git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Git branch workflow

From
Drew Northup <drew.northup@maine.edu>
Date
Nov 23, 2010, 15:47 UTC
Message-ID
<1290527239.10892.12.camel@drew-northup.unet.maine.edu>
In-Reply-To
<20101122170805.8jtzkqwxpcog0kgk@dennymagicsite.com>
On Mon, 2010-11-22 at 17:08 +0000, denny@dennymagicsite.com wrote:
Show 50 quoted lines
> 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
Previous: Enrico Weigelt
Message 4 of 4 in “Git branch workflow”
  1. denny@dennymagicsite.comNov 22, 2010
  2. tom fogalNov 23, 2010
  3. Enrico WeigeltNov 23, 2010
  4. Drew NorthupNov 23, 2010

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.