git 进一步学习

参考这篇文章:git best practice

常用 troubleshooting 技巧几则

这个算是新手常见问题的解决方案了,

  • 如果我在 trunk 上干活,然后没有 commit,突然 merge 某个 branch 出错了,想退出这个 merge,那只需要 git merge –abort;类似如果你在 branch 上干活,rebase 失败可以用 git rebase –abort
  • 去掉已经做过的修改,推荐使用 git stash save,之后可以看 git stash list 有没有存下来的,如果确实没有需要可以使用 git stash drop;另一种暴力做法是 git reset –hard,直接抛弃修改。这两种做法都不能处理 untracked 文件和 ignored 文件,为了做相关的清理我们可以用 git clean -nd 或者 -ndX,两者一起可以用 -ndx。
  • 如果某个 branch 上所有的 commit 都希望被抛弃以便 rebase,可以 git reset –hard @{u},类似如果希望和某个 branch 完全一样,可以使用对应 branch 的 ref,上一次 commit 可以使用 HEAD^。
  • 修正上次 commit 可以用 git commit –amend

选择 work mode

下面是一些参考:

  • progit 上的两种模式:在 trunk 之外有一个长期存在的 dev,然后只有在 dev 上成熟的 code 才会被 push 到 trunk 上,dev 从别的地方(如 dev 的 branch) merge 新的功能进来;一种是只有一个 trunk,新的功能都以最新的 trunk 上 branch 出来的 topic branch 来开发,完成后 merge 回 trunk 并且删掉这个 topic branch(类似的一个 workflow 见这里);
  • gitflow 的版本其实是以上两种方式的混合,除了前者两个长期存在的 trunk 和 dev branch 以外另外加了一些辅助的 branch,trunk 上仍然只是做 tag,但并不算 release,有专门的 release branch。开发时比如从 trunk 某个 tag 开始,如果发现了重大的问题,可以到 hotfix branch 上修正,结果会 merge 回 trunk 和 dev。dev 同时有几个 feature branch 在同时进行,一旦 feature 成熟就可以并入 dev。当 dev 的成熟达到一定程度准备 release 时,code 被 merge 进入 release branch 并且暂停 dev 的进行,在 release 上完成整合,结果 merge 回 trunk 和 dev;
  • gitworkflow 的版本包括 maint(指 maintenance,大的 release 出现的 trunk)、master(为每次 release 做准备的 branch)、next(开发的 branch) 和 pu(proposed updates,作为 integration branch),这四个后面的是前面的 branch,一般只有上游对下游进行 merge,也使用 feature/topic branch,整合的时候不是直接放进某个长时间存在的 branch,而是新建临时的 integration branch,确认整合后再进入长期的 branch。这里还间或使用 cherry pick 技巧,当然这对 code 安排有比较合理的分割,使得每个独立的工作对应的一些 commit 可以独立的被并入一个 branch(merge 是 branch 级别的行为,cherry pick 能做 commit 级别的)。
  • agile team 的分布式模型:队员接收到 feature 任务,从 master 获得最新的代码,开始工作在本地的 master 上 branch 出来的 feature branch,工作时记得常 rebase from master(一般需要先 fetch 然后 rebase),需要解除 rebase 中产生的问题,最后完成到一定程度后 push 回去(先与本地的 merge,然后 push)。修 bug 常用类似的流程。通常 branch 的名字可能对应 bugzilla 之类的编号或加以前缀表示区别。
  • 有的做法是对 master -> beta -> dev 的补充,这种模式原先大概就是 dev 开发,beta 测试,到 master 就发布了,这里没考虑到某些情况需要进行修 bug,因此作者提供了中间插上一个 gamma,而 gamma 有个 stable 分支专门用来修这种需要快速解决的。这就导致 dev 也必须从 stable 里面获得最快的更新
  • 分布式几个基本的做法(来自 progit):centralized model 是最简单的,就是一个 bare 作为中心,大家都从那里 check out,然后编辑好了 push 回去,这个有很大的冲突风险,更麻烦的是每个人的帐号可能有点问题(中心 repository 谁可写?);一个更合理的方案是有一个维护者,他自己有个 repository 用来工作整合,然后他通过的内容 push 到公开的 blessed repository(一般是个 bare repo),他自己跟踪严肃的 dev 的 public repo;dev 总是从 blessed repo 获得最新的信息,在自己私人的 repo 里面进行开发,完成后 push 到自己的 public repo 里面并通知维护者;更大的项目一个人维护忙不过来于是就出现了中间层,这所谓的 dictator-lieutenant 模式。

有兴趣继续研究可以看看这个贴。有人嘲笑 git 其实不是个 version control system,而是让人实践设计 workflow 的系统,真不为过… 就我个人常用的,可能是一直也没经历过大的项目应用 git 来管理吧还是比较基本的 long-term branch,一次实践过 blessed respository 感觉挺好;之前也有一次跟 JC、relic256 同学一起玩搞了个 centralized model 发现很多麻烦的地方,还是不适用,不过 blessed repo 的还是要有人愿意来做维护这事…

最后一个感想是 git 为什么显得很 tricky,其实很多功能常用的你就会记得怎么用,但是像发生某些奇怪的错误一般很罕见,如果对 git 的机制不理解(其实我还有点昏)就会不知道怎么办,这个时候去 google 个结果,看见别人这么做了试了一次过了可能也不理解为啥,之后很难再碰到类似的问题,于是就忘记了,下次碰到还是解决不了;另外某些东西看起来很相似但是又有很多细节稍有不同可能导致解法不同,很难有一些 general rule 可以 follow,使用者就会很难 generalize…

——————-
And they blessed Rebekah, and said to her, You are our sister, be you the mother of thousands of millions, and let your seed possess the gate of those which hate them.

Advertisements
git 进一步学习

一个有关“git 进一步学习”的想法

      1. zt 说:

        我 reply 的时候应该邮件提示,问题是我没有 reply 你的贴而是 reply 在正文下面了,所以…

        anyway,many thanks 🙂

发表评论

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / 更改 )

Twitter picture

You are commenting using your Twitter account. Log Out / 更改 )

Facebook photo

You are commenting using your Facebook account. Log Out / 更改 )

Google+ photo

You are commenting using your Google+ account. Log Out / 更改 )

Connecting to %s