I am having an issue with rebasing from master on to a ‘deploy’ branch within one of my repositories.
My repo is setup as follows:
master - of course, the main branch
deploy - a branch created where files like Capfile, deploy.rb etc are created and configured - these changes will NEVER be merged back into Master
Generally my workflow is:
- Do development on the master branch… test, smile, commit.
- Checkout the
deploybranch - Execute
git rebase masteron the deploy branch – this used to work without a problem - Push to remote and then execute
cap deploy - Relax
The problem I am now having is that when I execute git rebase master on the deploy branch it is coming up with a 3-way merge/manual merge required error (I don’t think the error message is really generic enough to post). Git tells me to perform a merge then use git rebase --continue to finish – which never works.
What I have found ‘does’ work is running git rebase master --interactive, cleaning up the pick list (there is 5 or so repeated ‘commits’ but with different reference numbers (same message) in this list, so I’ll choose one of them) and then manually do the merge. Once I have done this for each commit then I can continue the rebase and its all happy…
Until next time I need to perform a rebase.
So does anyone know what might be happy? The project isn’t really ‘secret’ so if need be I can post messages, logs, branch graphs etc.
Thanks
What sounds like it might be happening is that you have changed the commit history of those “repeated” commits such that they have a different sha1. Each sha1 is unique to not only the commit, but the commit history. Hence, it’s impossible (well, highly improbably to happen during the lifetime of the universe), to have two identicial sha1 in the same history or to have two sha1 in two different histories even. If you change anything in your commit, such as with an amend or interactive rebase, then you will change the sha1. So two commits that might look the same, are actually treated differently.
So very likely, you rebased from the other branch, did some type of interactive rebase or amended the commits, continued to commit some more code that modified that same part of the code, then on the next rebase you have conflicts because the commits that you have in your local branch that differ from the branch you are rebasing from are removed from the branch, the upstream is pulled in including that commit you’ve already pulled in and changed the sha1 of, and then when the commits are replayed onto the branch you end up with a conflict because the state of the code has changed from what the commit was expected because it was original created from a different history than what you now have on your branch. Wow, that was a long sentence…
When you’re “cleaning” up the pick list… what you are doing is likely deleting these repeated commits before rebasing, so now you’re not reapplying changes that have already been applied, so no more conflicts.
However, if you just wanted to resolve the conflicts during the rebase, this would likely be the best bet so you don’t accidently delete a commit that you want. Resolving the conflicts will make the change set of that commit different an applicable to the history you have. Once you push this merge conflict resolution, you shouldn’t see the issues again unless you modify commits that have already been pushed again.
To find which files have the merge conflicts do:
or
Once you know which files have conflicts, if you have a mergetool setup you can do:
If you’d rather merge manually, you can find the merge markers and lines by doing:
at the top level of your repo path and edit. When you edit manually, make sure you remove the markers and make the final version of the file look like how you want it to… git doesn’t do anything special with the markers for you. When you’ve finished editting manually, make sure to do
to add the file to add it to the index and remove the unmerged flag. When you are done resolving all unmerged files, do
To complete the rebase.