preface

In terms of version control, the company has shifted from SVN to Git management, and the private warehouse is built by GitLab, which can effectively manage the program version problems of each project team in theory. However, because developers switch from SVN mode to Git, they do not have a good understanding of the nature of distributed version management of Git in the underlying idea, and there are many abnormal situations in the process of using Git: they do not understand why there will be conflicts, unable to merge programs, will overwrite others’ programs and so on. The purpose of this article is to show teams how to properly use Git for program development.

Five principles to follow

Before I formally describe how to use the method, I want to state a few general principles that every developer must adhere to:

  1. We want to make sure that the Master branch is always available.
  2. New features are added in stages in the DEV development branch. (Dev branch can be understood as developing a version branch.)
  3. Each developer needs to set up his or her own branch, and all newly developed features need to be verified in their own branch before they can be merged into the Dev branch.
  4. Only when the dev branch is fully tested can it be merged into the Master branch and then released to production.
  5. In order to reduce the problem of too much version change and too many conflicts caused by not merging programs for a long time, periodically merge programs into the dev branch before leaving work every day (note: the premise is not to have bugs, which will cause other programs to be unable to use).

The correct process for the team to operate Git

According to the above principles to draw a map for everyone, first have an overall concept, do not be limited to a specific operation at the beginning. We first have to define a goal, that is to develop the program to merge on the remote branch. With this goal in mind let’s look at how Git is elegantly implemented:

1. Initialize the environment

Start from environment initialization, first set up the project on GitLab and initialize the required branches, create dev branch according to the master branch, and create developer branch according to the dev branch (dev_Hunter branch in the figure).

2. Pull the branch to the local

The first step of the development program is to pull the remote program to the local through Clone, and then pull the latest code through pull. This step needs to be made clear that the pulled program is a full program, that is, not only its own branch, all other branches have been pulled down.

3. Local program development commit and push

After the development, we need to commit the code. At this time, the commit of the operation is only saved in the local machine. Next, we can push the locally submitted program to the branch of the remote side by using push command.

4. Merge procedures

There is no problem with submitting programs under your own branch, because versions are updated relative to your own. However, there are a lot of problems when submitting code to the dev branch. Because other developers may have merged their applications into the Dev branch before merging them, their own branch is not the latest version, and there are many conflicts if they change the same files. To keep your branch in sync with the dev branch, do the following:

  1. Pull pull program. Purpose: Pull the latest version of the remote DEV branch to the local.
  2. Rebase merge program, local development branch and remote dev branch after comparison rebase. Note: I prefer to use rebase instead of merge, because you end up with a clear line for merging functions. You can search for the pros and cons.

3. If a conflict is displayed, the local program version does not match the latest dev branch, and the conflict needs to be handled manually.

  1. After the conflict is resolved, push the latest program to its own remote branch.
  2. Submit your own Merge Request request in GitLab, which can be merged into the Dev branch if no accidents occur.
  3. If you say you can’t merge it means there’s still a conflict. You need to re-perform steps 1-4. Step 5 will be triggered automatically for program merge.

conclusion

Many people how to use Git code for correct version management, I believe you should have a general understanding. The overall operation steps are as follows:

  1. Pull pulls the program locally.
  2. Commit && push the local development program and submit it to your remote branch
  3. Pull Pulls the latest version of the remote program
  4. Rebase & Push merges code, resolving conflicts if any, and submitting them to its own remote branch
  5. Merge Request Merges the remote branch into the dev branch