git synchronization of rebased branches

Question

I recently had a question answered about a multi-computer git development setup, and the solution I got there did solve my situation with the master branch, but not side branches based off the master.

Here's my current setup:

A--B--C--D  master
          \
           E--F--G--H  BUG_37

BUG_37 is a branch that is developing a fix to an optional tracked bug for a feature request in the system, and will eventually be merged into the master line, but is separate for the time being. With the repository in this state, one one machine, I made some changes to the master branch:

A--B--C--D--I--J--K  master
          \
           E--F--G--H  BUG_37

I then rebased the BUG_37 branch onto master, to ensure that it's working as an enhancement to the most current changes:

A--B--C--D--I--J--K  master
                   \
                    E1--F1--G1--H1  BUG_37

Let's say that rebase had a few conflicts that needed to be manually fixed before the rebase was final. If I push those changes to a remote repository, and now wish to pull changes down onto another development system that has the original setup still, what's the best way to do so? git pull --rebase will run the rebase again, and I'll have to manually go through the conflicts I went through the first time, right? And if I make a slight mistake going through the conflicts again, such that E1-H1 are slightly different in this new system, I'll get the repository even more out of sync.

How do I take a local repository in the original state and the remote repository in the third state, and have the local repository be updated to exactly match the remote repository (trashing changes E-H and moving the HEAD of BUG_37 to the new location)?

Answer 1

Delete the branch, then pull both branches from the remote repository.

git branch -D BUG_37
git pull origin master
git pull origin BUG_37:BUG_37

If you don't want to delete your local BUG_37 branch before being sure that this works, pull the remote branch into another local branch:

git pull origin BUG_37:NEW_BUG_37

Answer 2

I would not rebase at all on a branch which is already shared. While it results in the cleanest history, it will have changed the hashes of all the commits in BUG_37. So on the target machines, you will need to delete BUG_37 entirely and pull it again. This is OK to do once or twice but not great as a regular workflow.

It will be much easier to merge master into BUG_37; then the merge commit (where you fixed the conflicts) can be pushed to other machines, and branches won't need to be deleted.

Answer 3

I'm following the same workflow, basically switching between a laptop and desktop. I keep my main repo on the desktop and laptop clones the deskotp's repo. Eventually they get out of sync, cause I want to rebase my topic branches after I update master.

The simple answer, is just don't use git, instead use rsync to keep your repos synchronized. If you know you are the only one working on it, then this makes sense.

Well, I'm not a big fan of that solution either. So, this might be a little "cleaner". On the laptop, when pulling rebased branches from the desktop's repo:

git co topic
git fetch origin/topic
git reset --hard origin/topic

This will throw out any commits not on the desktop repo, so make sure you really want to do this.

Also, you probably can just git pull the laptop's master branch, since it should always be a fast-forward, cause you likely won't need to rebase it. I think it makes sense to rebase topic branches though, cause otherwise trying to merge it back into master at the very end is a pain.