Git 姿势

[gogu]

我们使用 Github Flow 来异步协作（暂时无视自动测试推送上线的持续集成部分）

1. 首先 fork 主仓库项目

2. 之后的 push 到自己的仓库，每个功能一个分支

   • git remote add [name] [address] name 是自定义的远程仓库名，address 是 fork 的仓库地址

     $ git remote add gogu git@github.com:gogu/cat-stride.github.io.git

   • git remote -v 查看自己已设置的远程项目地址

     $ git remote -v
     gogu	git@github.com:gogu/cat-stride.github.io (fetch)
     gogu	git@github.com:gogu/cat-stride.github.io (push)
     origin	git@github.com:cat-stride/cat-stride.github.io.git (fetch)
     origin	git@github.com:cat-stride/cat-stride.github.io.git (push)

   • git checkout -b [name] 创建本地分支，name 是自定义的分支名称，一般是开发中的功能

     $ git checkout -b update-note

   • 切换到已存在的分支用 git checkout [name]

   • git push [remote name] [branch name] push 到自己的远程仓库的对应分支

3. 提交 Pull Request 到主仓库

4. 邀请项目成员 review 代码，解决完所有提问并收到两个以上的赞 （approve）可以合并到主分支

关于解决冲突

1. 冲突的成因

   git 机制中，当你提交本地的 commit 到远程仓库时，会检查本地历史（history commits）和当前远程仓库历史。如果远程仓库历史相同的文件被其他成员修改过了，git 会要求你先手动处理一下本地历史，比如 git pull 一下，再重新尝试提交。

   $ git push origin master
   To github.com:cat-stride/cat-stride.github.io.git
    ! [rejected]        master -> master (fetch first)
   error: failed to push some refs to 'git@github.com:cat-stride/cat-stride.github.io.git'
   hint: Updates were rejected because the remote contains work that you do
   hint: not have locally. This is usually caused by another repository pushing
   hint: to the same ref. You may want to first integrate the remote changes
   hint: (e.g., 'git pull ...') before pushing again.
   hint: See the 'Note about fast-forwards' in 'git push --help' for details.

   git pull 背后其实是 git fetch 后自动进行 git merge 操作，merge 过程中如果遇到其他成员又和你修改了同一行，git 就会进入一个新的分支，并开始解决冲突流程。

   试着简单说来：当你和其他成员同时编辑一个文件，你们编辑的「基底」是相同的，其他成员先 push commit 到主仓库，你的「基底」就会和现在真正的「基底」不同步。这时你使用 merge 或者 rebase 操作处理历史 commit，git 会自动判断哪些行（line）的内容是不冲突的并自动合并。然而当同一行被同时修改， git 无法自动判断你在「不正确」的「基底」上更新的内容是否能保证整个系统正常工作，会把问题丢回给你，由你来手动选择正确的内容。

2. 解决冲突

   造例子比较麻烦... 先看这个 解决冲突 - 廖雪峰 git 教程

git 的相关问题在这个 issure 下解决。

[simpleowen]

棒棒哒。。。

[gogu]

关于 rebase

基于 git rebase 来处理 commit 历史，在实践经历中被伙伴们广泛接受。

其好处是直接反应到干净的历史记录上。除去各种人工的 merge 记录，我们可以实现每个 commit 都是有意义的。

坏处也很明显，rebase 意味着直接操作了「时间线」，相比 merge 否定了分支存在过的事实，相应操作也稍显麻烦，要时刻清楚自己有没有进入 rebase 流程中的解决冲突状态，以及和 merge 解决冲突的不同之处。

所以我们此次为求效率不强求使用 rebase 范式，如果你想更加深入了解 git，学习 rebase 是很好的契机；或者你也和 这位博主 一样对历史有着近乎洁癖的执着，那么强烈推荐你使用 rebase 范式工作。

• http://gitbook.liuhui998.com/4_2.html
• https://www.web-tinker.com/article/21113.html
• https://www.web-tinker.com/article/21114.html

另：github 默认的 merge PR（Pull Request） 操作是 merge 流程，会留下一个记录，不过这个记录是有意义的，可以回溯此 PR 是由谁最终 Review 并合并到主分支的。所谓无意义更多是本地处理时间线和解决冲突。