So you want to adopt git to version your current or next project. There are quite a number of ways you to go about it and even collaborate with others. Apart from using git to just version the code base of your project, it could be used to coordinate how others contribute to the project. This is best achieved by adopting a workflow.
A workflow is not a concrete rule that you must follow but rather a guideline.
A git workflow is a collaborative practice to make contributing to any project easier and better organised. It outlines how to go about adding and publishing changes to a project’s source code repository. It’s most effective for projects that have a remote repository. A workflow is not a concrete rule that you must follow but rather a guideline. So feel free to pick aspects of one and combine with that of another to suit your need.
For the sake of this post, we’ll assume that master is your main branch and that you are familiar with basic git related terms (branch, commit, merge, pull request, patch, fork, repository) or you can google them.
Here are a few workflows to consider for your project. For each workflow, we’ll briefly look at how it works and where it’ll most likely fit. If there are requests, we could go into more details in a later post.
Central Workflow
The repository contains only one branch, the main branch, master. All changes are committed to this branch. The repository could be just local, with out a remote copy or also hosted remotely where it could be cloned and pushed to.
Use case
This is ideal for a one person project. On your project, you would adopt this workflow to have snapshots of your changes as you go along with the development. After some significant work, you commit your changes so that you can later go back to any previous version. It could also be used by small teams making the transition from svn to git.
Developer Branch Workflow
Every developer has their “personal” branch or subset of it, to which they push. All changes published to the remote repository by that developer would be on their branch. Work can be done on separate branches but would have to be published on the developer’s branch which is later integrated(merged) into the main branch.
Use case
Better suited for small(limited requirements) projects with a small number of collaborators needing their changes to be reviewed before it’s merged into master. Say you have a group assignment, collaborators on that team do their part then publish to the remote repository for others to review before it’s merged. The review should ideally be done with a pull(merge) request. It could also be a handy way to introduce pull request on a team or in an organisation.
Feature Branch Workflow
In its simplest form, the repository would have a main branch with stable, shippable code and other branches for every feature(or bug or improvement) to be integrated into the main branch. To go further, the repository would have a secondary main branch (eg dev) which holds stable code being tested to be shipped to users when it’s merged to master. In that case, feature branches are merged to dev, not master. There’s a very detailed explanation by Vincent Driessen.
Use case
This would be more appropriate for teams having some kind of project management method(e.g Agile) that continuously ship out. Let’s say your project is under continuous development and you might have a set of features to be developed for the next release. These features are assigned to different developers who create a branch for every feature that's published (most likely for review) before it’s merged into dev for testing. When you’re ready to release, dev is merged to master.
Issue Branch Workflow
Very similar to feature branch workflow with one key difference. Branches are created from issues/tasks on the issues in the project’s issue tracker. The branches could have the same name of the issue of its id. There’s only one branch per issue and one issue per branch.
Use case
Just Like the feature workflow, this is best suited for projects with a project management structure in place. However, unlike it, this workflow is more applicable to projects where each feature isn’t completely handled by a single developer. Like you would work on the UI of a feature and another developer would work on a different aspect of that feature. It could be adopted by both projects that are continuously being released or those that are released once in a while.
Forking Workflow
With this workflow, contributions to a project are made by creating a fork of its repository. All changes are committed to any branch on the forked repository then contributed back to the original repository with a pull request. Contributors would only have read access to the remote repository.
Use case
Mostly used on open source projects with public repositories. Anybody (let’s say a friend) that can view your remote repository can make a fork of it. They mustn’t have access to contribute directly to the repository as long as they can view it. When they’re done working on it, they make a pull request which you can review to decide whether to integrate, reject or ask for improvement before it’s merged into your project.
Patch Workflow
Using this workflow, contributors submit changes they’ve made to the repository with a patch (a file containing what was changed in the repository). The patch is applied to the repository by someone who can write directly to the repository, like a maintainer/owner.
Use case
Used on projects where the contributor can’t write directly to the repository but has access to the source code. Let’s say you share the source code of your project with a friend or they have read access your remote repository. After changes are committed to their copy to the source code, a patch is created and sent to you. You apply it to the repository to get their changes. Also used on some open source projects by those that aren’t main contributors of the project.
There could be tonnes of other way people collaborate using git or even different implementations/names for the ones discussed here. These are just a few. It’s left for you to choose any, combine multiple or something entirely different for your next project. So feel free to pick and choose.
I’d Love to see what you build and how you do it.
Top comments (15)
Thanks for this clear article !
Few months ago I wrote an article about how to applied the feature branch workflow when several teams are working on the same product along with the Scrum methodology :)
theodo.fr/blog/2016/09/push-to-pro...
I really enjoyed reading your article. From your article, it seems like every feature branch also has sub-branches. Was this done so that multiple developers can work on the same feature?
Thank you: I really enjoyed this article - so logically delineated!
I have seen teams struggle with a model somewhere between feature and developer branches, and I couldn't explain what seemed hinky about it. I personally like the issue branch workflow, because it focuses my attention on the one task.
I'm glad you enjoyed it.
Could you describe how they go about it in the model you mentioned?
I find git flow scales well - from personal single-dev projects to larger multi-dev. It tends to be my default whenever starting out a project.
I'm curious how you use git flow on a single-dev project.
I've done it, and it's no different than on a multiple-dev project. You're still keeping each feature, fix, etc. on their own branches that you merge into
masterordevelopbranch when ready. It's just that there's nobody else doing the same thing on your repo.That makes a lot of sense. So you'll be tracking what types of changes each unit of work introduces.
I've seen this (feature/issue type workflow) although branches didn't get the feature's name. Every branch is created from an issue on the issue tracking system then prepend the task type(feature|hot-fix|update|fix) to get a branch name(e.g hot-fix/DCS-458). This helps in tracking what types of issues are worked on mostly, who makes the most bug fixes, where the branch is to be merged into, etc.
I work in a team and we always use the git flow paradigm. Works perfect for us
Yes, the git flow workflow (or feature branch workflow as is in the post) is quite popular with teams. But it isn't always the best choice for all projects irrespective of the team size.
No, but we only do larger projects. Even with smaller projects it has its advantages. Having only 1 branch should never be an option in my opinion.
Of course, Except for very simple projects, a single branch is never ideal.
Really nice summary.
The only thing I am missing here is a remark on how to use tagging. I am always amazed when I see a project which is not using tags to mark the stable releases.
Yh, good point.
Tagging is very key especially for marking releases on large projects.