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

I have just experimented with it and using git pull --rebase works when pulling from a rebased branch. Without the --rebase flag, the commits will be duplicated, but with --rebase the commits are not being duplicated.

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.