Git Workflow Best Practices

As a very popular version management tool, Git is favored by many developers. So how can git play a better role? I have summarized the following best practices for Git workflow based on my experience in actual project development. Welcome everyone to shoot bricks. Pre-conditions

I use the daily development: Git + Github/gitlab 1. Create corresponding develop based on task branch

When we receive a new task, the first step is to create a new development branch (develop branch), and then checkout to start development on this new branch.
It is strongly not recommended to develop new tasks directly on master, especially if there are more team members. Each team member should work on his or her newly created branch, the benefit of which is that Master is always in a "neat" state and does not cause too many conflicts due to simultaneous operation of multiple people, and also reduces the likelihood of master being mistakenly manipulated.

The specific git operation commands are as follows:

$ git checkout master//switch to Master Branch;
$ git pull origin master  //Fetch Master Remote Branch code;
$ git checkout-b <my Bran CH name>//Create a new branch and switch to that branch.

2. Development on the new develop branch

Once the develop branch is created, we can start developing on the develop branch. This is the most important phase of our task, and most of the work is done at this stage, and it should be the longest duration. Its main task is to complete the task development work, and eventually push the code to the remote branch corresponding to the current branch.

Let's take a look at this phase of the Git workflow, as shown in the following example: 2.1 First day

$ git Add. At the end of the first day of work, first put the changed code into the staging area;
$ git commit-  m "The initial commit message"//submit code to the local repository;

2.2 Daily Development

Before starting work every day, merge the master branch code into the current branch, with the following command:

$ git checkout master 
$ Git pull origin master  //The remote branch from master pulls the replacement code;
$ git checkout <my branch name>//Switch to The local branch where the task resides;
$ git rebase-i master  //merge code

The git rebase-i Master command merges the most recent code on master into the current branch, where-I is the function of compressing the commit before our current branch into a commit, and the benefit is that when we create the pull When the request is made and the corresponding code review is in place, the changes to the codes are focused on a commit, which makes the review more intuitive and convenient.

After merging the latest code on master, you can continue to develop. At the end of the day development, the updated code is submitted to the local repository, with the following command:

$ git Add. After the end of the day, the changes are put into the staging area;
$ git commit-  m "Daily commit message"//submit code to the local repository;

2.3 Push code to remote branch

Finally, when all the coding for a task is complete, push the code in the local repository to the remote branch, with the following command:

$ git Push--set-upstream origin <my branch name>

3. Create Pull Request

When all the code has been push to the remote branch, then we can not merge the code into master, what we should do is to create pull request.
Pull request is designed to allow code to be review by team members before it is in the merge to the Master branch, improving the quality of the code and reducing the probability of errors.

The Github/gitlab itself has the ability to create pull request. The operation to create a pull request is simply a click to create a Pull request button, fill in the comment information, and enter the name of the member that can be code review. When the pull request is created, all team members who can make code review receive an email notification and see the code change through a link to the corresponding pull request to complete the review. This step does not operate with the actual git instructions.

The code review in this step is not required and you can skip to step fourth directly. 4. Merge code to Master

When all the reviewer have finished code review, and the pull request has been labeled as approved state, we can merge the branch into master and eventually push to the remote master branch.
The command is as follows:

$ git checkout master//switch to Master Branch;
$ git Merge <my branch name>//Merge the branch code you created before to the master branch;
$ git push origin master//Push Master's code to the remote branch of master, and
git branch-d <my branch name>//Delete the previously created branch.

If it is troublesome to knock the command, you can simply click the merge button on the Github/gitlab Web page to perform the code merge.

At this point, the workflow for a task git is over.