基本概念：
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)Gitingit.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 的目的