{"thread":{"id":"25814","subject":"Git branch workflow","startedAt":"2010-11-22T17:08:05Z","lastAt":"2010-11-23T15:47:19Z","messageCount":4,"participants":["denny@dennymagicsite.com","tom fogal","Enrico Weigelt","Drew Northup"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"156344","messageId":"20101122170805.8jtzkqwxpcog0kgk@dennymagicsite.com","threadId":"25814","inReplyTo":null,"subject":"Git branch workflow","fromName":"","fromEmail":"denny@dennymagicsite.com","sentAt":"2010-11-22T17:08:05Z","receivedAt":"2010-11-22T17:08:05Z","isPatch":false,"sender":{"key":"denny@dennymagicsite.com","avatar":null},"body":"my website was small enough where I usually fixed everything live on \nproduction server, including adding new features, doing bug fixes and \nso on.\n\nNow, with git I can create branches in whatever order I want, and then \nmerge them whenever I want and push things to production whenever I \nwant.\nWith this, comes confusion of what a good branch workflow is. And \nthis will be my question -- in what order and from which branches to I \ncreate new branches and how do I merge them back.\n\nConsider a specific scenario:\nI am on dev server on master branch and I want to develop a specific \nfeature F.\nI cut a Feature branch F from master and start working on the feature. \n Once I am done with most of the work on F and it works reasonably \nwell, I want to push it to production, but .. before I do I realize \nthat I want to make some CSS fixes to the site, unrelated to other \nbranches, and I can wait with pushing Feature branch to Production \nuntil I fix up CSS reasonably well.\nHere is the question: do I cut the CSS branch from Master or do I cut \nit from the Feature branch?\n\nIf I want to keep close to my original before-git workflow, I say, either\n* merge Feature with Master\n* cut CSS branch from Master\n* do CSS fixes\n* merge CSS with Master\n* push Dev Master to Prod Master\n\nor\n* cut CSS branch from Feature, as Feature already has latest code\n* when I am done with CSS, merge CSS into Feature\n* merge Feature into Master (and remove Feature)\n* push Dev Master to Prod Master\n\nThere are tons of other variations that are possible. Which workflow \nis preferred for this scenario?\n\nSupplementary questions that may help define a good workflow for my case:\n* What if later a bug is discovered in the Feature. If I already \nmerged Feature branch into Master and deleted Feature branch, do I \ncreate a FeatureBugFix branch? Or do I keep the original Feature \nbranch without removing it for a while? If so, for how long do I keep \nit? Do I perhaps keep a general BugFix branch instead that I don't \nremove?\n* currently I am the only developer working on the code. This will \nnot change in the forseeable future.\n\nDennis\n"},{"id":"156345","messageId":"4CEB0E2A.5080304@sci.utah.edu","threadId":"25814","inReplyTo":"20101122170805.8jtzkqwxpcog0kgk@dennymagicsite.com","subject":"Re: Git branch workflow","fromName":"tom fogal","fromEmail":"tfogal@sci.utah.edu","sentAt":"2010-11-23T00:43:22Z","receivedAt":"2010-11-23T00:43:22Z","isPatch":false,"sender":{"key":"tfogal@sci.utah.edu","avatar":null},"body":"Hi Dennis,\n\ndenny@dennymagicsite.com wrote:\n> my website was small enough where I usually fixed everything live on \n> production server, including adding new features, doing bug fixes and so \n> on.\n> \n> Now, with git I can create branches in whatever order I want, and then \n> merge them whenever I want and push things to production whenever I want.\n> With this, comes confusion of what a good branch workflow is. And this \n> will be my question -- in what order and from which branches to I create \n> new branches and how do I merge them back.\n\nThis is, of course, a matter of opinion. Despite what I say below, I\nwould say the best advice with git is: try it! Experiment with a few\ndifferent workflows. Give each a week or two. I think you'll find\nthere are advantages to any approach, but there's one that works best\nfor *you*.\n\nThe nice thing about git is that you don't have to use the workflow that\nworks for \"me\" (for generic \"me\") -- you get to adapt git to fit the\nworkflow you have, instead of adapting your workflow to fit the git\nyou've got.\n\n> Consider a specific scenario:\n> I am on dev server on master branch and I want to develop a specific \n> feature F.\n> I cut a Feature branch F from master and start working on the feature. \n> Once I am done with most of the work on F and it works reasonably well, \n> I want to push it to production, but .. before I do I realize that I \n> want to make some CSS fixes to the site, unrelated to other branches, \n> and I can wait with pushing Feature branch to Production until I fix up \n> CSS reasonably well.\n> Here is the question: do I cut the CSS branch from Master or do I cut \n> it from the Feature branch?\n\nI would personally base 'css' off of master. Although with the caveat,\nsince I just recently did something dumb and lost data , that I would\n(now) push 'feature' to some backup repo first. Not make it live, just\npush it somewhere so it's backed up.\n\nMy logic is: a) the two things are logically disjoint. I can always \ndecide later that I want to bring them together. It's much harder to\ndecide later that I want to pull them apart (though, admittedly, still \npossible); b) pushing to production involves certain risks. Maybe you \nhad a silly PEBKAC and broke some shell script, and now your entire site \ngives 401 errors. By keeping them separate you can push to production + \nverify each branch separately, which hopefully makes the problem easier \nto figure out should you have a hand-to-forehead moment.\n\n[snip]\n> Supplementary questions that may help define a good workflow for my case:\n> * What if later a bug is discovered in the Feature. If I already \n> merged Feature branch into Master and deleted Feature branch, do I \n> create a FeatureBugFix branch? Or do I keep the original Feature branch \n> without removing it for a while? If so, for how long do I keep it? Do \n> I perhaps keep a general BugFix branch instead that I don't remove?\n\nI don't have a set guide for doing this myself. I go through and delete \nold branches whenever \"git branch\" grows so many lines of output that it \nannoys me. That said, it's extremely rare that I use a branch which has\nbeen merged back to master: instead I make a new bugfix-branch which is \nbased off of master (or, more commonly: the release branch).\n\nCheers && HTH,\n\n-tom\n"},{"id":"156383","messageId":"20101123030516.GA27595@nibiru.local","threadId":"25814","inReplyTo":"20101122170805.8jtzkqwxpcog0kgk@dennymagicsite.com","subject":"Re: Git branch workflow","fromName":"Enrico Weigelt","fromEmail":"weigelt@metux.de","sentAt":"2010-11-23T03:05:16Z","receivedAt":"2010-11-23T03:05:16Z","isPatch":false,"sender":{"key":"weigelt@metux.de","avatar":null},"body":"* denny@dennymagicsite.com wrote:\n\n> Consider a specific scenario:\n> I am on dev server on master branch and I want to develop a specific \n> feature F.\n> I cut a Feature branch F from master and start working on the feature. \n> Once I am done with most of the work on F and it works reasonably \n> well, I want to push it to production, but .. before I do I realize \n> that I want to make some CSS fixes to the site, unrelated to other \n> branches, and I can wait with pushing Feature branch to Production \n> until I fix up CSS reasonably well.\n> Here is the question: do I cut the CSS branch from Master or do I cut \n> it from the Feature branch?\n\nMy advise: always fork from the latest stable revision (in your case:\nproduction server's master). Before merging, always rebase onto latest\nmaster and possibly rerun the test cycle.\n\n\ncu\n-- \n----------------------------------------------------------------------\n Enrico Weigelt, metux IT service -- http://www.metux.de/\n\n phone: +49 36207 519931 email: weigelt@metux.de\n mobile: +49 151 27565287 icq: 210169427 skype: nekrad666\n----------------------------------------------------------------------\n Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme\n----------------------------------------------------------------------\n"},{"id":"156396","messageId":"1290527239.10892.12.camel@drew-northup.unet.maine.edu","threadId":"25814","inReplyTo":"20101122170805.8jtzkqwxpcog0kgk@dennymagicsite.com","subject":"Re: Git branch workflow","fromName":"Drew Northup","fromEmail":"drew.northup@maine.edu","sentAt":"2010-11-23T15:47:19Z","receivedAt":"2010-11-23T15:47:19Z","isPatch":false,"sender":{"key":"drew.northup@maine.edu","avatar":"https://avatars.githubusercontent.com/u/18331571?v=4"},"body":"\nOn Mon, 2010-11-22 at 17:08 +0000, denny@dennymagicsite.com wrote:\n> my website was small enough where I usually fixed everything live on \n> production server, including adding new features, doing bug fixes and \n> so on.\n> \n> Now, with git I can create branches in whatever order I want, and then \n> merge them whenever I want and push things to production whenever I \n> want.\n> With this, comes confusion of what a good branch workflow is. And \n> this will be my question -- in what order and from which branches to I \n> create new branches and how do I merge them back.\n> \n> Consider a specific scenario:\n> I am on dev server on master branch and I want to develop a specific \n> feature F.\n> I cut a Feature branch F from master and start working on the feature. \n> Once I am done with most of the work on F and it works reasonably \n> well, I want to push it to production, but .. before I do I realize \n> that I want to make some CSS fixes to the site, unrelated to other \n> branches, and I can wait with pushing Feature branch to Production \n> until I fix up CSS reasonably well.\n> Here is the question: do I cut the CSS branch from Master or do I cut \n> it from the Feature branch?\n> \n> If I want to keep close to my original before-git workflow, I say, either\n> * merge Feature with Master\n> * cut CSS branch from Master\n> * do CSS fixes\n> * merge CSS with Master\n> * push Dev Master to Prod Master\n> \n> or\n> * cut CSS branch from Feature, as Feature already has latest code\n> * when I am done with CSS, merge CSS into Feature\n> * merge Feature into Master (and remove Feature)\n> * push Dev Master to Prod Master\n> \n> There are tons of other variations that are possible. Which workflow \n> is preferred for this scenario?\n> \n> Supplementary questions that may help define a good workflow for my case:\n> * What if later a bug is discovered in the Feature. If I already \n> merged Feature branch into Master and deleted Feature branch, do I \n> create a FeatureBugFix branch? Or do I keep the original Feature \n> branch without removing it for a while? If so, for how long do I keep \n> it? Do I perhaps keep a general BugFix branch instead that I don't \n> remove?\n> * currently I am the only developer working on the code. This will \n> not change in the forseeable future.\n> \n> Dennis\n\nEach may be overkill, but perhaps these will give you some ideas:\nhttp://nvie.com/posts/a-successful-git-branching-model/\n\nReferencing the above and other inspirations:\nhttp://www.silverwareconsulting.com/index.cfm/2010/9/13/A-Git-Workflow-for-Open-Source-Collaboration--Part-I--Introduction\n\nGood luck finding something that works for you!\n\n-- \n-Drew Northup N1XIM\n AKA RvnPhnx on OPN\n________________________________________________\n\"As opposed to vegetable or mineral error?\"\n-John Pescatore, SANS NewsBites Vol. 12 Num. 59\n"}]}