This content originally appeared on DEV Community and was authored by Maxim N Epikhin
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?
This content originally appeared on DEV Community and was authored by Maxim N Epikhin
Maxim N Epikhin | Sciencx (2022-02-15T11:58:32+00:00) Git Organized: My better Git Flow. Retrieved from https://www.scien.cx/2022/02/15/git-organized-my-better-git-flow/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.