An Interest In:
Web News this Week
- March 20, 2024
- March 19, 2024
- March 18, 2024
- March 17, 2024
- March 16, 2024
- March 15, 2024
- March 14, 2024
Git-Flow vs Github-flow
Git-flow
Git-flow was described by Vincent Driessen on his 2010 post A successful Git branching model. Ive found it to be a great way to organize a repository. In short, you:
- Keep your master branch as the code that has been released,
- Use a develop branch as the current snapshot of what will go into the next release - your living beta,
- Spawn off feature branches off develop for every new feature, which are merged back into it when theyre ready,
- When you are ready to release, you merge to master and tag with a release version.
There are other considerations for how to deal with hotfixes, but thats the gist of it. You can see a git-flow diagram below:
This is a great approach and it has several advantages:
- master always remains as a stable reflection of your live code,
- You can trivially do hotfixes without worrying about unfinished features,
- Feature branches ensure that teams working in parallel dont trip over each other and that conflicts need to be handled only once (the moment the feature is done),
- It allows teams to cherry-pick changes other teams may be doing on their feature branches, without needing these commits to be on develop already,
- It lets you do a release off develop at any point - if a feature isnt ready, thats OK, you just leave it for the next release.
There are helper scripts to assist you with Gitflow. Atlassians SourceTree supports it directly as well.
Github-flow
Proponents of Github-flow (and its cousin Gitlab-flow) have a few complaints about it. The main argument is that it goes against continuous delivery, since at some point someone needs to flip a switch and do a release from develop into master.
Thats a valid argument. Nothing is less continuous than manual switch-flipping.
The Github-flow proposal is that you should:
- Do away with the develop branch altogether,
- Spawn all feature branches off master, and merge them back into master when ready,
- Version tagging should not be carried by a human, but by an automated process whenever code is pushed to live,
These are valid points and they do result on a lighter-weight workflow. But they ignore that there are cases where you want a manual release, a negotiation of what is supposed to go into any particular version.
My take on it
Both systems have their uses. I think something like Github-flow is a great approach if what you are developing is an application. On that case, just using a master branch plus features branches works well, and you can do your releases in an automated fashion. The deployment itself is the atomic end-product you care about.
When you are building a library, where people outside your team might depend on specific versions, I think git-flow is the right approach. For a library, you want to lump your versioned changes together into a conceptual unit - including potentially separating or delaying breaking changes. At this point, coming to an agreement on what should go into a version makes sense, as does the manual release process of git-flow.
If anybody outside of your team depends on your versioning scheme, or will need to have a clear conceptual overview of what changed on a particular release, Id recommend using git-flow.
If whatever you are releasing is the final artifact, and it will be used but others will not need to reference its version, then GitHub-flow does the trick.
Original Link: https://dev.to/massii/git-flow-vs-github-flow-2iop
Dev To
An online community for sharing and discovering great ideas, having debates, and making friendsMore About this Source Visit Dev To