Reputation: 6928
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)?
Upvotes: 13
Views: 6616
Reputation: 1281
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.
Upvotes: 3
Reputation: 117096
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.
Upvotes: 3
Reputation: 125217
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.
Upvotes: 8
Reputation: 24475
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
Upvotes: 5