this post was submitted on 08 Sep 2023
30 points (91.7% liked)

Git

2875 readers
19 users here now

Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency.

Resources

Rules

  1. Follow programming.dev rules
  2. Be excellent to each other, no hostility towards users for any reason
  3. No spam of tools/companies/advertisements. It’s OK to post your own stuff part of the time, but the primary use of the community should not be self-promotion.

Git Logo by Jason Long is licensed under the Creative Commons Attribution 3.0 Unported License.

founded 1 year ago
MODERATORS
[email protected]
[email protected]
[email protected]
30
A successful Git branching model (nvie.com)
submitted 1 year ago by [email protected] to c/[email protected]
3 comments fedilink hide all child comments
you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 5 points 1 year ago (1 children)

Apart from the historical value, the most important part of this article now is the "Note of reflection" added 10 years after it's inception:

If your team is doing continuous delivery of software, I would suggest to adopt a much simpler workflow (like GitHub flow) instead of trying to shoehorn git-flow into your team.

I don't think this work flow is relevant any more even for teams that don't do CD, to be honest. It was a messy work flow to begin with and I haven't seen it applied successfully in practice.

[–] [email protected] 2 points 1 year ago

the most important part of this article now is the "Note of reflection" added 10 years after it's inception

Agreed; amazing to see this added. I suppose it's admirable... but the pain that has been inflicted on the teams I've been part of in the meantime... ugh.

I haven't seen it applied successfully in practice.

Neither.

I could see the value, in theory, for geographically separate teams spanning many time zones juggling concurrent development efforts. But the reality for a lot of commercial software development is totally the opposite. It's done in offices where staff are in at 9, out at 5, all working on the same features in a linear style. They're not developing an OS kernel; they're maintaining a CRUD app.

For that "git-flow", code needs to be in a state where it can have patches rebased/merged independent of one another. The codebases I've worked on have never been anywhere near that robust.