2017年8月30日 星期三

[ Git 常見問題 ] Can't push to branch after rebase

Source From Here 
Question 
We use git and have a master branch and developer branches. I need to add a new feature and then rebase the commits to master, then push master to CI server. 

The problem is that if I have conflicts during rebase I cannot push to my remote developer branch (on Github) after the rebase is complete, until I pull my remote branch. This causes duplicate commits. When there are no conflicts, works as expected. 

Question: after rebase and conflict resolution, how do I sync up my local and remote developer branches without creating duplicate commits 
Setup: 
  1. // master branch is the main branch  
  2. git checkout master  
  3. git checkout -b myNewFeature  
  4.   
  5. // I will work on this at work and at home  
  6. git push origin myNewFeature  
  7.   
  8. // work work work on myNewFeature  
  9. // master branch has been updated and will conflict with myNewFeature  
  10. git pull --rebase origin master  
  11.   
  12. // we have conflicts  
  13. // solve conflict  
  14. git rebase --continue  
  15.   
  16. //repeat until rebase is complete  
  17. git push origin myNewFeature  
  18.   
  19. //ERROR  
  20. error: failed to push some refs to 'git@github.com:ariklevy/dropLocker.git'  
  21. hint: Updates were rejected because the tip of your current branch is behind  
  22. hint: its remote counterpart. Merge the remote changes (e.g. 'git pull')  
  23. hint: before pushing again.  
  24. hint: See the 'Note about fast-forwards' in 'git push --help' for details.  
  25.   
  26. // do what git says and pull  
  27. git pull origin myNewFeature  
  28.   
  29. git push origin myNewFeature  
  30.   
  31. // Now I have duplicate commits on the remote branch myNewFeature  
How-To 
First, you and those you're working with need to agree whether a topic/devel branch is for shared development or just your own. Other developers know not to merge on my development branches because they'll be rebased at any time. Usually the workflow is as follows: 
  1. o-----o-----o-----o-----o-----o       master  
  2. \  
  3.    o-----o-----o                      devel0  
  4.                 \  
  5.                   o-----o-----o       devel1  
Then to stay up-to-date with remote I'll do the following: 
# git fetch origin 
# git checkout master 
# git merge --ff origin/master

I do this for two reasons. First because it allows me to see if there are remote changes without needing to switch from my devel branch. Second it's a safety mechanism to make sure I don't overwrite any un-stashed/committed changes. Also, if I can't fast-forward merge to the master branch that means either someone has rebased the remote master (for which they need to be flogged severely) or I accidentally committed to master and need to clean up my end. 

Then when remote has changes and I've fast forwarded to the latest I'll rebase: 
# git checkout devel0 
# git rebase master 
# git push -f origin devel0

Other developers then know they'll need to rebase their devel branches off my latest: 
# git fetch  
# git checkout devel1 
# git rebase /devel0

Which results in much cleaner history: 
  1. o-----o                                 master  
  2.        \  
  3.          o-----o-----o                  devel0  
  4.                       \  
  5.                         o-----o-----o   devel1  
Don't merge commits back and forth at your whim. Not only does it create duplicate commits and make history impossible to follow, finding regressions from a specific change becomes near impossible (which is why you're using version control in the first place, right?). The problem you're having is the result of doing just this. 

The only time to merge is when your topic branch is ready to be accepted into master. On a side note. If multiple developers are committing to the same repository you should all consider having named branches to distinguish between developers devel branches. For example: 
# git branch 'my-name/devel-branch'

This message was edited 7 times. Last update was at 30/08/2017 21:53:53

1 則留言:

  1. I like your blog, I read this blog please update more content on hacking, further check it once at python online course

    回覆刪除

[Linux 常見問題] What's the best way to send a signal to all members of a process group?

Source From  Here   Question   I want to  kill a whole process tree.  What is the best way to do this using any common scripting languages? ...