Git Organized: My better Git Flow
Tags: git, workflow, github
Published: 2022-02-15 11:58:32

[In this article](http://maximepihin.ru/all/git-organized-moy-luchshiy-podhod-k-git-flow/), 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

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/5jbxr0j1gdhwwuyglbha.png)

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

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ik37w6l8is59ufyi4cft.png)

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