Re: With feature branches, what is ever committed directly to master
- From
Jon Seymour <jon.seymour@gmail.com>
- Date
- Aug 11, 2010, 03:02 UTC
- Message-ID
- <AANLkTinwQhD-b0-6uQYwBa3r7psNvPp5LMcjqHVKLF+c@mail.gmail.com>
- In-Reply-To
- <AANLkTin0VgH8CvnUn_tCJPTkhh7Ce-tYWo52qouoVvRN@mail.gmail.com>
On Wed, Aug 11, 2010 at 5:02 AM, Bradley Wagner <bradley.wagner@hannonhill.com> wrote:
Show 15 quoted lines
> I realize there are a lot of different Git workflows but I'm wondering > how others in this community do it. > > We're using our "master" branch from our central repo (Beanstalk) as a > dev branch and we have stable branches for various release versions of > our software. > > We've not made as heavy use of feature branches yet as we should have. > Once we do start using them more regularly, what kind of stuff is ever > committed directly to "master" or is master typically the place where > things are merged into from other stable/features branches? > > Is "master" really even unstable at that point? > > Thanks in advance! I realize this question is pretty open-ended.
The project I am on is in test/fix mode at the moment.
In our workflow, we tend not to even bother with a shared master branch. The build team maintains one, but it is for their own sanity, not for sharing with the rest of the development team.
We do at least two team builds a day, the AM build ends with 10, the PM build with 5 and patch builds, if required with the next available unused number which is not 5 or 10. Each build is tagged with the build number [ providing most of the convenience of an SVN commit id ].
Our developers tend to base their work on the latest released build tag, except if it is a fix required to patch a build that has already been delivered to a higher test environment, in which case the patch is based on the build number of the code deployed into that environment. This patch can usually then be trivially merged into builds in lower environments as required.
Personally, I maintain several topic branches which are merged with the upstream only in the event of the requirement to resolve a merge conflict. Otherwise, I keep them clean and merge them into the base of my working branch (as described into an earlier note). By always merging into the base of my working branch (and never the tip) I can keep my working tree stable and my patches clean.
In my view, tag-based (rather than branch-based) sharing is a better way to work when you have a large team. In a large team, the shared branch is necessarily going to be highly unstable. The tags issued by the build team help create a measure of stability and point of reference in what would otherwise be a somewhat chaotic environment.
The single biggest mistake we made with git was to attempt to share work throughout the team by having developers keep in sync by merging with a shared master branch. Extracting a developers history from such a tangle is a complete nightmare.
jon.
Show 5 quoted lines
> -- > To unsubscribe from this list: send the line "unsubscribe git" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >