5 ms·

This sounds like a feature branch strategy, which I've only used in 1 or 2 person teams, never on projects that big. There have been some articles recently on

This sounds like a feature branch strategy, which I've only used in 1 or 2 person teams, never on projects that big. There have been some articles recently on the downsides of feature branching that my experience agrees with (http://continuousdelivery.com/2011/07/on-dvcs-continuous-integration-and-feature-branches/ http://continuousdelivery.com/2011/07/on-dvcs-continuous-int...). I'm curious if the GitHub people have hit the same issues. So if 2 people are working on the same feature, they're probably working off the same named branch. Are there any race conditions with merging to master? I'm assuming that only one head is allowed in master, correct? So that before a pull request is accepted and merged into master, the latest master must first be merged into the feature branch and have CI run all tests successfully on it before the pull request can go. Does GitHub stop you from merging into master if someone else just merged into master and you're about to create a new head? Then you have to merge the latest master into your feature branch, run CI on it again and then merge to master after CI is successful (assuming someone else didn't beat you to merging to master again). (I've got a lot more experience with Mercurial than Git so my mental model could be a little off)

dasil003 15y ago
> Are there any race conditions with merging to master? I'm assuming that only one head is allowed in master, correct? So that before a pull request is accepted and merged into master, the latest master must first be merged into the feature branch and have CI run all tests successfully on it before the pull request can go. Does GitHub stop you from merging into master if someone else just merged into master and you're about to create a new head? One useful thing to keep in mind for this explanation is that GitHub doesn't do anything really, it's just one more git repo with a bunch of sugar. Yes, there is only one HEAD for a branch in any given repo. When you push it expects that your local HEAD is a direct descendant of the remote HEAD. If this is not the case (due to someone pushing since you last pulled) then it won't do anything (you can force it, but that's almost always a bad idea). In practice though this is not a big issue. You don't have to remerge into the topic branch. Instead you can just reset your master HEAD to origin/master and then remerge the topic branch into master and then push. If you are just working on changes locally directly on master, it's even easier, you just do git pull --rebase and all your local changes are rebased to the latest HEAD.
pgr0ss 15y ago
I actually just wrote up a blog post as well about why I don't like feature branches: http://www.pgrs.net/2011/08/29/why-i-dont-like-feature-branches/ http://www.pgrs.net/2011/08/29/why-i-dont-like-feature-branc... My main reasons are that git history gets messy, builds don't run on feature branches (although github seems to have a work around here), and refactoring is harder. My opinions are largely based on working on larger projects (more than 10 devs working in the same codebase).
- freedrull 15y ago
  Learn to use rebase and squash commits! It solves a lot of the issues you talked about.
  - pgr0ss 15y ago
    Squashing commits can fix up git history, but it does not address the bigger issues: refactoring, lack of builds, and having to deploy multiple branches to test features. The first two make it very hard to do any significant code reworking on a feature branch.
    - simonw 15y ago
      GitHub seem to have solved both the lack of builds issue and the challenge of deploying multiple branches (their bot can deploy a branch to staging with a single command) - which just leaves refactoring. I imagine they deal with refactoring by broadcasting a message to the team saying "I'm working on refactoring area X, try not to touch that code until I'm done if you don't want to deal with a painful merge".
    - tpz 15y ago
      I intend no ill will with this response, but it is worth pointing out that "the first two" "bigger issues" have nothing to do with your revision control system. Lack of builds is something about which you and your CI server need to have a chat, and refactoring is something about which you and your people need to have numerous chats before, during, and afterwards.
  - 15y ago
schacon 15y ago
wrt that article, we don't run into these issues i think largely because we do something that seems straightforward to me that is for some reason not addressed in that article (unless i'm reading it wrong) which is to reintegrate (merge) from master into your feature branch rather often. the article you mention seems to think that you can either have short lived feature branches or integrate them into master all the time, where we (and most people, i think) do the opposite - integrate master into the feature branches so they're never that far behind and then do the opposite to fast forward the feature branch into master when it's ready to deploy. and yes, your mental model is off a bit - a branch in git is more like a bookmark in hg - multiple heads for a branch doesn't really make sense - every head is a branch, there is no such thing as an unnamed head.
technoweenie 15y ago
Yes, there's always a race condition merging to master. Occasionally I'll want to deploy something, but jenkins builds pile up, or someone is busy test-deploying a feature branch. Since we deploy from our chat room, we naturally talk about what we're doing in the same spot. Also, if you have too many developers on the same project, break the project up into smaller pieces. We have various systems in separate repos that can be rolled out independently.

dasil003 15y ago

> Are there any race conditions with merging to master? I'm assuming that only one head is allowed in master, correct? So that before a pull request is accepted and merged into master, the latest master must first be merged into the feature branch and have CI run all tests successfully on it before the pull request can go. Does GitHub stop you from merging into master if someone else just merged into master and you're about to create a new head? One useful thing to keep in mind for this explanation is that GitHub doesn't do anything really, it's just one more git repo with a bunch of sugar. Yes, there is only one HEAD for a branch in any given repo. When you push it expects that your local HEAD is a direct descendant of the remote HEAD. If this is not the case (due to someone pushing since you last pulled) then it won't do anything (you can force it, but that's almost always a bad idea). In practice though this is not a big issue. You don't have to remerge into the topic branch. Instead you can just reset your master HEAD to origin/master and then remerge the topic branch into master and then push. If you are just working on changes locally directly on master, it's even easier, you just do git pull --rebase and all your local changes are rebased to the latest HEAD.

pgr0ss 15y ago

I actually just wrote up a blog post as well about why I don't like feature branches: http://www.pgrs.net/2011/08/29/why-i-dont-like-feature-branches/ http://www.pgrs.net/2011/08/29/why-i-dont-like-feature-branc... My main reasons are that git history gets messy, builds don't run on feature branches (although github seems to have a work around here), and refactoring is harder. My opinions are largely based on working on larger projects (more than 10 devs working in the same codebase).

freedrull 15y ago
Learn to use rebase and squash commits! It solves a lot of the issues you talked about.
- pgr0ss 15y ago
  Squashing commits can fix up git history, but it does not address the bigger issues: refactoring, lack of builds, and having to deploy multiple branches to test features. The first two make it very hard to do any significant code reworking on a feature branch.
  - simonw 15y ago
    GitHub seem to have solved both the lack of builds issue and the challenge of deploying multiple branches (their bot can deploy a branch to staging with a single command) - which just leaves refactoring. I imagine they deal with refactoring by broadcasting a message to the team saying "I'm working on refactoring area X, try not to touch that code until I'm done if you don't want to deal with a painful merge".
  - tpz 15y ago
    I intend no ill will with this response, but it is worth pointing out that "the first two" "bigger issues" have nothing to do with your revision control system. Lack of builds is something about which you and your CI server need to have a chat, and refactoring is something about which you and your people need to have numerous chats before, during, and afterwards.
- 15y ago

schacon 15y ago

wrt that article, we don't run into these issues i think largely because we do something that seems straightforward to me that is for some reason not addressed in that article (unless i'm reading it wrong) which is to reintegrate (merge) from master into your feature branch rather often. the article you mention seems to think that you can either have short lived feature branches or integrate them into master all the time, where we (and most people, i think) do the opposite - integrate master into the feature branches so they're never that far behind and then do the opposite to fast forward the feature branch into master when it's ready to deploy. and yes, your mental model is off a bit - a branch in git is more like a bookmark in hg - multiple heads for a branch doesn't really make sense - every head is a branch, there is no such thing as an unnamed head.

technoweenie 15y ago

Yes, there's always a race condition merging to master. Occasionally I'll want to deploy something, but jenkins builds pile up, or someone is busy test-deploying a feature branch. Since we deploy from our chat room, we naturally talk about what we're doing in the same spot. Also, if you have too many developers on the same project, break the project up into smaller pieces. We have various systems in separate repos that can be rolled out independently.