Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A successful Git branching model (2010)

nvie.com

Post reply on HN
Print view View original

51–60 of 121 posts

Re: A successful Git branching model (2010)

#51

Post by bbatha »

ryanbrunner wrote: post #32
mabbo wrote: post #15

I've got a much nicer branching model- try not to have one. Everyone works off master, and you aren't allowed to check in code that won't run in production. Hide unfinished features behind feature flags, and never merge/push a change that won't pass tests/CI. The chaos of huge feature merges (a key source of bugs I've experienced) is minimized. You deploy fixes hourly, not weekly (or later monthly when it just won't…

I think from the perspective of the central repository, this is a sane approach. Locally though, you should still be routinely using (short-lived) feature branches. Working directly off master on your local machine can make things annoying / complicated when you need to move away from your work for a moment (say to fix a bug) and don't have a good representation of "what's currently on production". Also, I think this…

Depending on the frequency of your deploys you can simply add release branches or tags to the “work on master” model. Any decent deployment system can deploy from an arbitrary arbitrary ref, plus release history in your git log is very useful. The point here is to eliminate long lived feature branches that require their own maintenance.

Re: A successful Git branching model (2010)

#52

Post by dboreham »

mabbo wrote: post #15

I've got a much nicer branching model- try not to have one. Everyone works off master, and you aren't allowed to check in code that won't run in production. Hide unfinished features behind feature flags, and never merge/push a change that won't pass tests/CI. The chaos of huge feature merges (a key source of bugs I've experienced) is minimized. You deploy fixes hourly, not weekly (or later monthly when it just won't…

Exactly. I've never understood the obsession with minor branching. Actually now we never ship software in a box major branches typically aren't needed either. The insanity goes back way before git but git seems to have driven it to "11".

Re: A successful Git branching model (2010)

#53

Post by jasode »

mabbo wrote: post #27
sillysaurus3 wrote: post #19

Earlier quoted context omitted.

Feature flags are a nice idea, but nobody outside of Facebook seems to be embracing them. The tooling just isn't there. Some concrete questions: - How do you prevent your codebase from becoming if-statement spaghetti? - How do you prevent new features from being leaked to the user? They'll see the new features in the front end source code. At many companies this isn't an acceptable tradeoff. So do you preprocess the…

> How do you prevent your codebase from becoming if-statement spaghetti? A valid point- if you're not careful that can happen. Key things: remove those ifs after a launch, and launch fully or remove the feature; consider 'hiding' the ifs behind factories that build the objects that implement the different logic; also, if you have 20 features is development for the same area of your codebase, worry- you may be trying…

>A valid point- if you're not careful that can happen. Key things: remove those ifs after a launch

I think a big factor that's unspoken about "trunk-based-master" development is that it fits better with "website apps" such as Facebook and Etsy. The "live website" can be thought of as a "single executable" and trunk-based mental model maps well to that. The feature-flags as a replacement for branches doesn't result in an unusable combinatorial explosion. There are minimal # of "alternate universes" of Facebook... maybe a "Facebook for internal engineers" etc. You can tame that with feature-flags.

However, for corporate development where the output is "exe" files... e.g. version 2.x of product has dependencies on a old version of a library and a version 3.x uses a totally different architecture with different conflicting dependencies... you can't model that code evolution in a clean manner with feature-flag "if" statements. If you move the "if" statements outside of the code and into preprocessors (#ifdef) or the "build" system such as cmake, you've just shifted the problem around instead of solving it. Branches instead of feature-flags are cleaner and more sane for certain domains.

Re: A successful Git branching model (2010)

#54

Post by latencyloser »

sillysaurus3 wrote: post #19
mabbo wrote: post #15

I've got a much nicer branching model- try not to have one. Everyone works off master, and you aren't allowed to check in code that won't run in production. Hide unfinished features behind feature flags, and never merge/push a change that won't pass tests/CI. The chaos of huge feature merges (a key source of bugs I've experienced) is minimized. You deploy fixes hourly, not weekly (or later monthly when it just won't…

Feature flags are a nice idea, but nobody outside of Facebook seems to be embracing them. The tooling just isn't there. Some concrete questions: - How do you prevent your codebase from becoming if-statement spaghetti? - How do you prevent new features from being leaked to the user? They'll see the new features in the front end source code. At many companies this isn't an acceptable tradeoff. So do you preprocess the…

The project I work on at Microsoft uses feature flags. I see it with many Azure services as well. I can testify that it is absolutely if-statement hell, at least in the areas that rely on these feature flags. However, I will say I think 'lazy programming' is more the issue than the flags themselves. For example, isolating feature specific behavior to it's own impl and using an abstract class to share common behavior--that sort of basic stuff gets skipped in favor of 'time'.

Thankfully these are all obscured from the user for the most part.

We have a 'control panel' like thing that we used to enable/disable feature switches. It works well for its use case and let's us enable/disable with as much granularity as we want.

Re: A successful Git branching model (2010)

#55

Post by mbrock »

damnyou wrote: post #21
mabbo wrote: post #15

I've got a much nicer branching model- try not to have one. Everyone works off master, and you aren't allowed to check in code that won't run in production. Hide unfinished features behind feature flags, and never merge/push a change that won't pass tests/CI. The chaos of huge feature merges (a key source of bugs I've experienced) is minimized. You deploy fixes hourly, not weekly (or later monthly when it just won't…

This is called trunk-based development, and it is the only development model that scales to thousands of engineers in one repository.

It's also called "continuous integration."

As in everyone continuously integrates their changes, and you strongly discourage divergence.

https://en.wikipedia.org/wiki/Continuous_integration

In software engineering, continuous integration (CI) is the practice of merging all developer working copies to a shared mainline several times a day.

https://martinfowler.com/articles/continuousIntegration.html...

One of the features of version control systems is that they allow you to create multiple branches, to handle different streams of development. This is a useful, nay essential, feature - but it's frequently overused and gets people into trouble. Keep your use of branches to a minimum. In particular have a mainline: a single branch of the project currently under development. Pretty much everyone should work off this mainline most of the time. (Reasonable branches are bug fixes of prior production releases and temporary experiments.)

Re: A successful Git branching model (2010)

#56

Post by twunde »

sillysaurus3 wrote: post #31
hoorayimhelping wrote: post #29

Earlier quoted context omitted.

> Feature flags are a nice idea, but nobody outside of Facebook seems to be embracing them I worked at Etsy from early 2012 to late 2015 and I used feature flags every day I was there. > How do you prevent your codebase from becoming if-statement spaghetti? You remove the feature flag checking code when you turn off or turn on the feature. It's an extra deploy, but it needs to be part of the prod/eng process. This is…

You remove the feature flag checking code when you turn off or turn on the feature. It's an extra deploy, but it needs to be part of the prod/eng process. This is the most salient issue of feature flagging in my experience and something you need to get ahead of from the get-go. I don't understand. I was asking about the development source code, not the code delivered to the user. The dev source code isn't stripped of…

Most languages have FOSS feature flag libraries. One that comes to mind is waffle for python/django.

Re: A successful Git branching model (2010)

#57

Post by mbrock »

shandor wrote: post #18
sillysaurus3 wrote: post #14

Earlier quoted context omitted.

I was researching some of this a few weeks ago, and there are many posts about tags being a bad idea. The arguments are that they have to be maintained separately and they lack context. But yes, master branch master race. Also related: "What are the problems with 'a successful Git branching model'?" https://barro.github.io/2016/02/a-succesful-git-branching-mo... Speaking of bad ideas, anyone want to weigh in on merge…

I always advocate workflows where merges never happen. To me, the 'git log' of a master branch is like a history book about the repository. When you read through it, it should give you answers to the questions "what was changed, why, and when" in as clear format as possible. Now, I've read most of the arguments trying to show that merges are the way to do just this, instead of rewriting history with interactive rebas…

I'm not sold on the idea of the master log as a readable narrative.

If you really want to maintain such a narrative, it would be possible to do it separately, in something like a changelog.

You might even hire someone to do that, a kind of technical historian. It's real work, because software development is pretty messy.

If you reaaally care about the history of the software's development, I would seriously consider aggressive rebasing of the repository even much later -- you could refactor the commit history as much as you want to clarify the logical progression of the software.

As I see it, a source code repository is not like a history book, because a history book is written after the fact by a trained historian who spends a lot of energy on tidying up the narrative and making it actually comprehensible.

A source code repository looks to me more like an archaelogical artifact with some terse notes sprinkled in there as clues by the various workers.

Basically I think the git log structure is kind of overblown and workflow arguments that hinge on the legibility of the repository's graph structure don't really matter that much to me.

I still sometimes write pretty involved commit messages, but that's a kind of separate issue from these "workflow" discussions that are mostly about how you should formally arrange the DAG. And I also know that my commit messages are mostly lost in time like tears in rain, so I try to communicate important changes in other ways.

Re: A successful Git branching model (2010)

#58

Post by vermooten »

mabbo wrote: post #15

I've got a much nicer branching model- try not to have one. Everyone works off master, and you aren't allowed to check in code that won't run in production. Hide unfinished features behind feature flags, and never merge/push a change that won't pass tests/CI. The chaos of huge feature merges (a key source of bugs I've experienced) is minimized. You deploy fixes hourly, not weekly (or later monthly when it just won't…

mabbo you are right, it's how we do it and it's hyper-efficient. Last place I worked used OP's model it worked ok but wasn't as efficient.

Re: A successful Git branching model (2010)

#59

Post by dahart »

mabbo wrote: post #15

I've got a much nicer branching model- try not to have one. Everyone works off master, and you aren't allowed to check in code that won't run in production. Hide unfinished features behind feature flags, and never merge/push a change that won't pass tests/CI. The chaos of huge feature merges (a key source of bugs I've experienced) is minimized. You deploy fixes hourly, not weekly (or later monthly when it just won't…

Personally, I wouldn't argue for one or the other being nicer, they each have strong use cases at different times.

I like to use feature flags for: 1- features that need to be A/B tested, 2- huge features that dev lasts for more than 1-2 weeks, 3- features that take more than a small handful of people to either write or test.

I like to use branches for: 1- code that definitely should not be inflicted on other teams until ready, 2- features that take between 3 days and a week or two, relatively short cycle, and 3- features that need more than one person and/or more than one commit to finish, but less than maybe half a dozen.

Assuming it doesn't impact the code review process, I like to commit to master directly, without a feature flag, for: 1- any small features contained in a single commit written by a single person, and 2- hot patches and bug fixes that roll in after merge.

Re: A successful Git branching model (2010)

#60

Post by skrebbel »

ryanbrunner wrote: post #32
mabbo wrote: post #15

I've got a much nicer branching model- try not to have one. Everyone works off master, and you aren't allowed to check in code that won't run in production. Hide unfinished features behind feature flags, and never merge/push a change that won't pass tests/CI. The chaos of huge feature merges (a key source of bugs I've experienced) is minimized. You deploy fixes hourly, not weekly (or later monthly when it just won't…

I think from the perspective of the central repository, this is a sane approach. Locally though, you should still be routinely using (short-lived) feature branches. Working directly off master on your local machine can make things annoying / complicated when you need to move away from your work for a moment (say to fix a bug) and don't have a good representation of "what's currently on production". Also, I think this…

A hotfix branch fixes this. You can still do trunk based development for the rest, and cherry pick the bugfixes into such a hotfix branch (branches off from the latest commit that was released).
Post reply on HN