Re: [boost] [git help] Documenting common modular boost workflows

Subject: Re: [boost] [git help] Documenting common modular boost workflows
From: Beman Dawes (bdawes_at_[hidden])
Date: 2013-10-23 12:06:16

On Tue, Oct 22, 2013 at 11:06 PM, Niall Douglas
<s_sourceforge_at_[hidden]>wrote:

> 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<version_number>
> >   git flow release finish v<version_number>
> >
> > 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