On Tue, Oct 22, 2013 at 11:06 PM, Niall Douglas
On 22 Oct 2013 at 19:45, Dave Abrahams wrote:
I don't understand the source of mystery here. This is bog-standard Git usage:
cd my/submodule/directory git checkout develop # make edits
Umm, shouldn't you create a new branch here for the change rather than changing develop directly:
git checkout -b issue_8_fix develop #make edits git commit -a git checkout develop git merge issue_8_fix git commit -a
My (very tentative) plan for the docs is to recommend always branching for new features, even if trivial, and also for other change if they are anything beyond trivial. But not for a totally simple change like fixing a single typo level bug. I'm not sure I want to sidetrack in what is basically beginners documentation to take about how practices often differ among projects, particularly along the spectrum from small single developer projects all the way up to very large multi-developer mega projects. But maybe I'll say something brief.
git commit git push origin develop [snip] git flow release start v
git flow release finish v As you can see, that's a lot simpler. I strongly recommend using the gitflow tool because it will save lots of trouble and prevent mistakes.
I agree. Though I must admit I do it by hand personally, mainly because TortoiseGit doesn't assist gitflow to my knowledge.
The TortoiseGit folks have been very responsive to the few requests for improvements I've been involved with. So if we find gitflow tools would be helpful, consider submitting a request to them.
For those interested: point is with gitflow that git branches are incredibly cheap. You branch for every self contained change, no matter how small. Think a branch per fully compiling source tree, and you're about right granularity. It's normal to generate hundreds of new branches per month - don't worry, there is a git command to auto purge all merged branches.
Yes, I'll probably add that as an aside.
Thanks, --Beman