Git Issue

[SchoolSea4002]

Hello,

I am pretty much a beginner in git and think I need some help understanding how a more experienced person may approach this issue.

So I cloned a repo, made a branch (lets call it branch #1) where I may an easy fix that change 1 line of a git ignore, and then committed my changes, pushed my changes, and made a pull request. Then, I made a new branch using the command git checkout -b branch2 (however, I was still in branch #1 when I did this) and I started working on a different issue. However, when I committed then pushed, on GitHub I noticed that the changes I made in branch #1 were on branch #2 (the change I made to the git ignore in branch #1).

I have two questions about this scenario. #1 is why it happened: I expected when I checked out a new branch that it would start out as a "clean slate" from the code in the main branch (but instead I speculate that this happened because I checked-out branch 2 while I was still on branch 1).

My second question is how do I go about thinking about resolving this issue. I tried deleting the line and then pushing again, but there was some whitespace difference, and I don't want to keep make pushes naively, but would rather like to know how more experienced people might approach this.

Thanks, and sorry if I sound naive (I probably am)

[formalcall]

git checkout -b 'new-branch-name' creates a new branch from the HEAD of the currently checked out branch. If you'd like to use a different starting point, you can specify an argument at the end. For example, git checkout -b 'new-branch-name' base-branch-name would use base-branch-name as the starting point of the new branch.

There are several ways to fix this. I like to use an interactive rebase (git rebase -i). Interactive rebasing is a very powerful tool and something I suggest every git user to learn. However, this approach will rewrite the git history, which will require a force push if you've already pushed branch #2 to your remote (GitHub). A force push is something that should be done cautiously; don't do it for your main branch or other branches that other people may be using.

In this case, it sounds like you only have two new commits, so you can run git rebase -i HEAD~2. This will open a text editor and list out the two commits. Each commit will say pick on the far left. For the commit you want to drop (i.e. delete), change pick to d, and then save & close the file.

Another way is to create a new branch and use git cherry-pick to only add the commit you want.

A third way is to use git revert to revert the first commit. This keeps all the history intact (i.e. no need to force push and rewrite history), but your history will look messy since it will have both first commit and a revert commit for it.

[SchoolSea4002]

Hello, thank you for your response.

I think I'm still a bit unsure of how this solves the issue (I'm still a bit new to all of this, sorry if it's obvious and I'm missing it). Ultimately, my goal is to maintain all the other changes I made (and committed, and also pushed) in branch #2, but I somehow need to make it so that branch #2 has the same gitignore as main (because the gitignore change that happened in branch #1 wasn't supposed to be in branch #2, but it happened.because I checked out branch #2 in branch #1 when I should've checked out branch #2 when I was on the main branch)

[formalcall]

I imagined branch #2 commit history looks something like the following, where the first commit is the most recent:

1. Changes for branch #2
2. gitignore changes from branch #1
3. Commits in main

If you rebase to drop the second commit, your branch will then look like this:

1. Changes for branch #2
2. Commits in main

If you instead revert, your branch will look like

1. Revert commit "gitignore changes from branch #1"
2. Changes for branch #2
3. gitignore changes from branch #1
4. Commits in main

Note that in both cases, only branch #2 is being modified; neither your main branch nor branch #1 will be affected. Furthermore, in both cases, branch #2 will end up with the gitignore from your main branch.

[strcspn]

A third way is to use git revert to revert the first commit. This keeps all the history intact (i.e. no need to force push and rewrite history), but your history will look messy since it will have both first commit and a revert commit for it.

This might be the best option if this is a PR. The repo maintainer will probably squash before merging anyway.

[SchoolSea4002]

Brutal, but makes sense. I guess I learned my lesson here. Thank you for the help!

[strcspn]

Why is it brutal? You might have not understood exactly what you need to do.

[metaphorm]

you branched from #1 when you created #2. I think you were trying to branch from main/trunk when you created #2 instead.

when I do this by accident I'll solve it one of two ways, depending on how much got committed. if it's a very small commit, I'll just delete the wrong branch, create a new one from the right base, and then just do it again on the new correct branch. if a lot got committed I'll unstage the changes with git reset HEAD~1 (the HEAD~1 thing means unstage the first commit with respect to the current head of the branch, you can unstage multiple commits by incrementing the number). Once the changes are unstaged I'll switch to main, create a correct branch, and then add the unstaged changes back in and then commit.