git by example

记一次回滚操作

1. 路人甲让我修改一个bug，我在develop下修改了
2. 路人甲让我push到releae/sdk0.7分支上
3. 我本地操作切换到release分支并合并develop上的修改：
   • git checkout release/sdk0.7
   • git merge develop
   • git pull
   • git push origin release/sdk0.7
4. 路人甲pull下来看了下之后，发现问题：
   • 只要我修改的那个bug
   • 不要develop上的其他新修改（develop上有多人的新提交）
5. 我本地分支试验下回滚操作：
   • git checkout -b rfake 分支一个rfake出来做试验
   • 查看我那个修改是develop上的倒2个commit，
   • git cherry-pick develop~1 把develop的倒2个commit 通过cherry pick合并到rfake这个分支
     • 擦亮眼睛：cherrypick可以取到任何一个分支的任何一个commit，配合reset你想干嘛就干嘛
   • git log查看下，正确，
6. 回滚：
   • git checkout release/sdk0.7
   • git reset --hard commithash 到第2个步骤之前的commit（commithash只要指定commit的前面几位hash数字即可）
     • 可以通过git log查看某个commit的hash值
   • git push origin release/sdk0.7 -f 强制push到仓库
   • 重复第5个步骤的事情
   • git push origin release/sdk0.7
7. 路人甲需要做：
   • git reset --hard commithash 到第2个步骤时release分支的最新commit
   • git pull 重新拉取
8. 事实上，如果一开始就正确操作就可以避免回滚：
   • 一开始就在relsease分支上修改，或者从release分支出来一个新分支来修改
   • 修改完毕，提交到release分支
   • 把release分支的修改merge到develop上，因为develop总是比release新。
9. 这个操作覆盖了git的大部分操作：
   • 如何切换到分支开发，如何建立新分支做实验
   • 如何合并其他分支上的修改到当前分支
   • 如何提取某个分支的某个commit并合并到当前分支
   • 如何重置
   • 如何强推
   • 怎样正确的在发布分支上改bug

使用GitHub实施团队项目开发

• GitHub团队项目合作流程
• Github团队开发示例

理解git的原理

• 最佳实践、本文略晦涩、慎入：Commit Often, Perfect Later, Publish Once: Git Best Practices
• 图解Github的PullRequest开发方式：Understanding the GitHub Flow
• 一种成功的git分支策略：A successful Git branching model
• 如何写好git的提交日志：How to Write a Git Commit Message
• 抱持提交历史的干净、整洁：Keeping Commit Histories Clean
• 最好的git合并工具：What's the best visual merge tool for Git?
• git的最佳操作之一是用命令行，但是合并冲突的时候，一个跨平台的Diff工具会带来极大便利：visual diff