Assume that the reader understands basic Git operations and Git branch management strategies.

In order to enhance the readability of Code records and assist the implementation of Code review, a suitable Git flow scheme was set up by referring to the existing flow scheme.

Process steps

  1. The new branch
  2. Commit record
  3. Merge commit Records
  4. Push to the corresponding remote repository
  5. A Merge Request was submitted
  • Git cherry-pick is another benefit of this process
  • Git pull –rebase

Step 1: Create a branch

Each time a new feature is developed, a new feature branch should be created from the current main development branch.

# create a new function branch from the current branch
$ git checkout -b feature-KJDS-00000Copy the code

Step 2: Commit the record

After the function is added, commit the function. Commit must carry sufficient modification information.

Add to staging area and commit
$ git add -A
$ git commit -m "header: some message"Copy the code

Set here:

  • Miscellaneous submission usemisc:At the beginning:
$ git commit -m "misc: some awesome modification"Copy the code
  • Bugfix or merged commit records are usedjira-No:At the beginning:
$ git commit -m "jira-00001: fix a specific bug"Copy the code

Expansion: can be combined with “Gitmoji” to enhance the readability of information.

Step 3: Merge commit records

Suppose four new development records are added to the feature function branch:

commit 34d364d9d51dc94b264e99f7a92add50dd2c3987
Author: Aeo <[email protected]>
Date:   Sun Jun 25 12:27:02 2016 +0800

    misc: forth commit

commit 27322cb4b3f99226ffa98240460b90d92ed55a17
Author: Aeo <[email protected]>
Date:   Sun Jun 25 12:26:42 2016 +0800

    misc: third commit

commit 405b957a96a7dbe352cf7da9a422312a735f6081
Author: Aeo <[email protected]>
Date:   Sun Jun 25 12:26:16 2016 +0800

    misc: second commit

commit cc12fc86a7738ee2f9a8a48c31a9435232c2b08f
Author: Aeo <[email protected]>
Date:   Sun Jun 25 12:25:53 2016 +0800

    misc: first commitCopy the code

Now that we have completed the development and tuning of the feature branch, we need to merge the code into the current main development branch.

Git rebase is recommended to merge unnecessary commits to keep the main development branch clean.

Rebase: generally translated as “derivative” or “rebase”

If you want to merge the last four commits, you can run the following command:

# I indicates interactive.
$ git rebase -i HEAD~4Copy the code

Git will now open an interactive interface that allows users to make changes to their historical commits:

pick cc12fc8 misc: first commit
pick 405b957 misc: second commit
pick 27322cb misc: third commit
pick 34d364d misc: forth commit

# Rebase 2763481.. 34d364d onto 2763481 (4 command(s))
#
# Commands:
# p, pick = Use this commit
# r, reword = Use the submission, but edit the submission information
# e, edit = Use the submission, but pause here to provide an opportunity for modification
# s, squash = This commit is used, but merged into the previous commit record
# f, fixup = Similar to squash, but discards the commit information of the current commit record
# x, exec = execute shell command
# d, drop = removes the current commitCopy the code

What we need is to use squash or fixup for branch merging:

pick cc12fc8 misc: first commit
squash 405b957 misc: second commit
squash 27322cb misc: third commit
squash 34d364d misc: forth commitCopy the code

With fixup, the other records are simply discarded, skipping the next step. If squash is used, you need to modify and save the four commit information in the next step:

# This is a combinatin of 4 commits.
# This is the 1st commit message:

misc: first commit

# This is the commit message #2:

misc: second commit

# This is the commit message #3:

misc: third commit

# This is the commit message #4:

misc: forth commitCopy the code

After editing and saving the git log, you can see that only one commit record is left:

The COMMIT SHA is not the same as before
commit da473276aa981f6e29577aa09a525109971547f2
Author: Aeo <[email protected]>
Date:   Sun Jun 25 12:50:53 2016 +0800

    misc: first commitCopy the code

Risks of Rebase:

There is a rule to follow when using Rebase:

Once a commit object in a branch has been published to a common repository, it should never be replicated on that branch.

Simply put, if the commit record to be merged is a mix of other people’s commit records, you cannot merge this part of the commit record.

But as long as you start new branches and keep them separate, there’s no hybridisation.

Step 4: Push to the corresponding remote repository

After the Merge of commit records is complete, the latest code of the target branch can be merged to avoid conflicts during the subsequent Merge Request submission.

$ git push origin feature-KJDS-00000Copy the code

Step 5: Submit the Merge Request Request

After completing the function and submitting it to remote, you need to go through the following process:

  1. Submit Merge Request:

    Create a Merge Request by using the +Create Merge Request button.

  2. “Assignee” must be specified:

    Specify who needs to review your code. Do not specify yourself.

  3. Change Target Branch:

    Change to target branches that need to be merged into;

  4. Set the option to delete merged branches after merge:

    Select Remove source branch when merge request is accepted. After the merge is complete, delete the source branch to control the total number of branches.

  5. Submit the Merge Request using the Submit Merge Request.

After completing the above Settings, relevant students will receive an email notification, and then they can enter GitLab for code review.

If the problem is found, it will comment on the problem code and refuse to close the application; otherwise, it will apply for merger.

The Merge Request record left after the merger application was approved will also be a code Reviewer record.

Git cherry-pick is another benefit of this process

For the code submitted through this process, each function corresponds to a unique submission record.

At this time, if some functions are independently launched in advance, they can be directly used in the branch to be launched:

git cherry-pick commit-SHACopy the code

The commit-SHA can be a commit record on another branch, which can then be captured directly on the branch to be live, avoiding the time and risk of deducting functionality from the hybrid-code.

Use git pull –rebase instead of git pull to remove unnecessary Merge requests

During the initial build phase of the project, there may be multiple people working on a branch at the same time with a large number of concurrent operations, which may not be appropriate.

However, git pull –rebase can still be used to keep the commit record as clean as possible.

If you commit your code locally and then execute Git pull, you are most likely to get merge records like this:

Merge branch 'feature' of ssh://domain/some-system into featureCopy the code

But in most cases there is no conflict. So when pulling remote code, use Git pull –rebase to keep the commit history clean.

Git /rebase), then pull the code from the remote branch to the local branch, and finally apply the saved patches to the local branch.

To use rebase as the default for Git pull, modify ~/. Gitconfig to have all Tracked Branches use this setting automatically:

[branch]  
  autosetuprebase = alwaysCopy the code

The appendix

  1. Derivatives of Git branches
  2. Git use specification process – Ruan Yifeng