21 ms·

A note of reflection after 10 years of “A successful Git branching model”

199 points by nilsandrey 7y ago

nilsandrey 7y ago
Strongly agreed with the new author note. I used the same ideas with the teams I've been coaching: "Consider your context...." as the need or not of support for multiple versions and "...Decide for yourself.
umvi 7y ago
I tried using Gitflow on our team, but there was too much complexity for me. We ended up switching to Trunk Based Development (TBD)[1] which I and my team found to be much simpler. [1] https://trunkbaseddevelopment.com/ https://trunkbaseddevelopment.com/
- wcarss 7y ago
  +1 to trunk based. There's obviously a lot there, but one of the best bits is the idea that each release deserves a branch. It makes hotfixes, ci/cd, and rollbacks all much simpler to reason about.
- alexbanks 7y ago
  I didn't know there was a name for this, but I've been doing it for 2 years now and I don't think I could go back.
  - obelos 7y ago
    Same here. My team has been managing our git repo like this for years, but I didn't realize there was a named practice around it.
    - mixmastamyk 7y ago
      It was the way in the svn days and common before. But folks attracted to git are often the same that like to desimplify things.
- billti 7y ago
  I would love all the hours back I spent in discussions around branching strategy, trying to keep complex models understood across the team (and myself), dealing with painful merges and flowing changes through, trying to figure out if a change is in a branch already, etc.. It's so much simpler and more productive if everyone works in master, with new features behind a flag if need be, with just critical fixes ported to release branches. There will always be arguments for why a more complicated branch strategy needs to be introduced. Resist those arguments. In my experience, the cost rarely pays for any benefits. Writing good software is hard enough already.
  - sethammons 7y ago
    We work on a branch and merge to master only after code review and (usually) quality assurance. We also deploy asap after merging to master and passing all regression tests. We can and often do deploy the same service many times a day.
- zoomablemind 7y ago
  Same here. Trunk based is easy to explain and enforce. The only challenge we faced was maintaining patch releases. Folding in fixes for common issues which were found in newer releases sometimes involved more than just cherrypicking the fix into a patch release for an older version. This inevitably led to asking users to update to more up-to-date versions. This further enforced the linear development paradigm.
  - gregmac 7y ago
    This is the one thing that I find lacking in trunk-based development. I work on multiple products that have a release branch for each minor release, and it works incredibly well other than this as a minor pain point. I find the easiest way is that if you know you want (or even think you might want) a particular fix in a patch version, you can make a branch from the oldest release branch you want to support. When you create a PR, you can easily target to the release branch (or another later release branch) or master, depending on what you want. You can even do multiple PRs to merge it multiple places. No matter how you go about it, it should always be safe to merge a release branch back into master. In fact, this is a good thing to do after you release a patch version, but can also be done whenever you need a particular fix in newer (master, or other feature branch code) code immediately. Merging release branches like this makes following a fix significantly easier than if you do it with cherry picking. Consider if you're looking at bug ticket, and trying to figure out what branches/releases it was fixed in. If the PR was merged to master, then later cherry picked to an older release, all you'll see is it was in master. Unless someone manually comments about it or your tooling picks it up based on references, the only other thing to do is check the code itself to see if the fix is there. When you instead merge forward, even if the ticket comments are wrong or not there, you can literally follow the branches from the PR/commits and see every release it got into.
    - brandmeyer 7y ago
      > Unless someone manually comments about it or your tooling picks it up based on references. I don't find this to be overly burdensome on the tooling. If the ticket-tracking system can't automate traceability between git commits and tickets, then it isn't well-suited to git-based software development. We use the following policy: - A bugfix commit must fix the bug, the whole bug, and nothing but the bug. If that seems impractical for the task at hand, make it practical by breaking up the bug's ticket into smaller elements. - Bugfix commits always cite the bug tracking system's ticket number. - The bug tracking system observes the git tree and maintains its own linkage to it. - When cherry-picking the bugfix to other affected branches, pass the `-x` argument to `git cherry-pick`. That's it. The (cherry-picked from) comment helps out when just viewing the git history on its own. And the bug tracking system lets you quickly see all of the commits and pull requests that referred to the bug.
- Legion 7y ago
  Trunk based using short lived feature branches is the only thing I've used that has made any sort of sense in terms of value vs. complexity.
- bosswipe 7y ago
  TBD is fine for web apps, but not for software that you have to maintain multiple versions in the wild at the same time or when the release cycle takes several weeks.
  - wikibob 7y ago
    So...shouldn't the focus be fixing the fact that release cycles take several weeks? This is well researched and discussed in Nicole Forsgren's book: Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations https://www.amazon.com/Accelerate-Software-Performing-Technology-Organizations/dp/1942788339 https://www.amazon.com/Accelerate-Software-Performing-Techno...
    - brandmeyer 7y ago
      Sometimes long test cycles are just the nature of the business, especially in hardware-software co-development, and especially in high-reliability development. Nobody will believe that running software tests on a workstation or server somewhere counts for release readiness if it gets deployed to a wind turbine, robot, or megawatt UPS. The software team's automated tests indicate that the software is ready to start an expensive physical testing cycle, not that its ready to go to the field.
  - lilbobbytables 7y ago
    That isn't true at all. Trunk based is perfect for this because you have the clean release branches from the trunk. I've worked in large companyies very successfully using TBD and releasing quarterly to enterprise customers using our software on their systems.
    - blondin 7y ago
      > I've worked in large companyies very successfully using TBD and releasing quarterly to enterprise customers using our software on their systems. care to elaborate? curious about those companies and the software you are talking about. i totally see the trunk based process work for software that doesn't need to maintain multiple versions as the original commenter said. but for multi-versioned software you can't afford to have a single trunk and let your developers have a go at it. i went and checked the repos for some of the multi-versioned software that i use that are open-source. well confirmed.
- jpswade 7y ago
  Absolutely agree. I think git flow makes sense to begin with however once you start to do CI/CD, you need something a bit more robust. Trunk based development gives you that. No long lived branches. No merge hell. It’s considerably better.
  - mixmastamyk 7y ago
    I’d argue that starting simple and adding complexity only when needed is a better strategy.
- mcv 7y ago
  The thing I don't get about trunk-based development is: if everybody always pushes straight to master, how do you do code review? Or don't you do code review in TBD? I like having explicit pull requests where a new feature can be reviewed.
  - deleted 7y ago
    [deleted]
  - adrianmsmith 7y ago
    That link does say that you can use pull requests for merging the short-lived feature branches back into master. It says that, for small teams, pushing directly into master might be acceptable (presumably without code review).
    - mcv 7y ago
      But how short-lived can they be? Feature development isn't necessarily short. Reviewing bits and pieces of a feature without having the whole thing together may not be very informative. And small teams may also care about code review.
gulbrandr 7y ago
Is this related to the "Please stop recommending Gitflow" [1] article posted yesterday? [1] https://news.ycombinator.com/item?id=22485489 https://news.ycombinator.com/item?id=22485489
- deleted 7y ago
  [deleted]
- sytse 7y ago
  Kind of, that article recommends making things less complex if you do continuous delivery to a SaaS. The update article mentions it was meant for versioned software. I tried to articulate the various levels of branching you need in GitLab Flow https://docs.gitlab.com/ee/topics/gitlab_flow.html https://docs.gitlab.com/ee/topics/gitlab_flow.html The various levels are: feature branches, production branches, environment branches, and release branches.
  - waheoo 7y ago
    Sounds like gitlab tried to fix githubflow instead of realising its fundamentally broken and going with the gerrit pattern that works fine for both trunk based and release style applications.
    - sytse 7y ago
      We offer multiple options that depend on your need. GitHub flow and Git flow are at two ends but there are also intermediate steps.
arghskwidge 7y ago
AFAICT Gitflow just has one more branch than it needs. If you got rid of the master branch and supported production releases off release branches it would be just as useful and significantly less complicated. Can anyone explain to me what real value the master branch adds in this model? And without using fluffy meaningless words like, "source of truth," please.
- Chilinot 7y ago
  I fully agree. Removing the master branch which is just fluff that noone uses you essentially come to trunkbased development.
- raziel2p 7y ago
  The main advantage I can think of is you can just configure your nightly expensive CI jobs (running absolutely all e2e tests) to run against a static branch. Another might be that git clone gets the "correct" branch by default. Might be important if your git repo gets cloned by sales, support or whatever for external demo purposes. Anyway I don't think it makes a huge difference in complexity - it's rarely used for developers' workflows and doesn't even need to be updated that often.
  - pdpi 7y ago
    How meaningful is it to run build/test against a branch that is reflective neither of a release branch nor a feature branch, though?
    - amrox 7y ago
      For mobile apps and SDKs I found it very useful to keep a pointer to the current production version (master) for integration tests.
- jordigh 7y ago
  I don't really understand the distinction between develop and master either. You're supposed to branch off develop and merge forward back into develop, then merge into a release branch, then merge into master. So everything in develop is supposed to end up in master. So... why not branch off master and merge back into master?
cjfd 7y ago
It all depends on the situation. The simplest possible situation of mostly just having a master branch also can work quite well. When you have specialized testers that test a candidate release you start to need release branches. Feature branches start being necessary if changes are temoprarily incompatible with current master. This should not be too common, though. In many cases one can avoid feature branches by having feature switches that get removed as soon as a feature is done. If one wants to or needs to use feature branches they should be short-lived because one will be creating a merge hell if this is not the case. The git flow seems just too complicated for most cases. One comment already notices that it is quite unclear why a separate development and master branch are necessary.
debaserab2 7y ago
I've yet to work on a codebase that was so congested it required such strong delineation between feature/hotfix/release but I can see how it might be required at a certain size. I wonder what that threshold is.
- stickydink 7y ago
  It depends what you're working on. We have a fairly small team (7 engineers) working on a reasonably complex app (many features). Our "features" take anything from 1 day to 3 weeks of effort, and generally need to roll out as a whole. They are often really upgrades of existing features, and the work to continuously merge w/ feature flags, supporting both flows/designs, is just not something we've felt was worth the extra time. We release on a 2 week cycle, the same day each time. We merge our features into the develop branch as they are ready and safe for production. Our scheduled release day is Wednesday. The Thursday beforehand, we branch from develop into a release/x.y.0. This builds release candidates. We have a sanity check on Friday, then our remote QA team runs through them over the weekend. Any issues they find, we try to have squared away by Monday, Tuesday at the latest. Meanwhile other team members are still merging new things into develop. It's useful to have that release branch because it lets the rest of the team keep moving - we maybe only put out 1 or 2 developer's features each cycle, the rest are still trickling in. Once we release, we tag, merge into master, and start over again. If any issues show up on production, we use the hotfix branch, hotfix/x.y.z. That let's us resolve issues with risking a ship of any of the changes that have come into develop that haven't had a few days of stability behind it. For our team scale, we have a lot of users (100k's DAU), and we find this method is a nice balance between the pace of output you might get from true CI but with the reliability of a more traditional cycle. Backend and web projects, however... Straight CI, into master, and we roll out test > staging > production when we're happy.
  - debaserab2 7y ago
    I basically follow the same protocol as you up to this point: > Once we release, we tag, merge into master, and start over again. If any issues show up on production, we use the hotfix branch, hotfix/x.y.z. That let's us resolve issues with risking a ship of any of the changes that have come into develop that haven't had a few days of stability behind it. In our case, there's no point in a hotfix branch because master is always considered stable. You don't merge to master unless you're ready for that code to hit production. Feature gates are used for hiding live code when necessary for marketing announcements or if the feature simply isn't ready for actual customer usage yet (sometimes we leave the endpoints live but turn off all the navigation to the endpoint so we can send out the link as a "beta" test for specific customers). This does occasionally cause problems with feature branches lagging behind, but it's on the developer to ensure that their code merges into master smoothly (usually best done by syncing your feature branch back up to master frequently)
mkchoi212 7y ago
So cool that something Linus Torvalds made to solve his own problems, spread all around the world so quickly. I guess great dev tools can only be made by great developers, who have been through a lot of scenarios/problems themselves.
- zwieback 7y ago
  What's interesting to me is that git does not seem like a "great dev tool" when you first start using it, especially if you're already used to another VCS. Right now I'm using SVN, Perforce and git for different projects and I definitely like git the most, but it took a while to get there. And it's not the centralized vs. decentralized per se, like 99.9% of git users I'm almost always within milliseconds of a central server. The big change was to treat my development "as-if" I was doing my own thing, decentralized, when in fact I'm not.
- bmn__ 7y ago
  Don't neglect to give enough credit to BitKeeper, the DVCS some kernel folks used before and whose design in broad strokes was cloned by Linus.
  - koreth1 7y ago
    Or even further back: BitKeeper was a successor to an earlier DVCS from the early 1990s, Sun Workshop TeamWare. Everything old is new again.
yodsanklai 7y ago
Reading the comments, I realize I'm a git neophyte (limited experience working on some open source software, didn't know "gitflow" was a thing) so excuse me for my naive question. But what about this simple workflow. Developers submit PR on top of a master branch (developer is in charge of rebasing, PR must pass integration test). Administrator is in charge of merging, maintains a linear history. Releases are just tags on master. Has this workflow a name? anything wrong with it?
- kubanczyk 7y ago
  A year after you release v1.0.0 (which you say is a tag), a customer reports a bug in it. They don't want a breaking upgrade to v9.13.0. They want to pay for v1.0.1 (aka "hotfix"). But you can't open a PR against a tag v1.0.0. Hence you discover that v1.0 should be a branch, and both v1.0.0 and v1.0.1 tags. This way you can open a PR against v1.0 and easily create v1.0.1, v1.0.2, etc. Another problem. You are at "master" and approach v13.0.0. But there are numerous bugs to fix before you release. Testing takes >24 hours. You choose to work on bugs on a branch (v13.0) this way master can proceed with new features and not be feature-frozen for days or weeks. Another problem. Your CI is deficient in that it allows merging and cloning before it makes sure that previous merge produced good product. Puny as it is, it is the current industry standard. Thus your main branch becomes broken now and then. So you call it "develop" and only merge it to "master" what you are sure is a good product. If these common situations don't apply to you - proceed as you are. Do the simplest thing possible, but not simpler. What you've described doesn't create any roadblock or dead end street for the project.
  - deepersprout 7y ago
    > A year after you release v1.0.0 (which you say is a tag), a customer reports a bug in it. They don't want a breaking upgrade to v9.13.0. They want to pay for v1.0.1 (aka "hotfix"). > But you can't open a PR against a tag v1.0.0. Hence you discover that v1.0 should be a branch, and both v1.0.0 and v1.0.1 tags. This way you can open a PR against v1.0 and easily create v1.0.1, v1.0.2, etc. So you could just `git checkout v1.0.0; git checkout -b v1.0`, commit your hotfix and deploy v1.0.1. > Another problem. You are at "master" and approach v13.0.0. But there are numerous bugs to fix before you release. Testing takes >24 hours. You choose to work on bugs on a branch (v13.0) this way master can proceed with new features and not be feature-frozen for days or weeks. Or you could use topic branches for new features, and fix bugs on master at the same time. > Another problem. Your CI is deficient in that it allows merging and cloning before it makes sure that previous merge produced good product. Puny as it is, it is the current industry standard. Thus your main branch becomes broken now and then. So you call it "develop" and only merge it to "master" what you are sure is a good product. I don't understand your point here. Usually your CI builds a branch, runs some tests on the compiled product and makes sure the `master` branch is ok before deploying to staging or production. > If these common situations don't apply to you - proceed as you are. Do the simplest thing possible, but not simpler. What you've described doesn't create any roadblock or dead end street for the project. I think there are a lot of branching strategies for a reason. Your use cases can be covered with other branching strategies as well.
edpichler 7y ago
I love this branching model. I have being used in all projects and teams I can. I use it even in projects where I work alone. For me it is the ultimate branching model.
- sguav 7y ago
  Same for me, I see many comments about this not being ideal for scalable projects or Saas, but in my experience gitflow has worked well even for maintaining pcb design repositories!
  - edpichler 7y ago
    For me it is being super good in scalable projects, and together with well oiled CICD pipelines.
kureikain 7y ago
A problem with GitFlow is it's painful to follow PR model. Especially on the Github repository where pushing to master is a lock and can only done by PR and merge(or squash or whatever). Let's take a look at a release: 1. Branch of release/1.0 from develop 2. Fix some bug, then at the time of deploymennt. Merge it back to master and develop But once we merge, github close the PR... If we attempt to create another PR for other branch. The Github now see different history between master/develop...
- cfstras 7y ago
  There exist scripts and workflows to perform auto-merges from all release branches back to master. This way, you only have to care about branching off releases, and hotfixes will automatically land on develop once released. (Assuming master is your "next release", and develop is your main development branch)
  - kureikain 7y ago
    Like I said, I cannot merge because we cannot push from our computer to Github(It's locked). The only way to get code into branch is by doing a PR, and click merge button on Github UI. But a PR cannot be merged twice. And If I open two PRs two master/develop then I will see this kind of error on Github: "This branch is 1 commit behind. 1 commit ahead of develop"
    - cfstras 7y ago
      the way to go here is probably creating an "administrator" account which is used by those merging scripts, and allow push access to protected branches for administrators.
      - dillonmckay 7y ago
        So, on my team, juniors can create feature branches and easily deploy a feature branch to a ‘staging’ server. If the feature is deemed good, an ‘admin’ will ‘finish’ the feature and it is merged into develop branch. Then, when we are ready for a release, the ‘admin’ will create a release and both develop and master are updated. Updating master triggers a webhook that deploys the release. For a hotfix, the release step is skipped, but both develop and master are updated, again causing the webhook to trigger a deployment.
deleted 7y ago
[deleted]
juped 7y ago
I accept your apology. History is for reading, not writing. Do we make decisions that give us readable and informative histories? The people who give up and rebase absolutely everything into one linear trunk are not working optimally, but at least they're trying.
ggm 7y ago
I have never succeeded in working in a branch and having the real owners accept my state. I am of course talking about 'outsider' changes to code, but the effect is real: the master owner can elect to say "sorry, we decided to re-architect significantly and what you did is now superfluous, or at least too hard for us to re-integrate" and almost everything I have been involved with, this is what happened. Submitting small patches to their head state is more effective for me than trying to maintain state against a moving target with a realistic chance of making significant change, and having it accepted into the mainline.
keithnz 7y ago
We started with gitflow, but our team ended up going with a Release based branching system as the constant integration of various features ended up giving less control on what to deploy and when. Most common scenario... Devs create feature branches from master Features will be targeted to a release at some point, Release branch gets taken from master Devs PR feature branches to the release branch Release branch merges back to master on deployment.
- rojobuffalo 7y ago
  that workflow has always been my preference. QA can review features in batches, you can schedule releases to minimize impact, and several eyes are on the release to catch possible bugs.

199 points by nilsandrey 7y ago

Strongly agreed with the new author note. I used the same ideas with the teams I've been coaching: "Consider your context...." as the need or not of support for multiple versions and "...Decide for yourself.

umvi 7y ago

I tried using Gitflow on our team, but there was too much complexity for me. We ended up switching to Trunk Based Development (TBD)[1] which I and my team found to be much simpler. [1] https://trunkbaseddevelopment.com/ https://trunkbaseddevelopment.com/

wcarss 7y ago
+1 to trunk based. There's obviously a lot there, but one of the best bits is the idea that each release deserves a branch. It makes hotfixes, ci/cd, and rollbacks all much simpler to reason about.
alexbanks 7y ago
I didn't know there was a name for this, but I've been doing it for 2 years now and I don't think I could go back.
- obelos 7y ago
  Same here. My team has been managing our git repo like this for years, but I didn't realize there was a named practice around it.
  - mixmastamyk 7y ago
    It was the way in the svn days and common before. But folks attracted to git are often the same that like to desimplify things.
billti 7y ago
I would love all the hours back I spent in discussions around branching strategy, trying to keep complex models understood across the team (and myself), dealing with painful merges and flowing changes through, trying to figure out if a change is in a branch already, etc.. It's so much simpler and more productive if everyone works in master, with new features behind a flag if need be, with just critical fixes ported to release branches. There will always be arguments for why a more complicated branch strategy needs to be introduced. Resist those arguments. In my experience, the cost rarely pays for any benefits. Writing good software is hard enough already.
- sethammons 7y ago
  We work on a branch and merge to master only after code review and (usually) quality assurance. We also deploy asap after merging to master and passing all regression tests. We can and often do deploy the same service many times a day.
zoomablemind 7y ago
Same here. Trunk based is easy to explain and enforce. The only challenge we faced was maintaining patch releases. Folding in fixes for common issues which were found in newer releases sometimes involved more than just cherrypicking the fix into a patch release for an older version. This inevitably led to asking users to update to more up-to-date versions. This further enforced the linear development paradigm.
- gregmac 7y ago
  This is the one thing that I find lacking in trunk-based development. I work on multiple products that have a release branch for each minor release, and it works incredibly well other than this as a minor pain point. I find the easiest way is that if you know you want (or even think you might want) a particular fix in a patch version, you can make a branch from the oldest release branch you want to support. When you create a PR, you can easily target to the release branch (or another later release branch) or master, depending on what you want. You can even do multiple PRs to merge it multiple places. No matter how you go about it, it should always be safe to merge a release branch back into master. In fact, this is a good thing to do after you release a patch version, but can also be done whenever you need a particular fix in newer (master, or other feature branch code) code immediately. Merging release branches like this makes following a fix significantly easier than if you do it with cherry picking. Consider if you're looking at bug ticket, and trying to figure out what branches/releases it was fixed in. If the PR was merged to master, then later cherry picked to an older release, all you'll see is it was in master. Unless someone manually comments about it or your tooling picks it up based on references, the only other thing to do is check the code itself to see if the fix is there. When you instead merge forward, even if the ticket comments are wrong or not there, you can literally follow the branches from the PR/commits and see every release it got into.
  - brandmeyer 7y ago
    > Unless someone manually comments about it or your tooling picks it up based on references. I don't find this to be overly burdensome on the tooling. If the ticket-tracking system can't automate traceability between git commits and tickets, then it isn't well-suited to git-based software development. We use the following policy: - A bugfix commit must fix the bug, the whole bug, and nothing but the bug. If that seems impractical for the task at hand, make it practical by breaking up the bug's ticket into smaller elements. - Bugfix commits always cite the bug tracking system's ticket number. - The bug tracking system observes the git tree and maintains its own linkage to it. - When cherry-picking the bugfix to other affected branches, pass the `-x` argument to `git cherry-pick`. That's it. The (cherry-picked from) comment helps out when just viewing the git history on its own. And the bug tracking system lets you quickly see all of the commits and pull requests that referred to the bug.
Legion 7y ago
Trunk based using short lived feature branches is the only thing I've used that has made any sort of sense in terms of value vs. complexity.
bosswipe 7y ago
TBD is fine for web apps, but not for software that you have to maintain multiple versions in the wild at the same time or when the release cycle takes several weeks.
- wikibob 7y ago
  So...shouldn't the focus be fixing the fact that release cycles take several weeks? This is well researched and discussed in Nicole Forsgren's book: Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations https://www.amazon.com/Accelerate-Software-Performing-Technology-Organizations/dp/1942788339 https://www.amazon.com/Accelerate-Software-Performing-Techno...
  - brandmeyer 7y ago
    Sometimes long test cycles are just the nature of the business, especially in hardware-software co-development, and especially in high-reliability development. Nobody will believe that running software tests on a workstation or server somewhere counts for release readiness if it gets deployed to a wind turbine, robot, or megawatt UPS. The software team's automated tests indicate that the software is ready to start an expensive physical testing cycle, not that its ready to go to the field.
- lilbobbytables 7y ago
  That isn't true at all. Trunk based is perfect for this because you have the clean release branches from the trunk. I've worked in large companyies very successfully using TBD and releasing quarterly to enterprise customers using our software on their systems.
  - blondin 7y ago
    > I've worked in large companyies very successfully using TBD and releasing quarterly to enterprise customers using our software on their systems. care to elaborate? curious about those companies and the software you are talking about. i totally see the trunk based process work for software that doesn't need to maintain multiple versions as the original commenter said. but for multi-versioned software you can't afford to have a single trunk and let your developers have a go at it. i went and checked the repos for some of the multi-versioned software that i use that are open-source. well confirmed.
jpswade 7y ago
Absolutely agree. I think git flow makes sense to begin with however once you start to do CI/CD, you need something a bit more robust. Trunk based development gives you that. No long lived branches. No merge hell. It’s considerably better.
- mixmastamyk 7y ago
  I’d argue that starting simple and adding complexity only when needed is a better strategy.
mcv 7y ago
The thing I don't get about trunk-based development is: if everybody always pushes straight to master, how do you do code review? Or don't you do code review in TBD? I like having explicit pull requests where a new feature can be reviewed.
- deleted 7y ago
  [deleted]
- adrianmsmith 7y ago
  That link does say that you can use pull requests for merging the short-lived feature branches back into master. It says that, for small teams, pushing directly into master might be acceptable (presumably without code review).
  - mcv 7y ago
    But how short-lived can they be? Feature development isn't necessarily short. Reviewing bits and pieces of a feature without having the whole thing together may not be very informative. And small teams may also care about code review.

gulbrandr 7y ago

Is this related to the "Please stop recommending Gitflow" [1] article posted yesterday? [1] https://news.ycombinator.com/item?id=22485489 https://news.ycombinator.com/item?id=22485489

deleted 7y ago
[deleted]
sytse 7y ago
Kind of, that article recommends making things less complex if you do continuous delivery to a SaaS. The update article mentions it was meant for versioned software. I tried to articulate the various levels of branching you need in GitLab Flow https://docs.gitlab.com/ee/topics/gitlab_flow.html https://docs.gitlab.com/ee/topics/gitlab_flow.html The various levels are: feature branches, production branches, environment branches, and release branches.
- waheoo 7y ago
  Sounds like gitlab tried to fix githubflow instead of realising its fundamentally broken and going with the gerrit pattern that works fine for both trunk based and release style applications.
  - sytse 7y ago
    We offer multiple options that depend on your need. GitHub flow and Git flow are at two ends but there are also intermediate steps.

arghskwidge 7y ago

AFAICT Gitflow just has one more branch than it needs. If you got rid of the master branch and supported production releases off release branches it would be just as useful and significantly less complicated. Can anyone explain to me what real value the master branch adds in this model? And without using fluffy meaningless words like, "source of truth," please.

Chilinot 7y ago
I fully agree. Removing the master branch which is just fluff that noone uses you essentially come to trunkbased development.
raziel2p 7y ago
The main advantage I can think of is you can just configure your nightly expensive CI jobs (running absolutely all e2e tests) to run against a static branch. Another might be that git clone gets the "correct" branch by default. Might be important if your git repo gets cloned by sales, support or whatever for external demo purposes. Anyway I don't think it makes a huge difference in complexity - it's rarely used for developers' workflows and doesn't even need to be updated that often.
- pdpi 7y ago
  How meaningful is it to run build/test against a branch that is reflective neither of a release branch nor a feature branch, though?
  - amrox 7y ago
    For mobile apps and SDKs I found it very useful to keep a pointer to the current production version (master) for integration tests.
jordigh 7y ago
I don't really understand the distinction between develop and master either. You're supposed to branch off develop and merge forward back into develop, then merge into a release branch, then merge into master. So everything in develop is supposed to end up in master. So... why not branch off master and merge back into master?

cjfd 7y ago

It all depends on the situation. The simplest possible situation of mostly just having a master branch also can work quite well. When you have specialized testers that test a candidate release you start to need release branches. Feature branches start being necessary if changes are temoprarily incompatible with current master. This should not be too common, though. In many cases one can avoid feature branches by having feature switches that get removed as soon as a feature is done. If one wants to or needs to use feature branches they should be short-lived because one will be creating a merge hell if this is not the case. The git flow seems just too complicated for most cases. One comment already notices that it is quite unclear why a separate development and master branch are necessary.

debaserab2 7y ago

I've yet to work on a codebase that was so congested it required such strong delineation between feature/hotfix/release but I can see how it might be required at a certain size. I wonder what that threshold is.

stickydink 7y ago
It depends what you're working on. We have a fairly small team (7 engineers) working on a reasonably complex app (many features). Our "features" take anything from 1 day to 3 weeks of effort, and generally need to roll out as a whole. They are often really upgrades of existing features, and the work to continuously merge w/ feature flags, supporting both flows/designs, is just not something we've felt was worth the extra time. We release on a 2 week cycle, the same day each time. We merge our features into the develop branch as they are ready and safe for production. Our scheduled release day is Wednesday. The Thursday beforehand, we branch from develop into a release/x.y.0. This builds release candidates. We have a sanity check on Friday, then our remote QA team runs through them over the weekend. Any issues they find, we try to have squared away by Monday, Tuesday at the latest. Meanwhile other team members are still merging new things into develop. It's useful to have that release branch because it lets the rest of the team keep moving - we maybe only put out 1 or 2 developer's features each cycle, the rest are still trickling in. Once we release, we tag, merge into master, and start over again. If any issues show up on production, we use the hotfix branch, hotfix/x.y.z. That let's us resolve issues with risking a ship of any of the changes that have come into develop that haven't had a few days of stability behind it. For our team scale, we have a lot of users (100k's DAU), and we find this method is a nice balance between the pace of output you might get from true CI but with the reliability of a more traditional cycle. Backend and web projects, however... Straight CI, into master, and we roll out test > staging > production when we're happy.
- debaserab2 7y ago
  I basically follow the same protocol as you up to this point: > Once we release, we tag, merge into master, and start over again. If any issues show up on production, we use the hotfix branch, hotfix/x.y.z. That let's us resolve issues with risking a ship of any of the changes that have come into develop that haven't had a few days of stability behind it. In our case, there's no point in a hotfix branch because master is always considered stable. You don't merge to master unless you're ready for that code to hit production. Feature gates are used for hiding live code when necessary for marketing announcements or if the feature simply isn't ready for actual customer usage yet (sometimes we leave the endpoints live but turn off all the navigation to the endpoint so we can send out the link as a "beta" test for specific customers). This does occasionally cause problems with feature branches lagging behind, but it's on the developer to ensure that their code merges into master smoothly (usually best done by syncing your feature branch back up to master frequently)

mkchoi212 7y ago

So cool that something Linus Torvalds made to solve his own problems, spread all around the world so quickly. I guess great dev tools can only be made by great developers, who have been through a lot of scenarios/problems themselves.

zwieback 7y ago
What's interesting to me is that git does not seem like a "great dev tool" when you first start using it, especially if you're already used to another VCS. Right now I'm using SVN, Perforce and git for different projects and I definitely like git the most, but it took a while to get there. And it's not the centralized vs. decentralized per se, like 99.9% of git users I'm almost always within milliseconds of a central server. The big change was to treat my development "as-if" I was doing my own thing, decentralized, when in fact I'm not.
bmn__ 7y ago
Don't neglect to give enough credit to BitKeeper, the DVCS some kernel folks used before and whose design in broad strokes was cloned by Linus.
- koreth1 7y ago
  Or even further back: BitKeeper was a successor to an earlier DVCS from the early 1990s, Sun Workshop TeamWare. Everything old is new again.

yodsanklai 7y ago

Reading the comments, I realize I'm a git neophyte (limited experience working on some open source software, didn't know "gitflow" was a thing) so excuse me for my naive question. But what about this simple workflow. Developers submit PR on top of a master branch (developer is in charge of rebasing, PR must pass integration test). Administrator is in charge of merging, maintains a linear history. Releases are just tags on master. Has this workflow a name? anything wrong with it?

kubanczyk 7y ago
A year after you release v1.0.0 (which you say is a tag), a customer reports a bug in it. They don't want a breaking upgrade to v9.13.0. They want to pay for v1.0.1 (aka "hotfix"). But you can't open a PR against a tag v1.0.0. Hence you discover that v1.0 should be a branch, and both v1.0.0 and v1.0.1 tags. This way you can open a PR against v1.0 and easily create v1.0.1, v1.0.2, etc. Another problem. You are at "master" and approach v13.0.0. But there are numerous bugs to fix before you release. Testing takes >24 hours. You choose to work on bugs on a branch (v13.0) this way master can proceed with new features and not be feature-frozen for days or weeks. Another problem. Your CI is deficient in that it allows merging and cloning before it makes sure that previous merge produced good product. Puny as it is, it is the current industry standard. Thus your main branch becomes broken now and then. So you call it "develop" and only merge it to "master" what you are sure is a good product. If these common situations don't apply to you - proceed as you are. Do the simplest thing possible, but not simpler. What you've described doesn't create any roadblock or dead end street for the project.
- deepersprout 7y ago
  > A year after you release v1.0.0 (which you say is a tag), a customer reports a bug in it. They don't want a breaking upgrade to v9.13.0. They want to pay for v1.0.1 (aka "hotfix"). > But you can't open a PR against a tag v1.0.0. Hence you discover that v1.0 should be a branch, and both v1.0.0 and v1.0.1 tags. This way you can open a PR against v1.0 and easily create v1.0.1, v1.0.2, etc. So you could just `git checkout v1.0.0; git checkout -b v1.0`, commit your hotfix and deploy v1.0.1. > Another problem. You are at "master" and approach v13.0.0. But there are numerous bugs to fix before you release. Testing takes >24 hours. You choose to work on bugs on a branch (v13.0) this way master can proceed with new features and not be feature-frozen for days or weeks. Or you could use topic branches for new features, and fix bugs on master at the same time. > Another problem. Your CI is deficient in that it allows merging and cloning before it makes sure that previous merge produced good product. Puny as it is, it is the current industry standard. Thus your main branch becomes broken now and then. So you call it "develop" and only merge it to "master" what you are sure is a good product. I don't understand your point here. Usually your CI builds a branch, runs some tests on the compiled product and makes sure the `master` branch is ok before deploying to staging or production. > If these common situations don't apply to you - proceed as you are. Do the simplest thing possible, but not simpler. What you've described doesn't create any roadblock or dead end street for the project. I think there are a lot of branching strategies for a reason. Your use cases can be covered with other branching strategies as well.

edpichler 7y ago

I love this branching model. I have being used in all projects and teams I can. I use it even in projects where I work alone. For me it is the ultimate branching model.

sguav 7y ago
Same for me, I see many comments about this not being ideal for scalable projects or Saas, but in my experience gitflow has worked well even for maintaining pcb design repositories!
- edpichler 7y ago
  For me it is being super good in scalable projects, and together with well oiled CICD pipelines.

kureikain 7y ago

A problem with GitFlow is it's painful to follow PR model. Especially on the Github repository where pushing to master is a lock and can only done by PR and merge(or squash or whatever). Let's take a look at a release: 1. Branch of release/1.0 from develop 2. Fix some bug, then at the time of deploymennt. Merge it back to master and develop But once we merge, github close the PR... If we attempt to create another PR for other branch. The Github now see different history between master/develop...

cfstras 7y ago
There exist scripts and workflows to perform auto-merges from all release branches back to master. This way, you only have to care about branching off releases, and hotfixes will automatically land on develop once released. (Assuming master is your "next release", and develop is your main development branch)
- kureikain 7y ago
  Like I said, I cannot merge because we cannot push from our computer to Github(It's locked). The only way to get code into branch is by doing a PR, and click merge button on Github UI. But a PR cannot be merged twice. And If I open two PRs two master/develop then I will see this kind of error on Github: "This branch is 1 commit behind. 1 commit ahead of develop"
  - cfstras 7y ago
    the way to go here is probably creating an "administrator" account which is used by those merging scripts, and allow push access to protected branches for administrators.
    - dillonmckay 7y ago
      So, on my team, juniors can create feature branches and easily deploy a feature branch to a ‘staging’ server. If the feature is deemed good, an ‘admin’ will ‘finish’ the feature and it is merged into develop branch. Then, when we are ready for a release, the ‘admin’ will create a release and both develop and master are updated. Updating master triggers a webhook that deploys the release. For a hotfix, the release step is skipped, but both develop and master are updated, again causing the webhook to trigger a deployment.

deleted 7y ago

[deleted]

juped 7y ago

I accept your apology. History is for reading, not writing. Do we make decisions that give us readable and informative histories? The people who give up and rebase absolutely everything into one linear trunk are not working optimally, but at least they're trying.

ggm 7y ago

I have never succeeded in working in a branch and having the real owners accept my state. I am of course talking about 'outsider' changes to code, but the effect is real: the master owner can elect to say "sorry, we decided to re-architect significantly and what you did is now superfluous, or at least too hard for us to re-integrate" and almost everything I have been involved with, this is what happened. Submitting small patches to their head state is more effective for me than trying to maintain state against a moving target with a realistic chance of making significant change, and having it accepted into the mainline.

keithnz 7y ago

We started with gitflow, but our team ended up going with a Release based branching system as the constant integration of various features ended up giving less control on what to deploy and when. Most common scenario... Devs create feature branches from master Features will be targeted to a release at some point, Release branch gets taken from master Devs PR feature branches to the release branch Release branch merges back to master on deployment.

rojobuffalo 7y ago
that workflow has always been my preference. QA can review features in batches, you can schedule releases to minimize impact, and several eyes are on the release to catch possible bugs.