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

41–50 of 121 posts

Re: A successful Git branching model (2010)

#41

Post by viraptor »

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…

> and never merge/push a change that won't pass tests/CI.

This can be enforced as well. For example using Gerrit + some CI, you can allow people to submit a branch to be merged, but it's up to the CI to merge it if it passes all checks. There's no "aren't allowed" anymore. (Which is great because people will make mistakes)

One thing to keep in mind though is you're describing a system that works for a continuously deployed web service for example. Once you have a product with versions, you need to have a system for previous releases, backporting patches, security/point updates, etc. It's a completely different game at that point.

Re: A successful Git branching model (2010)

#43

Post by viraptor »

_chris_ wrote: post #9
watt wrote: post #3

The advice here given to avoid using "master" branch for development, and advice to create non-default branch named "develop" (or variations thereof) is quite harmful. If you must have a "release" branch or "stable" branch, ok, go for it, but leave the "master" for developing. Why? Strive to have sane defaults. Frankly, the idea that somebody must check out some extra special branch after cloning repo in order to sta…

I find the idea that master is the default is exactly why it should not be the development branch. For open-source software, that's what people download and try to build -- it should always strive to be production ready.

You can have both. With the right tooling you can prevent direct push to master, but at the same time implement CI to which you can submit your branches to be merged to master.

This way you can develop against master, you won't push garbage into it by mistake, and you can guarantee that each (first-parent path) commit on master passes the automated tests.

Re: A successful Git branching model (2010)

#44

Post by Froyoh »

imron wrote: post #28
mcv wrote: post #6

For a moment I thought: Has someone figured out something better than git-flow? But no, it's the original git-flow article again. It's good, but now exactly "news". Every git user should be aware of git-flow, even if you do have a better way of using git.

> Every git user should be aware of git-flow Agree. Every git user should be aware of it and should use it on a project at least once so they know to avoid it forever after.

Why avoid it?

Re: A successful Git branching model (2010)

#45

Post by nebabyte »

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've got a much nicer branching model- try not to have one

Ah, like my much nicer version control system ;)

Re: A successful Git branching model (2010)

#46

Post by nebabyte »

dorian-graph wrote: post #24
damnyou wrote: post #21

Earlier quoted context omitted.

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

While I do like this approach, it can cause some pains though. It's often a race to get your (approved) merge- or pull- request in. If you miss out, then you rebase, and try again. Perhaps if your pipeline is super fast, it isn't an issue. Another issue is that there still needs to be coordination outside of version control/CI pipeline to ensure that things are put in the 'right order', for the times when that is imp…

And why not. Rebasing should be much more straightforward/common. I remember at one point I had a 'magic' command that just did a rebase the way I expected and allowed me to merge changes in easily; it quickly made its way through the group I was working with.

Re: A successful Git branching model (2010)

#47

Post by hyperpallium »

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…

Dependency injection? The conditionals are then virtual (which implementation of an interface); the same controls apply to front-end code; global dependency configuration.Though all that infrastructure and boilerplate for explicit modularity is probably only worthwhile at Facebook-scale.

With each feature in a separate file, there is no merging of features, and if you squint your eyes you can see each possible dependency configuration as a git branch, selecting certain files out of a repository, just at runtime. There are no file-level merges, only different files, and different configuration selections. (Of course, modifying code to use the interface in the first place is a file-level change.)

BTW I've been thinking about this problem in the context of computational fluid dynamics, where you want to try different scales, fluid and container initial condition profiles and boundary conditions, as well as different discretizations, schemes and variations thereof. Basically, experimental cases (a bit like "functional test" setups).

Re: A successful Git branching model (2010)

#48

Post by Rafert »

Froyoh wrote: post #44
imron wrote: post #28

Earlier quoted context omitted.

> Every git user should be aware of git-flow Agree. Every git user should be aware of it and should use it on a project at least once so they know to avoid it forever after.

Why avoid it?

Because it's complicated and most people don't need that complexity at all. For some reason a lot of people happily jumped on the band wagon when this was released and started writing scripts to make it more bearable.

If you have multiple versions of your codebase that you need to maintain for a longer time to justify those release branches, gitflow might be for you. IMO GitLab flow is much more applicable for most people: https://about.gitlab.com/2014/09/29/gitlab-flow/

Re: A successful Git branching model (2010)

#49

Post by stonewhite »

icebraining wrote: post #34
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.

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

Re: A successful Git branching model (2010)

#50

Post by imron »

Froyoh wrote: post #44
imron wrote: post #28

Earlier quoted context omitted.

> Every git user should be aware of git-flow Agree. Every git user should be aware of it and should use it on a project at least once so they know to avoid it forever after.

Why avoid it?

Because it creates a large amount of needless busywork.

It's much easier to develop on master and/or on feature branches that can be cleanly merged in to master, and then tag master (or create branches) once a release is hit.

See for example the simple git workflow:

https://www.atlassian.com/blog/git/simple-git-workflow-simpl...

Post reply on HN