Git代码提交说明文档-初稿

Git代码提交说明文档-初稿

1 写在前面的话

该文档以一个软件工程师在整个产品开发周期中的代码提交过程为场景，来为软件开发人员提供详细的Git提交以及分支管理使用参考。

其中，产品开发周期主要分为几个阶段：EV (开发验证，送样)、DV (试产)、PV (量产)

本文档包括以下四方面：指令说明，错误处理，分支管理，场景示例。

2 指令说明

基础代码

git add .
git commit -m "提交注释"
git tag V1.0 -m "realse v1.0"
    
git push -u --all			//远程推送所有分支
git push -u --branch_your	//远程推送需推送的分支
git push -u --tag			//远程推送标签
    
git checkout -b branch_new	//新建分支并切换到新分支
git checkout master 		//切换分支
git branch -d branch_new	//先切换到母亲分支，再执行该指令删除新建分支

git log --oneline --graph	//查看当前Log
git reflog --oneline		//查看所有Log记录
    
git checkout .				//清空当前修改的代码（未add）
git stash					//清空当前add后的代码(已add)
git reset HEAD^				//撤销最近一次的commit,没有把add暂存区代码清除掉
git reset --hard HEAD^		 //撤销最近一次的commit,把add的暂存区代码清除掉了

git reset --hard ab002		//硬回退到ab002提交版本，这个是代码也会回退，穿越时空带你玩；
git reset --soft ab002		//软回退到ab002提交版本，但是暂存区代码并不会回退，也就是直接head指针回退了。主要用来修复之前某次提交的代码有问题。

2 错误处理

（1）代码撤销：

更改代码但最终没有实现功能，想把更改的代码全部撤销掉。此时分为3种情况：

① 更改代码，但是没有git add

git checkout .

② 更改代码，已经git add，但是没有git commit

git stash

③ 更改代码，已经 git add 与 git commit

git reset --hard HEAD^		 //撤销最近一次的commit,把add的暂存区代码清除掉了
git reset HEAD^				//撤销最近一次的commit,没有把add暂存区代码清除掉

（2）代码修复：

比如commit提交了10次，现在发现第2次提交的代码有一处不对，想要修改一下，可以使用以下操作：

git log --oneline --graph	//获取提交的hash值。假设第二次提交的hash值为ab002,当前hash为ab0010
git reset --soft ab002
//然后修改或者完善你的代码
git reflog --oneline
git reset --soft ab0010
git add .
git commit -m "修复第二次提交：增加解放东京的功能"
git log --oneline			//此时就可以看到在第10此提交的基础上多了一个修复提交，而其他代码没有受到影响；

（3）版本回退：

如果你想直接回退到第二次提交时的版本重新编译烧录，那就是使用git reset --hard。这里有两个思路：

① 在开发分支上reset --hard 第二版本，编译验证；然后再reset --hard会最近的版本

git log --oneline --graph	
git reset --hard ab002
//然后编译烧录去验证某个版本
git reflog --oneline
git reset --hard ab0010

② 在开发分支上新建一个分支，然后在新建分支上reset --hard，编译验证后可以checkout回开发分支上，把新建分支delete掉，好像什么都没有发生。

git checkout -b b_EV_v1.2

git log --oneline --graph
git reset --hard ab002
//然后编译烧录去验证某个版本
git checkout develop	//或者你的主要开发分支
git branch -d b_EV_v1.2

3 分支管理

远程仓库有两个作用：

① 保存代码，防止本地误操作或设备损坏，丢失造成代码丢失。
② 团队协作，多人在 leader 的任务分配下完成一个项目。
目前的公司的项目很少有团队协作，所以 gitlab 主要是用来存放代码。

在使用 Gitlab 进行代码管理时，目前以独立项目独立仓库原则比较合适。具体地：
① 团队负责人为即将开发的项目建立一个空的远程仓库。（或者开发人员自行建立）。
② 在群组内有一个标准 sdk 的仓库，项目开发者克隆标准 sdk 仓库，此时本地就有了一个已经存在的仓库。
③ 将这个仓库再上传到即将要开发的项目远程仓库中。再着手开发！

在进行项目开发过程中，代码管理应该符合以下逻辑：（暂定）

为了简化 git 代码管理流程，所有功能直接在 Develop 分支上开发，在 master 分支上发布。
开发永远都是在 develop 分支上完成的，master 分支上保留当前最稳定的软件版本。

master分支只能由 develop 合并，不能在这个分支上做提交。

在每次develop上的代码提交给测试部时都必须打上一个tag，标签要与测试 release note 文档中软件版本号保持一 致。
在每次 develop 分支向 master 分支合并时，也要打上一个软件版本的标签 tag，标签要与产品周期代号保持一 致。
这里建议master上的tag表示一个阶段内最稳定的版本，如release_V1.0（EV送样）、release_V2.0（DV试产）、release_V3.0（PV量产）。

当某个功能点比较复杂，需要分解 多次提交/多个子任务 才能完成时（比如闪灯问题）可以从 develop 分支拉出来一个单独的 feature 分支，等任务完成后 feature 分支先合并到本地develop 分支，将 feature 分支删除，再将本地 develop 分支推送 push 到远程 develop 分支。

而其余简单的功能点也可以直接在 develop 分支上进行开发。

4 场景示例

这里以软件工程师工作时的流程来进行描述。

（1）新建远程仓库

（2）初始化本地仓库

初次提交、上传远程仓库

git init
git remote add origin git@192.168.2.188:gaohui.luo/mabel-t3.git

git add .
git commit -m “first commit: SDK_v2.5.0”

git push -u --all

（3）新建开发分支

git git checkout -b develop/* 开始干活，在develop分支上编程实现功能点0 */
git add .
git commit -m “your commit message”
git push -u --all 

（4）在开发分支上新建特性分支

有些功能比较复杂或者是一类相同的任务(如按键、灯闪)，则在开发分支上新建特性分支，开始干活。

git checkout -b b_feature_1/* 开始干活，在b_feature_1上编程实现功能点1 */
/* 完成该分支的功能点1 */
git add .git commit -m “your commit message”
/* 开始干活，在b_feature_1上编程实现功能点2 */

/* 完成该分支的功能点2 */
git add .git commit -m “your commit message”
/* 循环往复，直到feature这一大块内容完成 */

第二天又验证了一下，发现最近的commit提交后代码有问题，或者commit的备注信息写的不好，那么：

/* 若此时发现上功能点代码写错了，或者需要完善 */
/* 开始编程，更改或者完善功能点2代码 */

git add .
git commit --amend -m “your commit message”

这时候会直接把上次的提交覆盖掉，提交的注释也会覆盖掉；

（5）特性分支合并到开发分支

该特性分支功能开发完成，要合并到develop开发分支

git checkout developgit merge --no-ff b_feature_1
git branch -d b_feature_1		//也可以保留该分支，删除与保留对develop没有影响git
push -u --all

此时会弹出来一个VIM编译页面，让你输入为什么合并的备注，可以直接按【ESC】，然后【shift + : 】，输入【wq】即可。这时候可以查看下Log信息:

git log --oneline --graph

（6）继续开发其他功能点；

这里如果功能比较复杂或也是某一类的，就如上所述新建一个特性分支来开发，完成后merge到develop分支上。而对于比较简单的功能点，可以直接在develop上开发。

在开发某个功能点的时候，由于是第一次做，把代码改的乱七八糟，很多文件都被动过了，结果测试下发现实现不了，想把改动的代码恢复到提交时的状态。可以如下操作：

git checkout .==> 没有add
或者
git trash ==>有add ，但是没有commit
或者
git reset --hard a2g3h4nej3 ==> 已经commit
其中，a2g3h4nej3这个是上次提交后的hash值。

详情参考第二章：错误处理

（7） EV阶段发给测试部测试

已完成UI上所有功能，在develop分支上打上一个标签，备注要和发给测试部的软件的版本号一致

git tag EV0.4_CToolV1.4.10 -m “S5090_AB1562M_20210504_EV0.1_CToolV1.4.10”
git push -u --tag

若发布的版本测出来有问题，那么先把问题分类编号，然后在develop分支上再拉一个分支解决BUG；

git checkout develop
git checkout -b b_bugfixed#001    
/* 解决问题1 */
git add .
git commit -m “your commit message”
/* 问题#001解决 */
git checkout developgit merge --no-ff b_bugfixed#001
git branch -d b_bugfixed#001
git push -u --all

这个过程是要经历好几轮，每次发给测试部的软件都必须在develop分支上打上版本标签，并确保推动远端

//在develop分支上打上一个标签，备注要和发给测试部的软件的版本号一致
git tag EV0.4_CToolV1.4.10 -m “S5090_AB1562M_20210504_EV0.2_CToolV1.4.10”    
/* 又经过N多Bug Fixed */

/* 解决第二批问题 */   
//在develop分支上打上一个标签，备注要和发给测试部的软件的版本号一致
git tag EV0.4_CToolV1.4.10 -m “S5090_AB1562M_20210504_EV0.3_CToolV1.4.10”

/* 后面依次类推即可 */

（8） 送样

​ 已解决EV阶段内部测试部报的所有BUG ，测试部say YES ! 送样！

​ 将develop分支merge到master分支上。

git checkout mastergit merge --no-ff develop
git log --oneline --graph
git tag V1.0.0 -m “release V1.0.0”
git push -u --all
git push -u --tag

客户反馈样机问题

客户测试会各种反馈BUG ，把问题分类编号，然后在develop分支上再拉一个分支解决BUG

git checkout -b b_bugfixed#001
/* 解决问题4 */
git add .git commit -m “your commit message”
git push -u --all
/* 问题#004解决 */
git checkout developgit merge --no-ff b_bugfixed#004
git branch -d b_bugfixed#004
git push -u --all
git tag EV0.4_CToolV1.4.10 -m “S5090_AB1562M_20210504_EV0.5_CToolV1.4.10”

经过很长一段时间的Bug Fixed，产品会进入试产阶段；

（9）试产

将develop分支merge到master分支上。

git checkout master
git merge --no-ff develop
git log --oneline --graph
git tag V2.0.0 -m “release V2.0.0”
git push -u --all
git push -u --tag

工厂会各种反馈BUG ，把问题分类编号，然后在develop分支上再拉一个分支解决BUG；

这些步骤和送样均相同，只不过打的标签名称要注意不一样

git tag DV0.4_CToolV1.4.10 -m “S5090_AB1562M_20210504_DV0.5_CToolV1.4.10”

经过很长一段时间的Bug Fixed，产品会进入量产阶段。

（10）量产

将develop分支merge到master分支上。

git checkout master
git merge --no-ff develop
git log --oneline --graph
git tag V4.0.0 -m “release V4.0.0”
git push -u --all
git push -u --tag

工厂会各种反馈BUG ，把问题分类编号，然后在develop分支上再拉一个分支解决BUG；

git tag PV0.5_CToolV1.4.10 -m “S5090_AB1562M_20210504_PV0.5_CToolV1.4.10”

每个批次的产品都要在develop和master打上标签批次的版本号。

• Gavin 2021