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

61–70 of 121 posts

Re: A successful Git branching model (2010)

#61

Post by activatedgeek »

It is good exercise to actually learn this branching model and then use it in practice. You will soon realize that most projects will suddenly start taking unnecessary toll on you just because now you want to maintain multiple branches and it is a huge PITA.

Instead just follow this simple routine - stay as close to the master as possible. If a temporary diversion is needed, create a new branch (and maintain both master and the diversion for a while). Delete the diversion once the job is done.

If you are never able to delete the diversion, it is not your git branching model that failed, it is you and your code who failed. Diversions may be long term (and I hope you have the workforce to maintain that branch as well) but still finite time. How to prepare that diversion is a software engineering problem and not git's fault.

Re: A successful Git branching model (2010)

#62

Post by aaimnr »

hoorayimhelping wrote: post #36
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 expectation of a bunch of weird branches making everything confusing (I had that too) ends up being unfounded. You typically only see a few places with branching logic, and people usually draw attention to it being branching logic for a feature or experiment. How and where you branch really depends on the feature. If you're A/B testing a button color, you'll deploy a different strategy than if you're trying to in…

> Let's say you're writing a crud app on an express server that communicates via http to a database service.

As a side note - a 'database service' that's only job is to serve as an HTTP wrapper over DB seems like an anti-pattern. Service boundaries here are not related to any business concern (if you're thinking along the SOA lines) and rewriting already existing DB remote interfaces via http seems like overengineering (if you're doing n-tier architecture). Some additional reasoning on the matter by Udi Dahan: https://vimeo.com/113515335

Would be interesting to hear your thoughts if you think otherwise.

Re: A successful Git branching model (2010)

#63

Post by dahart »

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…

> 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 probably have feature flags already and just didn't call them that. But normally in any given project, there are multiple ways to wrap a feature in a toggle.

Here are a couple of examples I use:

- I use handlebars for my frontend templating. When I have a feature that needs to serve or withhold some HTML to/from the user, I put the feature flag in my JSON file of variables that get passed to handlebars. Handlebars has a way to wrap HTML with a boolean test.

- I use the Google Closure compiler to optimize, uglify, and minify my code. When I need a feature flag that is code only, and I don't want users to accidentally get exposed, I use a boolean @define in JavaScript, and wrap feature code in an if statement. When the Boolean is false, Closure compiler removes that block from the output code.

- I set up my own JSON file of config constants that are injected into the code during build. If I have a feature flag to A/B test something, or that I do want released to users but has a secret switch to enable, then I put the constant in the JSON file, and write UI code to toggle the flag. This one usually generates more code than the two above, but whenever I decide that the feature is either dead or permanent, I remove all the code to enable and disable the feature.

- For fully dynamic toggling, I put my boolean config variable into my database. I use Firebase which is a giant pub-sub, so I wrap the toggle in a subscription to the database variable, which might then (for example) inject some HTML and/or toggle the CSS display attribute of some things on my page.

> Are feature flags really so nascent that there isn't a FOSS solution for it?

No, feature flags have always been around, since long before branching. There isn't a FOSS solution for it separate from your framework(s) because how they work depends entirely on your stack. They're also normally really simple, adding the dependencies of another project just to have a boolean in your config file or in your code is usually overkill. That said, there are FOSS and commercial solutions for A/B testing, which is usually a feature flag workflow, but it comes with lots of other stuff you might not need, like the reporting, analytics and statistics parts.

Re: A successful Git branching model (2010)

#64

Post by dahart »

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…

> Feature flags are a nice idea, but nobody outside of Facebook seems to be embracing them. The tooling just isn't there.

This might be just a terminology problem. Any company that does A/B testing is using feature flags, so pretty much most of the web is using them. I'd bet more or less all programmers have them in their repos too, maybe you just call them something else, or didn't think they could be called feature flags. If you have a config file, chances are high that you have feature flags already.

For tooling, I get the feeling you're thinking of feature flags as something other than your config files and code constants. But that's it: feature flags are really simple. Add a boolean const defaulted to false in your config somewhere, and wrap the code in an if statement. When you need to A/B test or release incrementally, that's when you need extra non-trivial code around features, and that's often not something someone else can provide. Turning the feature on and off requires specific knowledge of your project's stack and UI.

Re: A successful Git branching model (2010)

#65

Post by nerdwaller »

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

Re: A successful Git branching model (2010)

#66

Post by twic »

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…

> when one reads a real book about real world history, does it look more like git log history of a repo which has been using rebase, or merge?

This is a bizarre analogy. History books are a record of things that happened in the world's timeline, which is in fact linear. Source control is a record of things which happened in the timeline of development, which is typically branched.

Imagine a history book from some terrifying PKD-esque sci-fi universe where timelines branch and re-converge. Does that look more like git log history of a repo which has been using rebase, or merge?

Re: A successful Git branching model (2010)

#67

Post by twic »

stonewhite wrote: post #12

This was very much valid before the docker workflows came to happen. Now maintaining two mainline branches forces you to break "don't build a container per environment" cardinal rule. Trunk based development should be the go-to repository strategy for dockerized apps.

That's a good rule, and a correct deduction from it. However, it's not new to Docker workflows - you shouldn't build a good old fashioned binary per environment either!

Re: A successful Git branching model (2010)

#68

Post by icebraining »

stonewhite wrote: post #49
icebraining wrote: post #34

Earlier quoted context omitted.

What's the purpose of that rule?

If you properly externalized the configurations, Docker provides bit-by-bit parity between environments granted you use the same image. This results in increased confidence to test environments and lessening the chances of a surprise during production deployments. It is the next logical step in immutable deployment paradigm[1]. [1]: https://martinfowler.com/bliki/ImmutableServer.html

But why not use the typical solution of having two testing environments, in this case based on "develop" and "master", with the latter being bit-by-bit equal to what gets deployed?

Re: A successful Git branching model (2010)

#69

Post by rtpg »

activatedgeek wrote: post #61

It is good exercise to actually learn this branching model and then use it in practice. You will soon realize that most projects will suddenly start taking unnecessary toll on you just because now you want to maintain multiple branches and it is a huge PITA. Instead just follow this simple routine - stay as close to the master as possible. If a temporary diversion is needed, create a new branch (and maintain both mas…

How does this work if you have multiple ongoing changesets?

I'm often working in 3 different features at once, all needing to be merged separately in the review process

Re: A successful Git branching model (2010)

#70

Post by stonewhite »

icebraining wrote: post #68
stonewhite wrote: post #49

Earlier quoted context omitted.

If you properly externalized the configurations, Docker provides bit-by-bit parity between environments granted you use the same image. This results in increased confidence to test environments and lessening the chances of a surprise during production deployments. It is the next logical step in immutable deployment paradigm[1]. [1]: https://martinfowler.com/bliki/ImmutableServer.html

But why not use the typical solution of having two testing environments, in this case based on "develop" and "master", with the latter being bit-by-bit equal to what gets deployed?

What purpose does it serve but to double QA efforts. If you are testing the same stuff both in develop and master, why not just test only one and save some time. Ramming gitflow into a docker workflow efficiently is not really possible I believe.
Post reply on HN