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

71–80 of 121 posts

Re: A successful Git branching model (2010)

#71

Post by mkempe »

I've used the git-flow approach successfully with a small team working on a medical product (so, embedded software system) -- every feature branch had to be reviewed before being merged with `develop`, which was submitted to nightly, extensive functional tests (initially one-hour long, eventually kept as a nightly subset of the more than 24-hours complete QA run) before it could be approved as a new (monthly) release and be merged with `master`. Every new feature branch was automatically treated to quick continuous integration tests, and available for manually-triggered full functional tests (on the target devices).

This approach ensured that we had a full trace of development work, (signed) code reviews, and software changes -- compatible with FDA audits.

We also automated collection of code coverage data during functional tests, to inform analysis and revisions of the battery of functional tests.

Re: A successful Git branching model (2010)

#73

Post by hdhzy »

sillysaurus3 wrote: post #17
jph wrote: post #16

Earlier quoted context omitted.

> What's the point of running CI on a branch that's effectively for tracking releases only? I'm recommending using master as the output of a successful continuous integration, and thus always ready for release. I'm rejecting any git flow that has any developer pushing any code directly to master, while hoping/guessing that master branch integration will succeed. Caveat: Bugs will still happen. Caveat: There are more-…

Caveat: There are more-advanced release processes such as blue/green, alpha/beta, canary/throttle, etc. What does Facebook do? It's hard to imagine that they slow themselves down this much. They tend to hide features behind feature flags, but is it known what their CI process is like?

Github pushes topic branches to production and if they don't cause troubles then merges to master. The idea is that good state is defined as works in production not just passed CI tests.

Re: A successful Git branching model (2010)

#74

Post by hdhzy »

mkempe wrote: post #71

I've used the git-flow approach successfully with a small team working on a medical product (so, embedded software system) -- every feature branch had to be reviewed before being merged with `develop`, which was submitted to nightly, extensive functional tests (initially one-hour long, eventually kept as a nightly subset of the more than 24-hours complete QA run) before it could be approved as a new (monthly) release…

Interesting. How did you do signed code reviews?

Re: A successful Git branching model (2010)

#75

Post by trjordan »

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 like feature flags, but it's crazy to suggest that they totally mitigate your risk. Some features will end up with more lines of code hiding the feature than actually implementing it. After it's released, you then have to unwind all that code. That code churn isn't trivial, and "tests pass, ship it" isn't really a good model if you're shipping blocks of work that you don't want to expose to customers.

If your releases processes are perfect, then it's OK, but CI tends to treat release as "if the tests pass, it's perfect" and ships it to all customers. At the very least, you need to be able to compare releases that "don't change anything" to make sure you're not breaking something because some edge of your feature didn't get hidden behind the flag.

Re: A successful Git branching model (2010)

#76

Post by kostarelo »

nerdwaller wrote: post #65
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 it really depends on what you’re developing and delivering. Master based development is great for end-user deliverables (web apps being the big one that comes to mind, many libraries could do this too). But if you’re writing a language or LTS releases I could see a pretty good case for a branching model like git-flow. My experience with a work using gitflow is similar to yours, it was very messy and hard to m…

> It was even worse that those driving it didn’t really know much about git so 95% of the commit messages were “Merged X into Y...” instead of using a more linear history.

How so? Why merge commits are bad? Are you suggesting of rebasing each topic branch or commiting directly to the master?

Re: A successful Git branching model (2010)

#77

Post by mkempe »

hdhzy wrote: post #74
mkempe wrote: post #71

I've used the git-flow approach successfully with a small team working on a medical product (so, embedded software system) -- every feature branch had to be reviewed before being merged with `develop`, which was submitted to nightly, extensive functional tests (initially one-hour long, eventually kept as a nightly subset of the more than 24-hours complete QA run) before it could be approved as a new (monthly) release…

Interesting. How did you do signed code reviews?

We used PRs with BitBucket for all code reviews. The reviewer(s) had to digitally sign their final approval of the review comments+answers and of the related code changes, if any.

The only way to merge a feature branch into `develop` was via the PR + code review process.

Re: A successful Git branching model (2010)

#78

Post by TheRealWatson »

skrebbel wrote: post #60
ryanbrunner wrote: post #32

Earlier quoted context omitted.

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).

Fair enough but at that point you're creating a branching model, which is what the original comment advocated against.

Re: A successful Git branching model (2010)

#79

Post by QuercusMax »

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…

There's used a ton at Google, except they're called "experiments". I believe that term comes from A/B testing, which they're still heavily used for, but they're also used for feature rollouts.

Re: A successful Git branching model (2010)

#80

Post by solatic »

dahart wrote: post #63
sillysaurus3 wrote: post #31

Earlier quoted context omitted.

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…

> The dev source code isn't stripped of if-statements, right? When I use a feature flag as an alternative to branching, then I delete the if statements once the feature becomes permananent and gets released to all users. It's analogous to merging a branch. Obviously I'd leave it there during QA and A/B testing, but once toggling is no longer necessary, I remove the toggle. > Ok, but how? Assume an express server. You…

> then I delete the if statements once the feature becomes permanent and gets released to all users

Doesn't this throw out some of the point of feature flags? That if your production servers are getting hammered, and you're having trouble scaling (for whatever reason), that you can degrade service by toggling off various features which are more resource-intensive so that your service doesn't crash entirely.

Feature toggles implemented through conditional logic seems like an anti-pattern to me. Developers make mistakes, and it's very easy to forget to wrap work around the necessary toggles and accidentally expose not-ready code in production, which may also have security consequences.

It seems to me like a better pattern would be to feature-toggle on an API level, and force developers to plan and commit to relatively stable APIs when they deploy new features to production. This is achieved through an API gateway model - a versioned API is introduced to the gateway, and new versions of services must pass integration testing proving that they adhere to that API before the API gateway will serve the new version of the service with traffic. Developers may introduce new code, and new unstable APIs, and deploy them to production, but they will not be user-facing until a new, stable API is pushed to the API gateway to serve to users. This preserves developer flexibility in pushing new work to production, without exposing that work to the user, until the feature is stabilized and ready.

Post reply on HN