Git Flow

标签：自己   href   交点   一个栈   提交   其他   ash   要求   界面   

参考文章：

1. 简介我的Git Work Flow
2. 如何优雅的使用Git
3. Git工作流程

我的Git Flow

1. master 是长期分支，一般用于管理对外发布版本，每个 commit 对一个 tag，也就是一个发布版本

2. develop 是长期分支，一般用于作为日常开发汇总，即开发版的代码

3. feature 是短期分支，一般用于一个新功能的开发

4. hotfix 是短期分支 ，一般用于正式发布以后，出现 bug，需要创建一个分支，进行 bug 修补。

5. release 是短期分支，一般用于发布正式版本之前（即合并到 master 分支之前），需要有的预发布的版本进行测试。release 分支在经历测试之后，测试确认验收，将会被合并的 develop 和 master

开发新功能步骤

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

注意：

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

fix bug 步骤

测试线bug的修复

和开发步骤类似

线上bug的修复

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

Git使用要求

commit

1. commit message 言简意赅，不要写无用信息。不要出现 『update』，『Bug Fix』，『Merge Branch ......』, 这样让别人不能领其意的描述

2. 在master和develop上一次commit是一个功能，对于在feature分支上一个功能中有多次提交的情况，在提交Merge Request之前，需要合并为一次commit（使用git reset sha1撤销之前的commiit，再重新提交一次commit来合并，或者git commit --ammend），并@组内人员进行代码评审

Rebase

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

原因是：

1. merge 会导致你的分支都会引入一个外来的合并提交。如果 develop 非常活跃的话，或多或少会污染你的分支。
2. 丑，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 HEAD@{0}: rebase -i (finish): returning to refs/heads/feature-rebase-i
b3bf634 HEAD@{1}: rebase -i (fixup): 完善a中的判断和输出
dd19de3 HEAD@{2}: rebase -i (fixup): # This is a combination of 2 commits.
c138acf HEAD@{3}: rebase -i (reword): 完善a中的判断和输出
a7f47b2 HEAD@{5}: rebase -i (start): checkout dev
a472934 HEAD@{6}: rebase: aborting
a7f47b2 HEAD@{7}: rebase -i (start): checkout dev
a472934 HEAD@{8}: commit: 添加a输出
c84d5b7 HEAD@{9}: commit: 添加a中的判断
a5a6e64 HEAD@{10}: commit: 修改a内容
a7f47b2 HEAD@{11}: checkout: moving from dev to feature-rebase-i

git stash

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

注意

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

Git Flow

标签：自己   href   交点   一个栈   提交   其他   ash   要求   界面   

原文地址：https://www.cnblogs.com/cherishSmile/p/11710639.html