Git branch workflow

Git branch workflow

[denny]

my website was small enough where I usually fixed everything live on  
production server, including adding new features, doing bug fixes and  
so on.

Now, with git I can create branches in whatever order I want, and then  
merge them whenever I want and push things to production whenever I  
want.
With this, comes confusion of what a good branch workflow is.  And  
this will be my question -- in what order and from which branches to I  
create new branches and how do I merge them back.

Consider a specific scenario:
I am on dev server on master branch and I want to develop a specific  
feature F.
I cut a Feature branch F from master and start working on the feature.  
  Once I am done with most of the work on F and it works reasonably  
well, I want to push it to production, but .. before I do I realize  
that I want to make some CSS fixes to the site, unrelated to other  
branches, and I can wait with pushing Feature branch to Production  
until I fix up CSS reasonably well.
Here is the question:  do I cut the CSS branch from Master or do I cut  
it from the Feature branch?

If I want to keep close to my original before-git workflow, I say, either
*  merge Feature with Master
*  cut CSS branch from Master
*  do CSS fixes
*  merge CSS with Master
*  push Dev Master to Prod Master

or
*  cut CSS branch from Feature, as Feature already has latest code
*  when I am done with CSS, merge CSS into Feature
*  merge Feature into Master (and remove Feature)
*  push Dev Master to Prod Master

There are tons of other variations that are possible.  Which workflow  
is preferred for this scenario?

Supplementary questions that may help define a good workflow for my case:
*  What if later a bug is discovered in the Feature.  If I already  
merged Feature branch into Master and deleted Feature branch, do I  
create a FeatureBugFix branch?  Or do I keep the original Feature  
branch without removing it for a while?  If so, for how long do I keep  
it?  Do I perhaps keep a general BugFix branch instead that I don't  
remove?
*  currently I am the only developer working on the code.  This will  
not change in the forseeable future.

Dennis

Re: Git branch workflow

[tom fogal]

Hi Dennis,

denny@dennymagicsite.com wrote:
> my website was small enough where I usually fixed everything live on 
> production server, including adding new features, doing bug fixes and so 
> on.
> 
> Now, with git I can create branches in whatever order I want, and then 
> merge them whenever I want and push things to production whenever I want.
> With this, comes confusion of what a good branch workflow is.  And this 
> will be my question -- in what order and from which branches to I create 
> new branches and how do I merge them back.

This is, of course, a matter of opinion.  Despite what I say below, I
would say the best advice with git is: try it!  Experiment with a few
different workflows.  Give each a week or two.  I think you'll find
there are advantages to any approach, but there's one that works best
for *you*.

The nice thing about git is that you don't have to use the workflow that
works for "me" (for generic "me") -- you get to adapt git to fit the
workflow you have, instead of adapting your workflow to fit the git
you've got.

> Consider a specific scenario:
> I am on dev server on master branch and I want to develop a specific 
> feature F.
> I cut a Feature branch F from master and start working on the feature. 
>  Once I am done with most of the work on F and it works reasonably well, 
> I want to push it to production, but .. before I do I realize that I 
> want to make some CSS fixes to the site, unrelated to other branches, 
> and I can wait with pushing Feature branch to Production until I fix up 
> CSS reasonably well.
> Here is the question:  do I cut the CSS branch from Master or do I cut 
> it from the Feature branch?

I would personally base 'css' off of master.  Although with the caveat,
since I just recently did something dumb and lost data <g>, that I would
(now) push 'feature' to some backup repo first.  Not make it live, just
push it somewhere so it's backed up.

My logic is: a) the two things are logically disjoint.  I can always 
decide later that I want to bring them together.  It's much harder to
decide later that I want to pull them apart (though, admittedly, still 
possible); b) pushing to production involves certain risks.  Maybe you 
had a silly PEBKAC and broke some shell script, and now your entire site 
gives 401 errors.  By keeping them separate you can push to production + 
verify each branch separately, which hopefully makes the problem easier 
to figure out should you have a hand-to-forehead moment.

[snip]
> Supplementary questions that may help define a good workflow for my case:
> *  What if later a bug is discovered in the Feature.  If I already 
> merged Feature branch into Master and deleted Feature branch, do I 
> create a FeatureBugFix branch?  Or do I keep the original Feature branch 
> without removing it for a while?  If so, for how long do I keep it?  Do 
> I perhaps keep a general BugFix branch instead that I don't remove?

I don't have a set guide for doing this myself.  I go through and delete 
old branches whenever "git branch" grows so many lines of output that it 
annoys me.  That said, it's extremely rare that I use a branch which has
been merged back to master: instead I make a new bugfix-branch which is 
based off of master (or, more commonly: the release branch).

Cheers && HTH,

-tom

Re: Git branch workflow

[Enrico Weigelt]

* denny@dennymagicsite.com <denny@dennymagicsite.com> wrote:

> Consider a specific scenario:
> I am on dev server on master branch and I want to develop a specific  
> feature F.
> I cut a Feature branch F from master and start working on the feature.  
>   Once I am done with most of the work on F and it works reasonably  
> well, I want to push it to production, but .. before I do I realize  
> that I want to make some CSS fixes to the site, unrelated to other  
> branches, and I can wait with pushing Feature branch to Production  
> until I fix up CSS reasonably well.
> Here is the question:  do I cut the CSS branch from Master or do I cut  
> it from the Feature branch?

My advise: always fork from the latest stable revision (in your case:
production server's master). Before merging, always rebase onto latest
master and possibly rerun the test cycle.


cu
-- 
----------------------------------------------------------------------
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weigelt@metux.de
 mobile: +49 151 27565287  icq:   210169427         skype: nekrad666
----------------------------------------------------------------------
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------

Re: Git branch workflow

[Drew Northup]

On Mon, 2010-11-22 at 17:08 +0000, denny@dennymagicsite.com wrote:
> my website was small enough where I usually fixed everything live on  
> production server, including adding new features, doing bug fixes and  
> so on.
> 
> Now, with git I can create branches in whatever order I want, and then  
> merge them whenever I want and push things to production whenever I  
> want.
> With this, comes confusion of what a good branch workflow is.  And  
> this will be my question -- in what order and from which branches to I  
> create new branches and how do I merge them back.
> 
> Consider a specific scenario:
> I am on dev server on master branch and I want to develop a specific  
> feature F.
> I cut a Feature branch F from master and start working on the feature.  
>   Once I am done with most of the work on F and it works reasonably  
> well, I want to push it to production, but .. before I do I realize  
> that I want to make some CSS fixes to the site, unrelated to other  
> branches, and I can wait with pushing Feature branch to Production  
> until I fix up CSS reasonably well.
> Here is the question:  do I cut the CSS branch from Master or do I cut  
> it from the Feature branch?
> 
> If I want to keep close to my original before-git workflow, I say, either
> *  merge Feature with Master
> *  cut CSS branch from Master
> *  do CSS fixes
> *  merge CSS with Master
> *  push Dev Master to Prod Master
> 
> or
> *  cut CSS branch from Feature, as Feature already has latest code
> *  when I am done with CSS, merge CSS into Feature
> *  merge Feature into Master (and remove Feature)
> *  push Dev Master to Prod Master
> 
> There are tons of other variations that are possible.  Which workflow  
> is preferred for this scenario?
> 
> Supplementary questions that may help define a good workflow for my case:
> *  What if later a bug is discovered in the Feature.  If I already  
> merged Feature branch into Master and deleted Feature branch, do I  
> create a FeatureBugFix branch?  Or do I keep the original Feature  
> branch without removing it for a while?  If so, for how long do I keep  
> it?  Do I perhaps keep a general BugFix branch instead that I don't  
> remove?
> *  currently I am the only developer working on the code.  This will  
> not change in the forseeable future.
> 
> Dennis

Each may be overkill, but perhaps these will give you some ideas:
http://nvie.com/posts/a-successful-git-branching-model/

Referencing the above and other inspirations:
http://www.silverwareconsulting.com/index.cfm/2010/9/13/A-Git-Workflow-for-Open-Source-Collaboration--Part-I--Introduction

Good luck finding something that works for you!

-- 
-Drew Northup N1XIM
   AKA RvnPhnx on OPN
________________________________________________
"As opposed to vegetable or mineral error?"
-John Pescatore, SANS NewsBites Vol. 12 Num. 59