Three approaches
You can use one of these popular techniques, or you can use them as a basis for creating your own.
GitHub Flow . The strategy is used by the GitHub service team. The main requirements are as follows:
- There are no errors in the code in the master branch, and it must be ready to deploy at any time;
- to start developing a new feature, you need to create a feature branch in the master branch and give it a name that is obvious to everyone. When the work is ready, it needs to be merged into the master branch via a pull request;
- after merging the changes, you need to immediately deploy them to the server.
This approach is usually used for products with a single version that is not updated very often. For example, websites. On the plus side, this approach makes it easier for developers to understand and organize their work. The main disadvantage is that if your project is complex enough and is updated frequently, it is better to use a different strategy.
GitFlow . It should be said right away that this strategy is debatable. There are a lot of both positive and negative reviews about her.
The bottom line is as follows. There are two types of persistent branches: the master branch, to understand what the latest current version looks like, and the development branch, where development is taking place. There are three types of temporary branches coming from it.
- Feature, to add new features. After completing the work, you need to create a pull request in the development branch.
- Release to work on new versions. It is important to add a version number to the title, this will help you avoid confusion and track changes.
- Hotfix, for quick bug fixes.
This approach is considered one of the best for projects where several versions for different platforms are constantly being developed.
In 2010, a text by Dutch programmer Vincent Driessen " A successful Git branching model " was published, in which he first talked about GitFlow. The article became quite popular, a Russian translation appeared , and the method was adopted by many teams.
In 2020, American programmer George Stoker published an article “ Please stop recommending Git Flow", Where he criticized the method as outdated and ineffective in modern realities. Driessen, in response, supplemented his 2010 text with a disclaimer, in which he admitted that his method was not a panacea, but only one of the options for organizing work.
Forking Workflow. Here the approach is this: there is an original repository for merging all changes and a copy of it, in which another developer works. The approach is very close to the open source ideology, its goal is to use all the advantages of the open-source community within the project. However, most of the branching workflow is copying GitFlow. Feature branches here will merge with local developer repositories. Thus, development becomes flexible even for very large teams with contractors.
Among those who take this approach is Linux . You can offer your own options for changing the code even for the system core. And this approach seems to work effectively.
General points
Whichever concept you choose, there are basic points that are best to stick to. For example, here are the Microsoft rules :
- don't over complicate your branch strategy;
- use feature branches for all updates and bug fixes;
- merge feature branches into main branches using pull requests;
- Keep upstream quality and up-to-date.
A strategy based on these ideas will lead your team to work with logical and easy-to-understand versions.
Here are some more helpful guidelines.
Call it simple and obvious
This will help all team members understand correctly who is working on what. It is also acceptable to include additional information in the branch name, for example, the name of the creator. This is the case when you don't need to come up with something original. Branch names like “users”, “bugfix”, “feature”, “hotfix” are what you need. For branches that are delayed, use separate special flags. This will allow the team to immediately understand what is at stake and always keep these tasks in mind as long-term.
Merging branches only through a pull request
The pull request mechanism has proven to be logical and well thought out. Since this process takes time, you must agree within the team what and in what time frame is expected from all participants in the pull request. Assign the responsibilities of the reviewers and share this with the team through the internal knowledge base.
Here are some specific tips:
- according to Microsoft research , the optimal number of reviewers is two;
- if your team has already formed the principles of code review, stick to them and try not to break;
- A pull request works much better when more team members are regularly charged with reviewing code;
- Leave descriptions of your work in sufficient detail so that reviewers can quickly grasp the context.
Set up branch policies
It's worth spending time on branching policies for several reasons:
- this way you can isolate current work from completed work within the main branch;
- make reasonable restrictions by determining who and what changes can make to specific branches;
- quickly disseminate effective working methods.
There are two basic rules based on which policies should be configured:
- reviewers are automatically added to a pull request at the time of its creation. You can first define a list of them and then edit as you go;
- a successful build is required to complete the pull request. Code poured into the main branch should build cleanly.
But the most important principle when creating your branch strategy is this: you need to think it over so that the team does not have any questions about the meaning of this or that action. Then every day in your project will be productive.
Blog ITGLOBAL.COM - Managed IT, private clouds, IaaS, information security services for business: