我常用的 Git 开发工作流
我常用的 Git 工作流
目前，绝大部分的互联网公司，开发都是使用 GitLab 或者 Github 作为代码的托管所。
想分享一下个人日常工作的流程，从新做一个需求到需求代码合入。
使用到的工具：Git + Sourcetree
Git 项目地址：plaid 仓库
封面
面对部门的一个工程仓库「以 https://github.com/android/plaid 为例」，我会采用 fork 的形式, 这样在自己的空间里面就会有一个对应名称的工程仓库。
分为以下步骤：
1. Fork 仓库到自己的空间中
在 https://github.com/android/plaid 点击 Fork ， 会拷贝一份当前的仓库到自己的空间
例如：
fork 按钮
此时会在自己的空间下出现一个 Fork 工程的项目：
Fork 的好处是，你可以随便在自己空间下的仓库中，修改各种内容。
然后拷贝该仓库的 SSH，我们在终端中可以使用 git clone 把当前这个仓库代码下载到电脑本地：
// 下载到本地
git clone git@github.xxx/plaid.git
// xxx 为你的 github 的账号名称
2. 添加 remote 信息
fork 到本地后，如何保持和源仓库的代码同步呢？
切换到本地该项目的目录，我们可以使用 git remote add xxx 的方式去添加源仓库的地址：
// 进入该项目目录
cd plaid
// git remote add [名称] [源仓库地址]
git remote add plaid git@github.com:android/plaid.git
同时可以使用 git remote -v 查看该仓库的 remote 信息:
remote 信息
当我们想要跟新自己仓库的代码，保持和源仓库的代码一致，我们需要：
// git fetch plaid ,plaid 是你为远端源仓库起的名字
git fetch plaid
// 想要同步本地 develop 分支的代码
git rebase plaid/develop
// 更新远端 develop 代码；origin 是你 git 空间下该仓库的名称，默认
git push origin develop
这样一来，本地的代码就和源仓库的 develop 分支保持一致了。
注：
git remote add [名称]
这里的名称，个人喜欢和源仓库的名称一致，用作区分不同的 remote 信息
当然你可以add多个远端地址， 例如git remote add zhangsan git@github.com:zhangsan/plaid.git
3. 新建分支，完成需求
当我们需要完成需求时，往往需要新建分支。这也是我们日常工作的一种方式，每一个需求对应一个分支，便于后面找问题时及时定位。
比如我们的需求是新增标签，期望上线的版本是 x.y 「例如 5.30 版本」
新建分支：feature_5.30_add_tag
// 新需求，从 develop 拉取分支
git checkout develop
// 更新远端代码
git fetch plaid
// 更新本地 develop 分支
git rebase plaid/develop
// 新建分支：git checkout -b feature_x.y_xxx
git checkout -b feature_5.30_add_tag
这样一个新的分支就会被成功创建，然后在新的分支上开始自由的开发。
分支的名字： 我为什么这么取名字？
主要还是为了便于区分以下内容：
- 当前分支是什么？「新需求还是
bugfix」 - 什么时候上？「
5.30」版本 - 这个需求是关于什么的？「
add_tag」 - 一个好的分支名字，可以快速帮忙其他人熟悉业务需求
注：
- 新需求我会以：
feature_5.30开头bugfix我会以fix_5.30开头
4. 需求完成后，如何提交？
从我们的 remote -v有多个时，就决定了我们是以 MR「merge request」 的形式向远端仓库提交代码合入的。
注： 在
GitLab中被称为Merge Request;
在GitHub中被称为Pull Request；
两者没有本质区别。可参考这里
为什么呢？因为我们通常会把 develop 和 release 分支保护起来，我们不能允许直接向这两类分支合入代码，为了工程的安全考虑，转而通过 MR 的方式，经由 Code Review 后合入。
那么 MR 如何提交呢？
// 添加修改的改动
git add .
// 提交修改的改动
git commit -m "提交标签代码"
// push 到你空间下工程的远端
git push origin feature_5.30_add_tag
这时，git 的默认配置下，会生成一个链接，如下所示 ：
push 后
点击链接即可创建一个新的 MR 或 PR , 如下：
MR详情
然后填写各项信息，最后点击 create pull request 即可。
这样便会创建一个从 origin/feature_5.30_add_tag 向 plaid/develop 合并的 MR.
注：这里的具体界面不同的公司应该是不同的，这里举例使用的
github上的样式。
所以，截图上的样式出现的是pull request, 这里不用在意，本质上是一样的工作原理。
5. 在 MR 合并过程中，会出现的问题
首先，我们需要经过 Code Review ，确认代码不会引入问题，才会合进去；
其次在合并的过程中，可能会出现需要 rebase local 的操作，这是因为我们要合入的分支「develop」已经有其他的 MR 合入了，为了避免代码冲突，需要我们本地先把代码对齐我们要合入的分支 「develop」
5.1 Code Review
我们写的代码，一般需要经过 Code Review 才行，在 MR 上，有一项 changes 可以看到本次 MR 所修改的代码。
通过这种方式可以看到我们本次的改动，可以进行代码 review.
开篇时提到一款工具，Sourcetree。
Sourcetree ，我常常用它来看我当前的代码改动，因为用这个看会比较方便「相比 AS 自带」。
例如， 选中多个 commit , 看这些 commit 的代码改动:
代码改动
两述两种方式都行，看个人操作习惯。
5.2 解决冲突，更新代码
通常会有两种方式，一种是 rebase; 一种是 merge;
关于两者的区别，在这里不再介绍。
个人推荐使用， merge：
-
merge会新建立一个提交commit，便于后续的代码追踪； - 同时，当代码冲突时，
merge更加友好，一次性解决所有的冲突，而rebase会一个一个commit解决，比较繁琐。
示例如下：
// merge 操作
// 从 feature_5.30_add_tag 分支切换到 develop
git checkout develop
// 拉取源代码远端最新
git fetch plaid
// 本地 develop 分支更新为最新
git rebase plaid/develop
// 切换到上一个分支，即：feature_5.30_add_tag
git checkout -
// 把本地的 「develop」 分支向 「feature_5.30_add_tag」 分支 merge 代码；
git merge --no--f develop
...
// 解决冲突或其他问题
...
注： 当代码冲突时，一定要仔细，不可概括的处理。曾经遇到过，同事只要代码冲突时就选择
accept others的这种操作……「千万不要这样」。
6. 后续
当我们的代码合入之后，此分支也不再具有其他作用，不会继续在此分支上做新的开发。
那么，我们可以开始……新建分支，做新的需求了……(o^^o)
2020.4.26 by chendroid
完
