git workflow

基本概念：

remote name : origin

fetch: 从 remote 拉取所有的到本地，从而为下一步的checkout做操作。

checkout: 切换到指定的local分支（前提，remote已经将该分支放置到本地）

于是，为了偷懒，有个这个命令：

git checkout -b local-repo-name remote-name/remote-repo-name

等价于

git fetch remote-repo-name + git checkout local-repo-name

 

 

下一篇文章: 完善这个坑.

待补充:

1. rebase 操作 和 merge 操作干了些什么

2. 参考阅读的 “读后感”.

 

参考 :

http://ihower.tw/blog/archives/5140

Sugar:

生成 git repo 用户分支列表:

"C:\Program Files (x86)\Git\bin\git.exe" for-each-ref --format=%(authordate:iso8601)%09%(authorname)%09%(refname)%09%(objectname)%09%(authordate:relative)%09%(subject)%09

 

正文:

1. branch name 的选择

目的: 集中管理(尤其是清理删除)某个release相关的feature.

情景:

Solution:

TortoiseGit 有个很棒的feature: 如果名字为 feature/版本号/需求名称,

那么, 所有的 branch 就会根据 branch name, 由 TortoiseGit 自动进行 层级式的 聚类.

这样, 开发完成之后, 可以对整个 cluster 的 branch 集中删除.

 

 

2. Release/Develop/功能性branch 和 rebase/merge

功能性branch: 每个release衍生出的各种 feature/bugfix 这样的branch,

 

目标: (1) 减少分支合并所需要花费的时间 (2)历史单线化

情景:

merge: 根据merge行为的操作, 原本处于 “等价”地位的 多个 branch, 在 history 中, 会给开发者带来 “前后依赖”的 “错觉”. 在 diff 时, 往往找不到 前后衔接 的 commit.

history graph 的表现就是 ? (待补充)

这是 现代 团队开发 所无法避免的.

rebase: 单线化演进, 这样比较符合软件开发的过程(意味着, 进行 diff 操作 比较简单, 而且, history graph 比较清晰).

就像 一个人在开发软件的旧时代一样.

然而, rebase虽好, 但是 现实是 :

即使feature划分的很好, 但是, 代码中的 *耦合性* 很高, feature 和 release (此时已经融合了新的feature) 进行rebase式的合并时, 会和其他的多个 MODULE 出现冲突. 这个时候,

rebase就是很 “痛苦”的了. 相比较之下, feature内部 进行 rebase 操作, 同一模块的 之间的冲突, 会比多个模块间的冲突 小得多(PM的观点, 需要数据/理论支持).

这样的好处: feature内部是单线化的, feature 和 release 之间存在多线; 同时, 避免了 feature 和 release 之间因为 rebase 产生的大量 merge 操作. 这是一个 trade off.

 

rebase 在将 分支A 添加到 分支B 后面时, 是所有的 commit 视作 整块, 将 A 的最后一个 commit 和 B 的第一个commit 进行 diff/merge.

why? 分支A 的最后一个merge, 显然保证 和 A 之前所有的 commit 都是 无冲突的. 但是, 和 之后的 commit 就没法保证了.

 

会有2个效果:

(1) 提交时间在 块内 保持一致, 在块间 会出现 时间先后的错乱.

(2) 刚才提到的 A尾部和 B首部 的 merge之后的 新的 commit, 会作为B的新的 第一个commit,

并且, 会和 之后 B 的每个 commit 进行diff/merge. 如果 B 的 commit 很多的话, 那么, 就会有多次的 diff/merge.

 

Solution:

(1) rebase 比较适合 同一个 MODULE, 多个Dev同时开发的情景

(2) rebase 之前, 将各自分支的多个 commits, 实施 reset –soft 合并成单个 commit (减少中间过程)

?作者: 是否可以通过频繁的 rebase 来解决呢? 但是, 从开发体验来讲, 每次可能被分配同一模块的多个”功能点”, 更习惯(习惯是可以改的) 所有功能点完成之后, 再和其他开发者rebase.而每个功能点可以合成一个commit.

rebase 的目的