新人如何使用git加入到团队开发中

灰太狼 2022-08-29 10:07 275阅读 0赞

### 文章目录 ###

*  引言
 *  基本概念
 *   *  git四个基本工作区域
     *  不同工作区在实际开发中的应用场景
     *  git分支开发规范
     *  分支开发应用场景
     *  git commit 开发规范
 *  基础命令
 *   *  git merge 合并冲突
     *  git rebase 变基操作
     *  git reaset 版本重置
 *  实际开发场景如何应用git
 *   *  1、 将团队的代码库下载到本地
     *  2、 在本地进行编码和测试工作
     *  3、 在发起PR/MR时，要求提交历史仅有1个
     *  4、 开发进行一半，需要同步远端主分支的最新代码
 *  Reference

# 引言 #

刚刚进入团队的同学往往并不能很快适应团队化的开发，为了减少团队新同学的学习成本，本文将介绍git版本控制工具。值得注意的是，本文并非大而全的git说明文档，本文只是将工作中常用到的使用场景和命令提取出来，进而帮助团队新同学快速成长。

# 基本概念 #

## git四个基本工作区域 ##

> 在git中分为四个基本工作区域：  
> Workspace： 工作区，就是你平时存放项目代码的地方  
> Index / Stage： 暂存区，用于临时存放你的改动  
> Repository： 仓库区（或版本库），就是安全存放数据的位置，这里面有你提交到所有版本的数据。其中HEAD指向最新放入仓库的版本  
> Remote： 远程仓库，托管代码的服务器，可以简单的认为是你项目组中的一台电脑用于远程数据交换

四个基本区域的流转如图所示。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2d1aTk1MTc1Mw_size_16_color_FFFFFF_t_70]

## 不同工作区在实际开发中的应用场景 ##

**在实际的开发过程中，具体的流转流程如下所示：**

1.  使用git clone命令拉取远程仓库到本地
2.  使用git checkout命令，切换到你要开发的分支。一般不在原分支中作修改，而在稳定的分支上新建分支进行操作
3.  修bug，就在稳定的分支上新建fix分支
4.  新功能，就在稳定的分支上新建feature分支。在新分支上进行编码和测试操作
5.  使用git add 和 git commit命令来将所作的更改提交到本地仓库，每一次使用commit命令都会产生一条提交日志。
6.  使用git push命令将分支推送到远程分支之上
7.  待同事Review之后，将分支合并到稳定分支上

## git分支开发规范 ##

git中常见的分支包括以下几种分支，如图所示：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2d1aTk1MTc1Mw_size_16_color_FFFFFF_t_70 1]

*  master分支。用于部署到生产环境，一般由 release 或 hotfix 分支合并，不允许直接在 master 分支上修改代码
 *  release分支。预上线分支，一般由 develop 或 hotfix 分支合并，不建议直接在 release 分支上直接修改代码。
 *  develop分支。测试分支，一般用于测试环境中。始终保持最新完成以及 bug 修复后的代码。  
    若开发时间短，可直接在该分支进行开发、测试，在测试完成后直接推送到远程仓库。  
    若开发时间较长，则需在该分支上新建feature分支，待feature分支开发、测试完成后，推送到远程仓库，利用分支合并功能，合并该分支到develop分支上。
 *  feature分支。该分支为需求开发分支，命名规则为 feature- 开头，一旦该需求上线，便将其删除。
 *  hotfix分支。当线上出现紧急问题需要马上修复时，需要基于 release 或 master 分支创建 hotfix 分支，修复完成后，再合并到 release 或 develop 分支，一旦修复上线，便将其删除。

**总结：master和release分支不可直接更改，只能通过分支合并的方式来变更。日常开发一般在develop分支、deature分支和hotfix分支上工作。**

## 分支开发应用场景 ##

**遇到新需求**

*  遇到新需求时，即可在develop开发分支上直接编程、测试、推送，也可以新建分支完成该需求。具体分情况讨论，建议新开分支操作，避免与其他同事的提交代码产生冲突。  
    如果新开分支，则一定要在稳定的分支上完成新建操作。
    
     *  如果develop分支上所有的代码都是经过测试的稳定代码，那么可由该分支新建feature分支。
     *  如果develop分支上存在尚未测试的代码，那么建议从master或者release分支上下载稳定的代码进而新建feature分支开发。

**修复BUG**

*  develop分支存在BUG。如果仅仅是该分支存在BUG，而master和release分支不存在bug，那么可直接在该分支新建fix分支，待修复bug后，将该分支合并到develop分支，然后删除该fix分支。
 *  若master分支或release分支存在bug，那么需要回顾下develop分支是否有相同的bug。然后基于master分支新建fix分支，后将该fix分支分别合并到master分支和develop分支上。  
    总结：如果是新需求，那么在稳定的分支上新建feature分支，如果是线上bug，那么在线上环境所在分支上新建fix分支，待开发测试完成后，分别合并到master分支和develop分支上即可。

## git commit 开发规范 ##

日常开发中的每一次代码变更，都需要利用git commit命令来记录变更，为了使代码变更清晰易懂，应该使用一定的规范来commit的内容。

**推荐的git commit提交格式**

> type \[必须\]。  
> 用于说明git commit的类别，只允许使用下面的标识。  
> feat：新功能（feature）。  
> fix/to：修复bug，可以是QA发现的BUG，也可以是研发自己发现的BUG。  
> docs：文档（documentation）。  
> refactor：重构（即不是新增功能，也不是修改bug的代码变动）。  
> perf：优化相关，比如提升性能、体验。  
> test：增加测试。  
> chore：构建过程或辅助工具的变动。  
> revert：回滚到上一个版本。  
> merge：代码合并。  
> sync：同步主线或分支的Bug。

> scope \[可选\]。说明 commit 影响的范围，比如数据层、控制层、视图层等等，视项目不同而不同

> subject \[必须\]。subject是commit目的的简短描述，不超过50个字符，可以是中文描述

**commit 规范示例：**

> fix(DAO):用户查询缺少username属性  
> feat(Controller):用户查询接口开发

# 基础命令 #

> 知道了基本概念之后，在实际开发过程中需要掌握具体的命令和工具来将git应用到实际开发过程中，此处将介绍工程开发中常用的若干命令。此处的脑图为了方便记录常用的命令，然而本文并不会介绍所有的命令，尤其是基础的命令，只会介绍在开发过程中经常用到的不太好理解的命令。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2d1aTk1MTc1Mw_size_16_color_FFFFFF_t_70 2]

**强烈建议看Reference中的git 命令10大命令图解。**

## git merge 合并冲突 ##

> 当想要合并的两个分支的同一文件中的同一行代码上有不同的修改，或者一个分支删除了一个文件而另一个分支修改了这个文件时，Git 就会产生分支冲突。在这样的情况下，Git 会询问你想要保留哪种选择？

**git merge在使用的时候，有以下两种合并场景**

*  fast-forward模式，fast-forward！这类合并不会创建新的提交，而是会将我们正在合并的分支上的提交直接合并到当前分支。即合并的结果不会产生结，而会形成一条直线。  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2d1aTk1MTc1Mw_size_16_color_FFFFFF_t_70 3]
 *  No-fast-foward (—no-ff)。Git 会在当前活动分支上创建新的 merging commit。这个提交的父提交（parent commit）即指向这个活动分支，也指向我们想要合并的分支！即会产生分支合并的结，如下所示。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2d1aTk1MTc1Mw_size_16_color_FFFFFF_t_70 4]

## git rebase 变基操作 ##

**使用场景一： 不同分支进行rebase操作**

开发者在feature分支上开发新功能，而此时master分支上同事推送了新的代码，因此如果feature分支需要获得master分支的代码只有两种形式。

*  git merge。将master分支的变更合并到当前的feature分支上，这大会产生合并的结，使你feature分支的提交不清晰。不推荐
 *  git rebase。**建议看Reference中的动图。** 该命令会将master分支的变更同步到本地，同时，修改你feature分支的基础commit。

rebase前  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2d1aTk1MTc1Mw_size_16_color_FFFFFF_t_70 5]

rebase后  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2d1aTk1MTc1Mw_size_16_color_FFFFFF_t_70 6]

> 总结：在进行分支合并时，feature分支合并到develop分支/master分支时，建议使用git merge。而master分支/develop分支的变更合并到feature分支时，推荐使用git rebase。这会使提交历史更清晰。

**使用场景二：同一分支进行rebase操作，实现压缩commit**

日常在feature开发工作中，往往会稍作一点变更就git commit提交该变更，然而当该feature分支合并到develop分支时，会导致大量的develop的分支历史及其不清晰。因此，需要压缩commit，将所有的commit合并为一条，然后再向develop分支提出分支合并请求。

git rebase -i HEAD~3    #整理HEAD附近3条的commit记录
    git rebase -i $COMMIT_ID #整理指定COMMIT_ID之前的所有commit记录
    #上述命令会进入到一个交互式的编辑界面
    # 将除第一条以外的commit都改为squash即可将所有的commit合并到第一条记录中。

> 另：如果当前commit历史较为复杂，并非一条直线时，该命令将会产生冲突，无法达到合并commit的结果。故建议下游更新上游代码时，使用git pull --rebase，或者 git fetch + git rebase的操作，使下游分支提交历史较为清晰。不然在合并commit时会遇到麻烦。

## git reaset 版本重置 ##

当开发者不想要之前提交的修改时，就会用到这个命令。重置又分为软重置和硬重置。

**软重置：**

软重置会将 HEAD 移至指定的提交（或与 HEAD 相比的提交的索引），而不会移除该提交之后加入的修改！

git reset --soft HEAD~2  #还原到两个版本前
    git reset --soft $COMMIT_ID #还原到指定版本

> 另：由于软重置会保留修改的内容，故也可用于合并多个提交为一个提交。具体操作为将git reset重置为自己的首次提交，然后重新使用git commit进行提交。该命令在本地提交历史极为复杂（产生了各种merge的结）时，依然十分有效。

**硬重置：**  
该命令不会保存你提交过的修改，强制使代码回退到之前的某个版本。

git reset --hard $COMMIT_ID

# 实际开发场景如何应用git #

## 1、 将团队的代码库下载到本地 ##

**此处分为两种场景。**

*  对团队的代码库有开发权限，那么可直接使用git clone命令将代码库下载到本地
 *  对团队的代码库没有开发权限，那么需要先fork团队的仓库到自己的仓库中，接着克隆自己的仓库到本地

## 2、 在本地进行编码和测试工作 ##

1.  新建分支。在稳定分支上（develop分支/master分支/release分支，具体问导师）新建开发分支(feature分支/fix分支)。–> git checkout
2.  在新建分支上进行编码和单元测试工作。–> git add && git commit
3.  将单元测试后的代码分支推送到远程仓库。–> git push
    
    > a.如果出现了冲突，需要先用git fetch命令，将远程仓库拉下来  
    > b. 使用git merge命令合并冲突  
    > c. 使用git push 再次推送。  
    > d.也可直接git pull(直接进行了git fetch 和git merge操作)， 然后git push。
4.  在github上发起PR/gitlab上发起MR，请求别人review自己的代码，然后将自己的代码合并到测试分支(develop分支)上。  
    将develop分支的代码应用到测试环境中，如果有问题则回退到第2步继续进行开发  
    将develop分支测试稳定的代码，提交PR/MR到稳定分支(master/release)上，进而在生产环境中应用该代码。

## 3、 在发起PR/MR时，要求提交历史仅有1个 ##

*  使用git rebase命令
 *  使用git reset命令

> 具体使用方法在基础命令一节

## 4、 开发进行一半，需要同步远端主分支的最新代码 ##

*  git status 查看当前项目的状态，如果有未保存的修改，就git add . 和 git commit -m $message保存下来
 *  git pull --rebase origin develop 使用这个指令将远端的主分支以 rebase 的形式 “合进”当前分支

> 也可使用git fetch + git rebase的形式

*  git log 查看当前分支下的 commit message 是否符合预期

> 总结：下游需要上游代码，使用git rebase获取上游最新代码，进而保证下游分支提交历史清晰、简洁。

# Reference #

[git分支规范][git]  
[git commit提交规范][git commit]  
[动图展示10大命令][10]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2d1aTk1MTc1Mw_size_16_color_FFFFFF_t_70]: /images/20220829/1aa175ab8c3f4eae981098da4c5b4784.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2d1aTk1MTc1Mw_size_16_color_FFFFFF_t_70 1]: /images/20220829/310fd1879c4041fc925cd503f588b98b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2d1aTk1MTc1Mw_size_16_color_FFFFFF_t_70 2]: /images/20220829/d1b71c05cbbf45bfbe0bc7991cd7c041.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2d1aTk1MTc1Mw_size_16_color_FFFFFF_t_70 3]: /images/20220829/c9ec618f7245484aa0e728ccdb4f9037.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2d1aTk1MTc1Mw_size_16_color_FFFFFF_t_70 4]: /images/20220829/2cc4cce3fd594656bdda1471ad64c492.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2d1aTk1MTc1Mw_size_16_color_FFFFFF_t_70 5]: /images/20220829/c8fe0a5a484744b185e6abebdb20e517.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2d1aTk1MTc1Mw_size_16_color_FFFFFF_t_70 6]: /images/20220829/ce39022fdeba461996d16791f7fee6a9.png
[git]: https://zhuanlan.zhihu.com/p/108385922
[git commit]: https://zhuanlan.zhihu.com/p/182553920
[10]: https://zhuanlan.zhihu.com/p/132573100