[Git from entry to proficiency | 01] Git source code management github workflow practice

This is the 61st post of Machine Future

Original address: https://robotsfutures.blog.csdn.net/article/details/127684442

"Git Source Code Version Management Series" quick navigation:

• [Git from entry to proficiency | 01] Enterprise Git uses github workflow best practice

---

---

Write at the beginning:

• Blog Introduction: Focus on the AIoT field, follow the pulse of the future era, and record the technological growth on the way!
• Blogger community: AIoT machine intelligence , welcome to join!
• Column introduction: Master the version control skills commonly used in enterprises from 0 to 1.
• Target Audience: Software Engineers

1 Introduction

This article describes the github flow workflow commonly used by multi-person collaborative development in enterprises, involving branch management such as release branch, development branch, test branch, bug branch, feature branch, and version rollback.

2. Introduction of main branches

2.1 master branch

The main branch, after all the functions of the product are realized, will be finally released on the master branch.

2.2 develop branch

The development branch is cloned based on the master branch, and the coding work of the product is carried out in this branch.

2.3 release branch

The test branch is cloned based on the delevop branch. After the product coding work is completed, it is released to this branch for testing. Small bugs found during the test are directly repaired in this branch, and merged into the develop branch after the repair is completed. This branch is a temporary branch, and the branch can be deleted after the purpose is achieved.

2.4 bugfix branch

The bug repair branch is based on the master branch or the released milestone Tag clone. It is mainly used to repair the externally released branch. After receiving the bug feedback from the customer, it will be repaired in this branch. After the repair is completed, it will be merged into the develop branch and the master branch respectively. This branch is a temporary branch, and the branch can be deleted after the purpose is achieved.

2.5 feature branch

The feature branch is based on the clone of the develop branch. It is mainly used for multi-person assistance development scenarios or exploratory function verification scenarios. After the function development is completed, it is merged into the develop branch. Multiple feature branches can be created, which are temporary branches and can be deleted after the purpose is achieved.

3. New feature development workflow

3.1 Switch to the local warehouse workspace

cd /home/timerhunter/workspace

3.2 Clone code from remote warehouse to local warehouse

$git clone https://xxxx@localhost:8443/r/valve/V5-Lora.$git

3.3 Create a develop branch based on the master branch

/* 切换到master分支 */
$git checkout master
/* 基于master分支克隆develop分支，并在克隆完毕后直接跳转到develop分支 */
$git checkout -b develop
/* 推送develop分支到远程仓库 */
$git push origin develop

**Note: The coding work is mainly in the develop branch, and the master branch is mainly used to release stable versions**

3.4 Development process in local warehouse

Submit the code to the local warehouse when a function point is completed or at the end of the day's work

/* 提交修改到缓冲区 */
$git add .
/* 提交修改到本地仓库 */
/* 如果是修复的BUG，应该在修改说明的最开始添加Bug#ID，多个Bug用逗号分隔，例如Bug#002,003 */
/* 如果是完成了一个指派的任务，应该在修改说明的最开始添加Task#TaskID,例如Task#165 */
$git commit -m "Bug#123 修改说明"
/* 每完成一个功能点可以对代码进行打包 */
$git tag -m "简要说明增加/修复/删除了什么功能" v0.0.0.170718

Note: Not every Tag needs to be submitted to the remote warehouse. For example, after completing the coding work of a function point, you can create a package without compiling it, and only store it in the local warehouse. After the compilation is successful & the test is passed, create a new one Tag package (milestone Tag package), only push the milestone Tag package to the remote warehouse

3.5 Push the code to the remote warehouse

When a function point or stage work is completed, push the code to the remote warehouse develop branch

/* 执行代码拉取操作，防止代码冲突 */
$git pull
/* 解决代码冲突后，推送代码到远程仓库*/
$git push origin develop

Note: It is forbidden to submit uncompiled or uncompiled code to the remote warehouse. If the coding work is not completed, it can be submitted to the local warehouse. Wait for all the function points to be realized before pushing the code to the remote warehouse.

3.6 Publish the code to the test branch

The phased development work has been completed, the small batch test work is started, and the code is released to the test branch release

$git checkout develop
$git checkout -b release
$git push origin release

3.7 Repair after the test engineer submits the bug

• Pull code from remote repository

/* 克隆仓库 */
$git clone https://[email protected]:8443/r/admin/test.$git
/* 查看远程仓库分支情况：克隆仓库时只能克隆master分支，因此需要拉取指定分支，我们使用$git branch -r查看远程分支情况 */
$git branch -r
  origin/HEAD -> origin/master
  origin/dev
  origin/master
  origin/release
/* 拉取测试分支 */
$git checkout -b release origin/release

• The repair process is the same as #2.4, #2.5;
• Note that the Bug#BugID keyword is added to the fix description when $git commit
• Push the code to the remote branch after completing a bug fix or completion of phased work

3.8 After the test work is completed, merge the code into the develop branch

/* 切换到develop分支 */
$git checkout develop
/* 执行合并操作,将release分支代码合并到develop分支 */
$git merge release
/* 如果合并报错，则解决冲突，冲突解决后继续再次执行合并 */

3.9 After the development work and testing work are completed, the develop branch will be merged into the main line when publishing

$git checkout master
$git merge develop

3.10 Phase development completed, make a milestone Tag package

/* 创建里程碑Tag */
$git tag -m "Task#003 v1.0.0 首版发布" v1.0.0.170718
/* 推送里程碑Tag到远程仓库 */
$git push origin v1.0.0.170718

4. Post-launch product bug fix workflow

4.1 Get the software release version number of the Bug product

4.2 Find the milestone Tag

 /* 查询里程碑及其提交说明 */
 $git tag -n1 -l v*

4.3 Create branches based on milestone tags

 /* git checkout -b [创建的分支名称] [里程碑Tag名称] */
 $git checkout -b bugfix-v1.0.0.170718 v1.0.0.170718

4.4 After the code is repaired, you can query the modified place

 $git diff

4.5 Merge into the develop branch and the master branch respectively after repairing

/* 合并到develop */
$git checkout develop
$git merge hotfix-v1.0.0.170718
/* 提交到远程仓库develop分支 */
$git push origin develop
/* 合并到master：如果随下一个版本再发布，可不用合并至master分支 */
$git checkout master
$git merge develop
/* 提交到远程仓库master分支 */
$git push origin master

4.6 Create a new milestone Tag

 $git tag -m "Bug#002 修复某某Bug" v1.0.1.170719
 /* 推送到远程仓库 */
 $git push origin v1.0.1.170719

4.7 Delete the bugfix branch

/* 删除本地分支-$git branch -d [本地分支名]*/
$git branch -d bugfix-v1.0.0.170718
/* 删除远程分支-$git push origin :[远程分支名]*/
$git push origin :bugfix-v1.0.0.170718

4.8 Only part of the modifications are merged when multiple versions are in parallel

Cherry-pick will be used here. Cherry-pick supports only merging the modifications submitted by other branches to the current branch. The syntax is:

git cherry-pick [commitid]

For example:
Due to the different needs of different customers, sometimes there will be multiple versions in parallel, and multiple versions need to be maintained at the same time. After a bug occurs and verified, it needs to be synchronized to all branch versions.

# 切换到v4.66.0.0分支
$ git checkout 4.66.0.0
Switched to branch '4.66.0.0'
# 查看最近三次提交
$ git log --oneline -3
23d9422 [Description]:4.66.0.0 commit 3
2555c6e [Description]:4.66.0.0 commit 2
b82ba0f [Description]:4.66.0.0 commit 1

The 4.66.0.0 version recently added 2 requirements and fixed a bug. The bug submission record is commit2, so you can only merge commit2 into other branch versions

git cherry-pick 2555c6e

If there is a conflict, after the conflict is resolved, you can execute

git commit

submit, or via

git add .
git cherry-pick --continue

submit

5. Common operations in the daily development process

5.1 Undo operation

5.1.1 After submitting, it was found that several files were missing and not submitted

/* 正常提交 */
$git commit -m "发布v1.0"
/* 发现丢了修改记录，重新添加 */
$git add CHANGELOG.md
/* 重新提交,仍以"发布v1.0的名义提交"，最终只有一个提交*/
$git commit --amend

5.1.2 Undo the last submission, but keep the temporary storage area and the current modification unchanged

/* 正常提交 */
$git commit -m "发布v1.0"
/* 将会撤销“发布v1.0”的提交，但是保留暂存区和当前目录中文件的修改 */
$git reset --soft HEAD~

5.1.3 Undo the last submission and modification of the temporary storage area, leaving only the current modification unchanged

/* 正常提交 */
$git commit -m "发布v1.0"
/* 将会撤销“发布v1.0”的提交，撤销暂存区，但保存当前目录中文件的修改 */
$git reset --mixed HEAD~

5.1.4 Undo the last submission, and discard all modifications, including those in the temporary storage area and the current directory, and roll back to the last submission as a whole

/* 正常提交 */
$git commit -m "发布v1.0"
/* 将会撤销“发布v1.0”的提交，但是保留暂存区和当前目录中文件的修改 */
$git reset --hard HEAD~

5.1.5 Undo the modification of all files in the temporary storage area and the current directory, and file back to the last submission as a whole

Note: This operation is very dangerous, all modifications will be lost, and the whole file will be directly rolled back to the specified version, use with caution

/* 正常提交 */
$git commit -m "发布v1.0"
/* 修改多个文件 */
/* 添加到暂存区 */
git add .
/* 撤销暂存区和本地目录下所有文件的修改，并整体回档到上一次提交的状态 */
$git reset --hard HEAD
/* 可以修改HEAD为SHA-1值回档到任意版本 */
/* 使用git log查看每次提交的SHA-1值，可以仅指定前7位 */
$git reset --hard 745d8cd

5.1.6 Submit the file to the temporary storage area and withdraw it

After performing a git add operation on the file, re-withdraw

/* 添加文件到暂存区 */
$git add README
/* 将文件从暂存区撤回 */
$git reset HEAD README

5.1.7 Undo changes to the file

After modifying the file, it is found that the thinking is wrong, and the file needs to be restored to its original state

/* 撤销对CHANGELOG.md文件的修改，请注意这是一个危险的命令，
 * 对指定文件的修改都会被取消，会还原成上次提交的样子 */
$git checkout -- CHANGELOG.md

6. Summary

This article describes the workflow commonly used by software engineers in the enterprise development process. Later, it will publish the usage method of gitlab workflow suitable for small teams or one project per person, the construction of gitlab version control software, continuous development/continuous integration (CI/CD) , related content of automated testing, so stay tuned!

— Recommended by bloggers’ popular columns —

• Python zero-based quick start series
• In-depth explanation of i.MX8 enterprise-level development combat series
  
• MQTT from entry to improvement series
• Object Detection Quick Start Series
• Quick Start for the Autonomous Driving Simulator AirSim
• Security Tool SELinux Getting Started Series
• Python Data Science Quick Start Series