Can you help me solve this mystery. We have been having an issue for months where, occasionally, changes seem to “disappear” or regress in our git repo. I finally caught it happening in the act.
Our workflow is to create a feature branch from master and start working. When we are ready to merge our work, we first merge master onto the feature branch, and fix any conflicts or integration issues.
During this particular merge, git decided to choose the feature branch version of a chunk, when it should have chosen the chunk from master. No merge conflicts, git just decided that was the right thing to do, incorrectly. why? And what can we do to prevent this kind of thing from happening?
Why do you merge master into feature? Your feature branch should be an isolated set of commits representing your change. As soon as you merge master into feature you've 'polluted' your commit.
If you needed a change committed to master after you branched your feature, you should use rebase. Think of a rebase (in this sense) as making your branch again, right now, with the commits you've already made on that feature branch.
A speculative reason as to why your changes are disappearing is that the master version of the file was committed more recently than the feature branch commit. When you merge master into feature there are no merge conflicts so git auto merges the branches for convenience.
Try recreating the scenario you've mentioned above, but instead merging feature into master and see what happens.
Edit:
how would we handle a hotfix that needs to happen in the middle of the integration of the feature with master?
A hotfix could be created as a new branch from the latest remote master before you are integrating. Remember that you are only doing the integration on your local repository, so any changes here are not public... yet.
git checkout -b hotfix origin/master
# do changes
git commit -am "Made hotfix"
git checkout master
git merge hotfix
# hotfix complete!
git push origin master
how do we keep long running feature branches up to date?
This is rebase bread and butter! If your feature is isolated you probably won't have to rebase. That said you should try to keep your feature as succinct as possible, so rebasing these feature branches is a good idea. It also means you are 'integrating' as you go!
git checkout master
git checkout -b long_feature master
# commit
# commit
# commit
# now to rebase!
# get latest changes from others
git fetch origin
# update your local master branch to reference the latest from origin/master
git branch -f master origin/master
# do the rebase!
git rebase master
# repeat this cycle as often and as many times as necessary until your feature is complete
When you rebase, you might have to resolve conflicts. This is something you would have to do at some stage anyway, and if you do it as you go you are likely to have less complicated conflicts to resolve as they are incremental rather than 'big bang'.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With