Preface

Git plays a big role in managing the development branches of our development code. We usually have branches for production, pre-release, testing, and development. The normal process is development -> testing -> production, but there are usually many versions, there is a sequence of on-line order, and our developers will be more than one, in various factors the development version of the project remote branch, as well as the developer's local branch management by for the key.

General development process

The normal stages a version needs to go through are dev, test, uat, master, we do this through the following flowchart is no problem, each stage to pull the version branch from master, push to the corresponding branch for release, normal pre-release and production environment code should be consistent, test branch because there will be multiple versions parallel development, so the code and pre-release and production will be different.

Mu lti-version parallel development

When multiple versions are not developed, the management of branches is not as simple as the above, involving multiple versions, and the online time nodes of these versions are different, which means that the time nodes of test and uat are also different.

There are multiple scenarios involved here

  • In the case of fewer back-end developers, usually 2-3 people for example, it is entirely possible to pull a development branch from master, the branch format has Service name + uptime, for example xxx_20230130 this local branch, back-end developers together on this branch for parallel development, the development phase of their local branch merge to the dev branch, because only 2-3 people The development phase will merge their local branch to the dev branch, because there are only 2-3 people so conflict resolution is fine, there is conflict resolution conflict.

  • In the case of more back-end developers, usually 5-8 people, the branch is pulled from the master branch, and the branch format needs to be named Service name + initials + uptime, so that everyone can develop under their own named branch as much as possible, so that when testing locally in the development phase, they can do it without affecting each other, but when merging to the remote branch, the code needs to be resolved carefully. This kind of work should be left to people who are careful, and the testing should be done according to the priority of the version on line.

  • In the case of more versions, such as a month there will be 4-5 versions of development, then the uptime is also divided into 4-5 nodes, so you need to merge the code to the next version of the local development branch from the remote branch that is sent online first, and so on.

Git merge

As a git merge branch command, it is also a command that is often used in the daily development process, usually we will merge a version with the latest code to an older version to achieve version synchronization.

This is basically a step-by-step process that starts with a public branch, becomes a master and feature branch, and merges the master branch into the feature branch with the git merge master command. The merge command will merge all the commits from the previous featrue branch into a new commit. ⚠️ will only create a new commit record if there is a conflict.

This can be interpreted as git pull =git fetch +git merge, which pulls the latest remote branch and then merges that branch into another branch.

When developing in a company, people usually like this command because it's simple and brutal, it merges other branches directly into their own branch, and it's easy to understand.

Git rebase

As my personal preference, I prefer the rebase command, the core concept of which is "change base".

  • As you can see from the above figure, the feature branch is continued behind the master branch with the rebase command.

  • In a multiplayer development process, if someone else is committing in master and you have several commits in the feature branch, then you use the rebase command to put your commit record behind the master's commit record, and merge will merge the commits from different branches into This is the difference between merge and rebase.

  • If the local feature branch and the remote master branch are on the same branch, you can use rebase to ensure the clarity of the commit record, which is critical!

​

⚠️ Do not use the rebase command in the public branch, this will pollute the public branch so that your commit record will exist in the public branch and your latest commit record will exist when someone else pulls it.

Summary

In the development of not only the need for high quality code, in version management is also by for the important, before going online missed code things, I believe we have encountered, but this kind of thing is very dangerous ⚠️, I hope this article can give you in the daily code version management submit vigilance, reasonable merging branch, and finally wish you in the new year, less bugs, more learning, more progress.