{"thread":{"id":"24695","subject":"With feature branches, what is ever committed directly to master","startedAt":"2010-08-10T19:02:32Z","lastAt":"2010-08-13T23:52:52Z","messageCount":9,"participants":["Bradley Wagner","Michael Witten","David Ripton","Jon Seymour","Magnus Bäck","Tim Visher","Steven E. Harris"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"147667","messageId":"AANLkTin0VgH8CvnUn_tCJPTkhh7Ce-tYWo52qouoVvRN@mail.gmail.com","threadId":"24695","inReplyTo":null,"subject":"With feature branches, what is ever committed directly to master","fromName":"Bradley Wagner","fromEmail":"bradley.wagner@hannonhill.com","sentAt":"2010-08-10T19:02:32Z","receivedAt":"2010-08-10T19:02:32Z","isPatch":false,"sender":{"key":"bradley.wagner@hannonhill.com","avatar":"https://gravatar.com/avatar/8304e5020b13d5f8102220fae2f5dd607a2e114dbe62bbd92c1ab38fe0b69fdb?d=mp&s=160"},"body":"I realize there are a lot of different Git workflows but I'm wondering\nhow others in this community do it.\n\nWe're using our \"master\" branch from our central repo (Beanstalk) as a\ndev branch and we have stable branches for various release versions of\nour software.\n\nWe've not made as heavy use of feature branches yet as we should have.\nOnce we do start using them more regularly, what kind of stuff is ever\ncommitted directly to \"master\" or is master typically the place where\nthings are merged into from other stable/features branches?\n\nIs \"master\" really even unstable at that point?\n\nThanks in advance! I realize this question is pretty open-ended.\n"},{"id":"147671","messageId":"AANLkTik5MdbSFAN83B1D3ZbPmUutQ3ouqqAvYw+qECS1@mail.gmail.com","threadId":"24695","inReplyTo":"AANLkTin0VgH8CvnUn_tCJPTkhh7Ce-tYWo52qouoVvRN@mail.gmail.com","subject":"Re: With feature branches, what is ever committed directly to master","fromName":"Michael Witten","fromEmail":"mfwitten@gmail.com","sentAt":"2010-08-10T19:15:47Z","receivedAt":"2010-08-10T19:15:47Z","isPatch":false,"sender":{"key":"mfwitten@gmail.com","avatar":"https://avatars.githubusercontent.com/u/597101?v=4"},"body":"On Tue, Aug 10, 2010 at 14:02, Bradley Wagner\n wrote:\n> what kind of stuff is ever committed\n> directly to \"master\" or is master\n> typically the place where things are\n> merged into from other stable/features\n> branches?\n>\n> Is \"master\" really even unstable at\n> that point?\n>\n> Thanks in advance! I realize this\n> question is pretty open-ended.\n\nSee here:\n\n http://git.kernel.org/?p=git/git.git;a=blob_plain;f=MaintNotes;hb=todo\n\nThe `master' branch is indeed considered the most stable version of\nthe software when it comes to the way `git' itself is maintained.\n"},{"id":"147710","messageId":"4C61F760.4050409@ripton.net","threadId":"24695","inReplyTo":"AANLkTin0VgH8CvnUn_tCJPTkhh7Ce-tYWo52qouoVvRN@mail.gmail.com","subject":"Re: With feature branches, what is ever committed directly to master","fromName":"David Ripton","fromEmail":"dripton@ripton.net","sentAt":"2010-08-11T01:05:36Z","receivedAt":"2010-08-11T01:05:36Z","isPatch":false,"sender":{"key":"dripton@ripton.net","avatar":"https://avatars.githubusercontent.com/u/153528?v=4"},"body":"On 08/10/10 15:02, Bradley Wagner wrote:\n> I realize there are a lot of different Git workflows but I'm wondering\n> how others in this community do it.\n>\n> We're using our \"master\" branch from our central repo (Beanstalk) as a\n> dev branch and we have stable branches for various release versions of\n> our software.\n>\n> We've not made as heavy use of feature branches yet as we should have.\n> Once we do start using them more regularly, what kind of stuff is ever\n> committed directly to \"master\" or is master typically the place where\n> things are merged into from other stable/features branches?\n>\n> Is \"master\" really even unstable at that point?\n\nIf your repo is accessible to the public then I think it makes sense to \nhave master be stable. Because that's what people will see by default \nif they clone your repo, and you want to make a good first impression.\n\nIf it's a private repo that only insiders are allowed to see, then it \ndoesn't matter as much.\n\nOur team uses unstable master, which anyone on the team can push to. If \nsomeone pushes to it then a build and tests automatically run, and if \nthey succeed then that commit gets automatically pushed to the stable \nbranch. We let anyone create shared branches on the server if they want \nto collaborate on a feature. We make a tag for each release, but we \ndon't make a maintenance branch until we actually need it.\n\n-- \nDavid Ripton dripton@ripton.net\n"},{"id":"147714","messageId":"AANLkTinwQhD-b0-6uQYwBa3r7psNvPp5LMcjqHVKLF+c@mail.gmail.com","threadId":"24695","inReplyTo":"AANLkTin0VgH8CvnUn_tCJPTkhh7Ce-tYWo52qouoVvRN@mail.gmail.com","subject":"Re: With feature branches, what is ever committed directly to master","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2010-08-11T03:02:53Z","receivedAt":"2010-08-11T03:02:53Z","isPatch":false,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":"On Wed, Aug 11, 2010 at 5:02 AM, Bradley Wagner\n wrote:\n> I realize there are a lot of different Git workflows but I'm wondering\n> how others in this community do it.\n>\n> We're using our \"master\" branch from our central repo (Beanstalk) as a\n> dev branch and we have stable branches for various release versions of\n> our software.\n>\n> We've not made as heavy use of feature branches yet as we should have.\n> Once we do start using them more regularly, what kind of stuff is ever\n> committed directly to \"master\" or is master typically the place where\n> things are merged into from other stable/features branches?\n>\n> Is \"master\" really even unstable at that point?\n>\n> Thanks in advance! I realize this question is pretty open-ended.\n\nThe project I am on is in test/fix mode at the moment.\n\nIn our workflow, we tend not to even bother with a shared master\nbranch. The build team maintains one, but it is for their own sanity,\nnot for sharing with the rest of the development team.\n\nWe do at least two team builds a day, the AM build ends with 10, the\nPM build with 5 and patch builds, if required with the next available\nunused number which is not 5 or 10. Each build is tagged with the\nbuild number [ providing most of the convenience of an SVN commit id\n].\n\nOur developers tend to base their work on the latest released build\ntag, except if it is a fix required to patch a build that has already\nbeen delivered to a higher test environment, in which case the patch\nis based on the build number of the code deployed into that\nenvironment. This patch can usually then be trivially merged into\nbuilds in lower environments as required.\n\nPersonally, I maintain several topic branches which are merged with\nthe upstream only in the event of the requirement to resolve a merge\nconflict. Otherwise, I keep them clean and merge them into the base of\nmy working branch (as described into an earlier note). By always\nmerging into the base of my working branch (and never the tip) I can\nkeep my working tree stable and my patches clean.\n\nIn my view, tag-based (rather than branch-based) sharing is a better\nway to work when you have a large team. In a large team, the shared\nbranch is necessarily going to be highly unstable. The tags issued by\nthe build team help create a measure of stability and point of\nreference in what would otherwise be a somewhat chaotic environment.\n\nThe single biggest mistake we made with git was to attempt to share\nwork throughout the team by having developers keep in sync by merging\nwith a shared master branch. Extracting a developers history from such\na tangle is a complete nightmare.\n\njon.\n\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at  http://vger.kernel.org/majordomo-info.html\n>\n"},{"id":"147721","messageId":"20100811065751.GA8808@jpl.local","threadId":"24695","inReplyTo":"AANLkTin0VgH8CvnUn_tCJPTkhh7Ce-tYWo52qouoVvRN@mail.gmail.com","subject":"Re: With feature branches, what is ever committed directly to master","fromName":"Magnus Bäck","fromEmail":"magnus.back@sonyericsson.com","sentAt":"2010-08-11T06:57:51Z","receivedAt":"2010-08-11T06:57:51Z","isPatch":false,"sender":{"key":"magnus.back@sonyericsson.com","avatar":null},"body":"On Tuesday, August 10, 2010 at 21:02 CEST,\n Bradley Wagner wrote:\n\n> I realize there are a lot of different Git workflows but I'm wondering\n> how others in this community do it.\n>\n> We're using our \"master\" branch from our central repo (Beanstalk) as a\n> dev branch and we have stable branches for various release versions of\n> our software.\n>\n> We've not made as heavy use of feature branches yet as we should have.\n> Once we do start using them more regularly, what kind of stuff is ever\n> committed directly to \"master\" or is master typically the place where\n> things are merged into from other stable/features branches?\n\nFeature branches are useful when stuff needs to be developed in\nisolation, e.g. code that will undergo significant changes (usually\nleading to instability) or code whose release schedule isn't set in\nstone. When you're ready to create a stable branch for a public\nrelease you don't want to have half a dozen half-finished features\non master.\n\nWhile isolation is useful it also brings problems. If you have\ndependencies between features you may run into integration problems\nfar too late. People can merge between the feature branches to mitigate\nthis, but that also creates a mess. Isolation also means that the code\nwill be exercised less before released, i.e. less dog fooding. In some\ncases it makes sense to fulfill the goal of isolation by keeping\nchanges on the master branch but use static or dynamic configuration\nof the software to disable the code or maybe use branch by abstraction.\n\nIn the case of creating a feature branch for the sake of securing\nthe releasability of a branch one must also consider the conditions\nsurrounding the release. Is the feature currently being developed on\na feature branch a must-have for the release? If yes, one of the\nstrongest arguments for feature branches becomes moot.\n\nFinally, bugfixes and similar smaller changes that don't make up a\nwhole string of commits should probably not be developed on branches.\n\n> Is \"master\" really even unstable at that point?\n\nI guess that depends on your organization, your developers, and the\nmaturity, architecture and inherent quality of the software. And, of\ncourse, how you define unstable. How bad can it be before it hurts?\nHow would *you* weigh the risk of branching against the risk of\ndeveloper slowdowns caused by frequent regressions?\n\n-- \nMagnus Bäck Opinions are my own and do not necessarily\nSW Configuration Manager represent the ones of my employer, etc.\nSony Ericsson\n"},{"id":"147746","messageId":"AANLkTi=b3UBYiLEZDPsjp-J6h-=hJXw7mLjQBx614Q0N@mail.gmail.com","threadId":"24695","inReplyTo":"20100811065751.GA8808@jpl.local","subject":"Re: With feature branches, what is ever committed directly to master","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2010-08-11T09:21:05Z","receivedAt":"2010-08-11T09:21:05Z","isPatch":false,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":"On Wed, Aug 11, 2010 at 4:57 PM, Magnus Bäck\n wrote:\n\n> Finally, bugfixes and similar smaller changes that don't make up a\n> whole string of commits should probably not be developed on branches.\n\nI think there is a case for _developing_ fixes on branches as opposed\nto _sharing_ fix branches. In particular, it is good to minimize the\nstuff that a fix drags along, so delivering a a fix to an integration\nstream which is depends on the minimum amount of other cruft is good\npractice. It also means the fix can easily be shared with other\ndevelopers even if it hasn't yet mean integrated into the main\nintegration stream.\n\nThis is where the idea of maintaining a private working branch\n(described in an earlier e-mail) really pays off. You get to keep all\nyour unintegrated fixes in your working tree, but\nyou can freely share the stable ones with other developers and the\nintegration stream without reduced fear of creating a merge nightmare,\nsince you have taken care (in selecting the base for the fix) to keep\neach fix isolated.\n\nAs to whether the team should maintain _shared_ feature branches this\ndoes, as you say, depend on your circumstances. By _shared_ feature\nbranch, I mean a branch that has its own build cycle, test cycle etc.\nSuch things are expensive, and they get more expensive the more\ncomplicated your delivery environment is. If your team and product is\nsmall and nimble, it doesn't cost much to maintain the several loosely\ncoupled development processes. If it isn't, then you save a lot by\nhaving a single integration stream that everyone bases their work on\nsince you can share that build and QA overhead across the entire team.\n\njon.\n\n>\n>> Is \"master\" really even unstable at that point?\n>\n> I guess that depends on your organization, your developers, and the\n> maturity, architecture and inherent quality of the software. And, of\n> course, how you define unstable. How bad can it be before it hurts?\n> How would *you* weigh the risk of branching against the risk of\n> developer slowdowns caused by frequent regressions?\n>\n> --\n> Magnus Bäck                      Opinions are my own and do not necessarily\n> SW Configuration Manager         represent the ones of my employer, etc.\n> Sony Ericsson\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at  http://vger.kernel.org/majordomo-info.html\n>\n"},{"id":"147765","messageId":"AANLkTik0kvKbe8xQksOrVVs6BygoPF7K_sZJA6BXwRVK@mail.gmail.com","threadId":"24695","inReplyTo":"AANLkTin0VgH8CvnUn_tCJPTkhh7Ce-tYWo52qouoVvRN@mail.gmail.com","subject":"Re: With feature branches, what is ever committed directly to master","fromName":"Tim Visher","fromEmail":"tim.visher@gmail.com","sentAt":"2010-08-11T14:48:42Z","receivedAt":"2010-08-11T14:48:42Z","isPatch":false,"sender":{"key":"tim.visher@gmail.com","avatar":"https://gravatar.com/avatar/98307ce54bcac1a46b5d845827d5386e2a27895ff08790cdd3877ad527760575?d=mp&s=160"},"body":"On Tue, Aug 10, 2010 at 3:02 PM, Bradley Wagner\n wrote:\n> I realize there are a lot of different Git workflows but I'm wondering\n> how others in this community do it.\n>\n> We're using our \"master\" branch from our central repo (Beanstalk) as a\n> dev branch and we have stable branches for various release versions of\n> our software.\n>\n> We've not made as heavy use of feature branches yet as we should have.\n> Once we do start using them more regularly, what kind of stuff is ever\n> committed directly to \"master\" or is master typically the place where\n> things are merged into from other stable/features branches?\n>\n> Is \"master\" really even unstable at that point?\n>\n> Thanks in advance! I realize this question is pretty open-ended.\n\nSince no one mentioned it yet, I found this [paper][] to be an\nincredible resource and it's the workflow my team has adopted.\n\n[paper]: http://nvie.com/git-model\n\n-- \n\nIn Christ,\n\nTimmy V.\n\nhttp://blog.twonegatives.com/\nhttp://five.sentenc.es/ - Spend less time on e-mail\n"},{"id":"148048","messageId":"m2ocd6yx3h.fsf@Spindle.sehlabs.com","threadId":"24695","inReplyTo":"AANLkTinwQhD-b0-6uQYwBa3r7psNvPp5LMcjqHVKLF+c@mail.gmail.com","subject":"Re: With feature branches, what is ever committed directly to master","fromName":"Steven E. Harris","fromEmail":"seh@panix.com","sentAt":"2010-08-13T22:19:30Z","receivedAt":"2010-08-13T22:19:30Z","isPatch":false,"sender":{"key":"seh@panix.com","avatar":"https://gravatar.com/avatar/d59ec0f7c010ee73cd67db381a5b865206fed17fd4278f12cdb6277db30033fc?d=mp&s=160"},"body":"Jon Seymour writes:\n\n> Otherwise, I keep them clean and merge them into the base of my\n> working branch (as described into an earlier note). By always merging\n> into the base of my working branch (and never the tip) I can keep my\n> working tree stable and my patches clean.\n\nCan you clarify what you mean by \"merging into the base\" and \"never the\ntip\"? Perhaps a pointer to the earlier note you mentioned would suffice.\n\n-- \nSteven E. Harris\n"},{"id":"148056","messageId":"AANLkTimD34VqsMJzUyTawBbdKoXZNXbcTUxLwk5Rj_S3@mail.gmail.com","threadId":"24695","inReplyTo":"m2ocd6yx3h.fsf@Spindle.sehlabs.com","subject":"Re: With feature branches, what is ever committed directly to master","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2010-08-13T23:52:52Z","receivedAt":"2010-08-13T23:52:52Z","isPatch":false,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":"On Sat, Aug 14, 2010 at 8:19 AM, Steven E. Harris wrote:\n> Jon Seymour writes:\n>\n>> Otherwise, I keep them clean and merge them into the base of my\n>> working branch (as described into an earlier note).  By always merging\n>> into the base of my working branch (and never the tip) I can keep my\n>> working tree stable and my patches clean.\n>\n> Can you clarify what you mean by \"merging into the base\" and \"never the\n> tip\"? Perhaps a pointer to the earlier note you mentioned would suffice.\n>\n\nHere is a link to the earlier note:\n\n http://permalink.gmane.org/gmane.comp.version-control.git/153168\n\nthis explains how I am using the term base.\n\nInformally, it is the first commit your history which contains work\nthat your current work depends on, but is not part of your current\nwork.\nIt is always directly reachable from your head via a path which does\nnot include a merge (and, as such, defines a linear range of commits\nthat is easily re-ordered or rebased as required).\n\nThe idea is that the base of your working branch accumulates\ndependencies, while the head (or tip) of your working branch\naccumulates your work. By merging at the base, you are never \"hiding\"\nwork in progress with a merge. As your view of what your dependencies\nare changes, you can rebuild your base at will, and then rebase your\nwork on top of that.\n\njon.\n\n\n\n> --\n> Steven E. Harris\n>\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at  http://vger.kernel.org/majordomo-info.html\n>\n"}]}