We've had some discussion of this in the migration thread, but it didn't quite seem totally finished. I also just noticed that one of the ubuntu git gui packages is apparently focused on supporting Vincent Driessen's branching model, described at http://nvie.com/posts/a-successful-git-branching-model/ so I took a look at it-- it looks quite nice. It seems to me the biggest distinction from what we've been talking about is that in addition to various feature branches it also proposes a development branch where all ongoing work is done, to which feature branches get merged and from which release branches get branched. Then only periodically at stable releases does the release branch get merged back into master, so master always provides the last stable release.
The diagram there is a very nice clear presentation of his model, far more clear than my words, and his writeup has a very clear discussion of what git commands would be used at what points, so it seems to make a very clear guide. I'd like to ask everyone to take a look at that to consider for adoption by us.
branch management proposal
branch management proposal
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0
Re: branch management proposal
The model seems to make a lot of sense. If we adopt something like this, I would prefer using master as his "develop" and creating a separate branch (called "release" or "stable") for the role he gives master. Master is the default branch and I feel development is the default mode for people accessing the repo.
Any code by me in this post is released under GPL 2.0 or later.
- adrian_broher
- Programmer
- Posts: 1156
- Joined: Fri Mar 01, 2013 9:52 am
- Location: Germany
Re: branch management proposal
I agree with Mitten.O here.
Resident code gremlin
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz
Re: branch management proposal
The model proposed in that post is called "git-flow". There's even a high-level tool to use it (https://github.com/nvie/gitflow/). But there is also detractors to this model, some people consider it too complex and bureaucratic for agile development. Among them lthe github development team, that proposed its own model, called github-flow and described here: http://scottchacon.com/2011/08/31/github-flow.html. Of course it's heavily based in github features.
Note that both git-flow and github-flow were developed with web applications in mind, where rapid development and deployment are a key requeriment. This contrast with the model used by "desktop" applications (being the linux kernel the most famous).
Another important issue to consider is the merge-vs-rebase thing. This is not a detail, since git-flow is heavily based in merging branches with two or more commit parents. And that type of merges come later with a price, as I said in the other thread. Maybe this blog post can explain the difference between ff-merges and merges and why the later are a problem: https://sandofsky.com/blog/git-workflow.html Also this one is relevant https://www.atlassian.com/git/articles/ ... or-rebase/
Also, a git workflow is not only about how to manage branches, it's also about how to manage repositories: http://git-scm.com/book/es/v2/Distribut ... -Workflows.
BONUS: Atlassian "Comparing Workflows" tutorial: https://www.atlassian.com/git/tutorials ... -workflow/
Note that both git-flow and github-flow were developed with web applications in mind, where rapid development and deployment are a key requeriment. This contrast with the model used by "desktop" applications (being the linux kernel the most famous).
Another important issue to consider is the merge-vs-rebase thing. This is not a detail, since git-flow is heavily based in merging branches with two or more commit parents. And that type of merges come later with a price, as I said in the other thread. Maybe this blog post can explain the difference between ff-merges and merges and why the later are a problem: https://sandofsky.com/blog/git-workflow.html Also this one is relevant https://www.atlassian.com/git/articles/ ... or-rebase/
Also, a git workflow is not only about how to manage branches, it's also about how to manage repositories: http://git-scm.com/book/es/v2/Distribut ... -Workflows.
BONUS: Atlassian "Comparing Workflows" tutorial: https://www.atlassian.com/git/tutorials ... -workflow/