In this article, I review the Git branching approach that I use in all of my development projects. Carefully, this approach is not as effective in maintaining existing software solutions.
How the branching organization is built
The first thing that should be - the main branch responsible for the final product (main / master / stable and others). We upload only ready-made and tested code to this branch, which then goes into release. Using the branch for other purposes is strictly prohibited.
The second point is the development branch. In this branch, we have a cut of the tested functionality code that is being prepared for release. This branch is not recommended to upload changes that are questionable or have not passed the tests. But, this moment is on the conscience of developers and testers. This development branch must be named as follows: development_MONTH_YEAR - for example, development_february_2022. You can go the easy way and call the dates numbers, but I prefer the verbal form for the months. Why create a branch every month? You will be able to see the development of the product every month and draw your own conclusions. This is convenient because you can tie product releases to the end of the month.
git checkout -b development_february_2022 main
or
git checkout -b development_february_2022 development_january_2022
The third point is task branches. Some people make new feature branches, but I prefer to create branches for each individual task. Most likely, you are leading a board and an issue in your project. Each issue has its own through number. This is how the branches are named: task_1 and so on. Each such branch must necessarily create from the current development branch (current month and year) in order to have actual changes. If changes have been merged into the development branch, then you must pull them into the task branch for updating.
git checkout -b task_1 development_february_2022
The merging goes like this:
- Merge the task branch into the development branch
- Development branch to master
Everything is simple and clear. And now it is worth mentioning the points on maintaining the board, as this is one of the most important functionalities in project management.
How to lead a board
Your whiteboard should have the following columns:
- List
- To do
- Fix
- In progress
- Code review
- Tests
- Awaiting merge
- Done
Here is such a simple organization of the board. Now I’ll tell you about the life cycle of a task by columns. The tasks that are in the List column are simply a list of all the tasks that have not yet been allocated. In To do - a list of tasks that need to be done in a sprint and already have a distribution for developers. Fix - tasks with errors. In progress - tasks that are being executed at the current time. Code review - tasks that are being checked by the team lead or other people responsible for the final quality of the code. Tests - tasks for testing by testers. Awaiting merge - tasks that are waiting to be merged into the development branch. Done - merged and closed tasks.
Now a little about the life cycle. First, no more than 3 tasks per developer are selected from the List and placed in To do. When a developer is present to solve no more than 1 task, he moves the task to In progress. After completing the task, you need to transfer it to Code review, from where it goes either to Fix or Tests. If the task got into Fix, then the developer, when he started solving errors, transfers it to In progress, and the cycle repeats. When the task is included in Tests, the cycle is repeated as in Code review. If the tests were successful, then the task is moved to Awaiting merge, and when merged into the development branch, it is moved to Done and closed.
Agree that this is a fairly simple organization of the task. What do you think?
UPD 18/02/2022
Made an omission on the branch. Look, we are creating a development branch from the main branch, and we are already creating a monthly development branch from the development branch. We fill the monthly development branch into the development branch and then from the development branch we create a new monthly development branch
Top comments (8)
What about using tags and a single trunk branch? You could use tags to denote production releases, and additional tags for marking when a development period/sprint begins. The trunk branch would be a bleeding-edge build containing the latest but but unreleased changes.
In general, I don't see the point in signaling the start of something (sprint or whatever) with tags. Developers on Scrum or other approaches already know the beginning. Another moment, the beginning of the sprint can be determined by the appropriate branch. If I use a monthly approach, then no one said that it could not be extended. You can, in theory, add another line of sprints. Then sprints will be created from the monthly development branch, and task branches from the sprint branch. Further, the tasks are merged into the sprint branch, and the sprint is already into the development branch. This is also a very good approach in my opinion, but I don't like sprints themselves.
I should have been clearer - I meant using tags to replace the
development_MONTH_YEARbranching.Yes, it's possible, but I have a policy of branching for later rollbacks. Also, with this approach, you can carry out several changes at the same time. For example, if you have only one messenger repository, and you decide to make 2 parallel versions (like the web version of Telegram), then branching will be a better solution.
Like most VCSs, Git has the ability to mark certain points in history as important. Typically, this functionality is used to mark the release of versions (v1.0, etc.).
One more thing, I don't really understand how a tag can be used to determine the beginning and end of a month... On the one hand, there are 2 tags, but on the other hand, why? It will not be easier to make a branch here and that's it. I prefer to use tags only as release notes.
+1
I still do not understand why one would want a branch only to denote releases when that's just a
git tag -naway.It doesn't have to be taken at face value. Simply, my approach is to use tags in this way. Someone builds tags differently, I do.
I could see it possibly making sense if you ever had changes in trunk that somehow weren't otherwise captured in long-lived branches (e.g. managing multiple minor releases like Python) and needed to backport, but that's rarely the case when you're building a product for end users, rather than a meta-product for other devs. I agree though, it's cumbersome to introduce the overhead of a release branch and PRs into it if you're never PRing it anywhere else.
Me to!