Git Flow_安科网

参考文章：

我的Git Flow

master 是长期分支，一般用于管理对外发布版本，每个 commit 对一个 tag，也就是一个发布版本
develop 是长期分支，一般用于作为日常开发汇总，即开发版的代码
feature 是短期分支，一般用于一个新功能的开发
hotfix 是短期分支，一般用于正式发布以后，出现 bug，需要创建一个分支，进行 bug 修补。
release 是短期分支，一般用于发布正式版本之前（即合并到 master 分支之前），需要有的预发布的版本进行测试。release 分支在经历测试之后，测试确认验收，将会被合并的 develop 和 master

开发新功能步骤

从开发分支拉一个功能分支
功能分支开发和测试
功能分支 rebase 开发分支（为什么）
功能分支合并到开发分支（Merge Request）

注意：

一次提交做一件事，写清楚 comment
每次 pull 远程分支时使用 git pull --rebase
分支从哪拉出来，最后合到哪回去
合并之前先 rebase

fix bug 步骤

测试线bug的修复

和开发步骤类似

线上bug的修复

从master拉一个fix分支（为什么是master）
测试完后 rebase master
合并回master

Git使用要求

commit

commit message 言简意赅，不要写无用信息。不要出现『update』，『Bug Fix』，『Merge Branch ......』, 这样让别人不能领其意的描述
在master和develop上一次commit是一个功能，对于在feature分支上一个功能中有多次提交的情况，在提交Merge Request之前，需要合并为一次commit（使用git reset sha1撤销之前的commiit，再重新提交一次commit来合并，或者git commit --ammend），并@组内人员进行代码评审

Rebase

不要出现反向拉取代码的情况，即看到 develop 有更新，就将 develop 的代码拉取 merge 进自己的分支。

原因是：

merge 会导致你的分支都会引入一个外来的合并提交。如果 develop 非常活跃的话，或多或少会污染你的分支。
丑，Network 复杂，增加理解项目历史的难度。

如何解决当前 develop 有更新的情况？

请使用 rebase！

Git 使用技巧

rebase 和 merge

git rebase一般解释为变基，也有解释为衍合。

git merge 和 git rebase 都可以整合两个分支的内容，最终结果没有任何区别，但是变基使得提交历史更加整洁。

提交点顺序

git merge后，提交点的顺序都和提交的时间顺序相同，即 master 的提交在 dev 之后。
git rebase后，顺序变成被rebase的分支（master）所有提交都在前面，进行rebase的分支（dev）提交都在被rebase的分支之后，在同一分支上的提交点仍按时间顺序排列。

分支变化

dev 在 rebase master 后，由原来的两个分岔的分支，变成重叠的分支，看起来 dev 是从最新的 master 上拉出的分支。

什么时候使用 rebase / merge

假设场景：从 dev 拉出分支 feature-a。那么当 dev 要合并 feature-a 的内容时，使用 git merge feature-a；反过来当 feature-a 要更新 dev 的内容时，使用 git rebase dev。

使用时主要看两个分支的"主副"关系。

注意

一般来说，rebase后的 dev 和远程的origin/dev会发生分离，在命令行界面中会提示：

Your branch and 'origin/dev' have diverged,
and have 1 and 1 different commits each, respectively.
  (use "git pull" to merge the remote branch into yours)
复制代码

这时需要用git push -f强制推送，覆盖远程分支。若使用了提示中的git pull，结果会变成合并，并产生一个合并提交点。

慎用git push -f!

git pull --rebase

与 git pull 的区别

在一般情况下，加与不加 --rebase 是没有区别的。

然而，从上面说的 git rebase 功能得知，某个分支可能与其远程分支发生分离，而当你 pull 时使用 git pull，则会变成你的本地分支和远程分支合并。

正确的做法是git pull --rebase，才会拉取到最新的分支。

因此推荐在任何时候 pull 远程分支，最好加上 --rebase 参数。

reset 和 revert

git reset 修改 HEAD 指向的位置
git revert还原某一个提交，并产生新提交来记录本次还原

git reset 常用命令

git reset HEAD {filename}: 取消暂存文件，恢复到已修改未暂存状态。
git reset HEAD~{n}: 表示回退到n个提交之前。它也可以用来合并提交，下面的写法与 git commit --amend 结果是一样的。

git reset HEAD~1
git commit
复制代码

git reset {version}: 后面带版本号，直接回退到指定版本。
git reset的三种参数:
1. 使用参数--hard，暂存区、工作区和 HEAD 指向的目录树内容相同。
2. 使用参数--soft，只更改 HEAD 的指向，暂存区和工作区不变。
3. 使用参数--mixed或者不带参数（默认为--mixed），更改引用的指向及重置暂存区，但是不改变工作区。

————————————————————

git reflog

查看提交记录的命令是git log，而git reflog的功能是查看本地操作记录，可以看到本地的commit, merge, rebase等操作记录，并带有版本号。

b3bf634 {0}: rebase -i (finish): returning to refs/heads/feature-rebase-i
b3bf634 {1}: rebase -i (fixup): 完善a中的判断和输出
dd19de3 {2}: rebase -i (fixup): # This is a combination of 2 commits.
c138acf {3}: rebase -i (reword): 完善a中的判断和输出
a7f47b2 {5}: rebase -i (start): checkout dev
a472934 {6}: rebase: aborting
a7f47b2 {7}: rebase -i (start): checkout dev
a472934 {8}: commit: 添加a输出
c84d5b7 {9}: commit: 添加a中的判断
a5a6e64 {10}: commit: 修改a内容
a7f47b2 {11}: checkout: moving from dev to feature-rebase-i

git stash

把工作区内容缓存到一个栈里，之后用 git stash pop取出。在未提交工作区内容，但是想切到其他分支时非常有用。

注意

不建议同一时间段在不同分支都使用 git stash，涉及到多个分支的情形还是先 commit 较好，不push到远程，下次 commit 时可用 --amend 合到上次提交中。

Git Flow