* Git branch workflow
@ 2010-11-22 17:08 denny
2010-11-23 0:43 ` tom fogal
` (2 more replies)
0 siblings, 3 replies; 4+ messages in thread
From: denny @ 2010-11-22 17:08 UTC (permalink / raw)
To: git
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Git branch workflow
2010-11-22 17:08 Git branch workflow denny
@ 2010-11-23 0:43 ` tom fogal
2010-11-23 3:05 ` Enrico Weigelt
2010-11-23 15:47 ` Drew Northup
2 siblings, 0 replies; 4+ messages in thread
From: tom fogal @ 2010-11-23 0:43 UTC (permalink / raw)
To: denny; +Cc: git
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Git branch workflow
2010-11-22 17:08 Git branch workflow denny
2010-11-23 0:43 ` tom fogal
@ 2010-11-23 3:05 ` Enrico Weigelt
2010-11-23 15:47 ` Drew Northup
2 siblings, 0 replies; 4+ messages in thread
From: Enrico Weigelt @ 2010-11-23 3:05 UTC (permalink / raw)
To: git
* 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
----------------------------------------------------------------------
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Git branch workflow
2010-11-22 17:08 Git branch workflow denny
2010-11-23 0:43 ` tom fogal
2010-11-23 3:05 ` Enrico Weigelt
@ 2010-11-23 15:47 ` Drew Northup
2 siblings, 0 replies; 4+ messages in thread
From: Drew Northup @ 2010-11-23 15:47 UTC (permalink / raw)
To: denny; +Cc: git
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
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2010-11-23 15:49 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-11-22 17:08 Git branch workflow denny
2010-11-23 0:43 ` tom fogal
2010-11-23 3:05 ` Enrico Weigelt
2010-11-23 15:47 ` Drew Northup
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.