Some very good advice given to me before OPW was to split my work on each bug into a separate local branch on git.
If I had to make a flow chart, it’d probably look something like this:
The most important thing to remember, though, is to always use
$ git checkout <branch-name> when you are on master.
In other words, your new branch should always be a clone of the latest master branch to minimise the number of merge conflicts that can occur when you cherry-pick your commits back to master.
... 
You can also do:
git checkout
git rebase master
Which will rebase your branch on the latest master commit, so you fix the conflicts in your dev branch, and then:
git checkout master
git merge
Which won’t conflict since you’ve prepare the merge in the dev branch
I find it less cumbersome, especially if you have several commits in your dev branch, you don’t need to cherry-pick them one by one…also, it prevents from messing with master, all the conflict resolution work is done in the dev branch.
oops the dev-branch name doesn’t show up because it was interpreted as an html tag, i meant:
git checkout dev-branch
git rebase master
and then:
git checkout master
git merge dev-branch
Regards
Ha! That’s what I did today. This post was for the time when I checked out a branch from a branch that wasn’t master and then cherry-picked in master to absolute disaster.
I think I should mention that this is only of use while submitting patches on bugzilla while what you suggested is probably better when you have git access to origin/branch-name? Would you agree?
Not really, if you rebased your dev-branch, then after merging it back into master, it won’t result in a “merge commit”, but will simply apply all the commits from the dev branch in master. So the result is really the same. It’s only faster, and safer IMO
I am quite new to git, and I have some questions here. Can you please answer them?
In what I do:
There are absolutely no conflicts till I cherry-pick, and then I have to fix all conflicts in master.
In what you suggest:
I’ll fix all conflicts while I rebase the branch with master and then there probably won’t be any conflicts while I use git merge.
Though we agree that both methods are the same, why would you say that rebasing is faster and safer? Because of fewer git commands? Isn’t rebasing the branch for the sake of one or two commits bit of a wasted effort?
P.S. – Thanks for making me think about this. Rebasing/merging now looks like a solid square block instead of a cotton-candy-cloud in my head. 🙂
The first thing I do when I get a new laptop/computer is setting the shell prompt so that it shows the git branch you are currently in, dead useful when you are changing branches, rebasing, merging…
You will find thousand examples, just a random one: http://www.blog.project13.pl/index.php/fun/1198/terminal-heroes-display-git-branch-in-shell-prompt-ps1/
That’s awesome. I should probably just use that instead of this silly alias I have for “git branch”, that I type in every now and then. Thanks!
Pingback: Links 21/8/2013: Diversity on the Desktop, Android as Distro | Techrights
And if you use https://code.google.com/p/gerrit/ it will do ~all the “one branch for each bug” a lot more automatic 🙂