is a rebase enough when the remote advance?-CodePudding

I have the following situation

 origin/master, master
|
some_commit
|
|  * HEAD-> thebranch, origin/thebranch
|  * some other commit
|  * some third commit
|/
* the last common commit

I am not planning to add any commit to thebranch, I am just using it.

Now I have received notice that the developer of the branch has probably rebased it to the top of master and add some commits to it

The question

My question is how should I proceed in this case?

My guess

I am thinking on doing

git fetch origin thebranch

then rebasing my local thebranch to master

and then merging it? but this will produce a merge commit no? I am confused on how to proceed.

CodePudding user response：

Since you're not actively using that branch and not making code changes, you could simply reset your local branch to the remote and continue using it from there. This is one of the dangers of rebasing or otherwise changing the history of a remote branch, if people have it checked out, they have to somehow get back on track with the remote branch.

To do so, just fetch for the branch and reset. You don't want to make changes to the branch so merging or rebasing wouldn't make sense. You just want to move the pointer to the new commit.

git fetch origin thebranch # update your local copy of the remote branch
git switch thebranch       # make sure you're on your local branch
git reset origin/thebranch # resets the current branch to what's currently in origin/thebranch

Depending on your situation, you may need to do a hard reset by adding --hard to the reset command.

CodePudding user response：

If you are just using the branch, first, I do not see the point in having a local branch for it. You would live happily ever after by just doing:

git checkout origin/thebranch

Then when the branch moves, as is the case right now, you can simply do

git fetch origin
git checkout origin/thebranch # that's right, checkout the same remote branch

Now, going to your question, the remote branch has moved, and you have no intentions to actually add anything to it, you just need your local branch to go to that spot where the remote is. Given that the branch has been rebased (or even it it hasn't been rebased, you could do the same thing):

git checkout thebranch # checkout local branch
git fetch origin
git reset --hard origin/thebranch # set local branch (index and working tree as well) in origin/thebranch

That should do.

Warning: git reset --hard cleans up whatever changes you have hanging around in index and the working tree.

Last but not least, let's not avoid the opportunity to learn something else about rebase. Your proposal to rebase your local branch on top of the remote branch is not a good proposal. Mainly because git would try to create new commits on top of the remote branch (which should not be done unless you know what you are doing). Let's take this example of yours:

* some_commit (master, origin/master) 
|
|  * blahblah (HEAD-> thebranch, origin/thebranch)
|  * some other commit
|  * some third commit
|/
* the last common commit

Suppose that the developer working on origin/thebranch decided to rebase the branch:

* blahblah (origin/thebranch)
* some other commit
* some third commit
* some_commit (master, origin/master) 
|
|  * blahblah (HEAD-> thebranch)
|  * some other commit
|  * some third commit
|/
* the last common commit

If you just ran git rebase origin/thebranch git would try to apply the last 3 commits that make up local thebranch on top of origin/thebranch.... which would be a waste of time if the new commits were not changed by the original developer (then git would complain about empty commits and asking you to skip them... there is no need for that, right?). Another possibility is that there might have been conflicts when the original developer rebased the branch.... do you want to deal with them creating new commits on top of their work? I don't think so, right? But, ultimately, the reason to avoid a rebase is because you can't be sure if the new commits actually resemble the old one, right? The developer might have done a completely different work in the new branch (say, a ref%cktor) that has no relation to the old work and you would be trying to bring over the old code... which is a no-go.