git小技巧

版本控制最佳做法

• 提交代码之前一定要先测试——在你还没有确认工作完成(彻底的测试)之前，忍住提交代码的冲动
• 提交应该是相关更改的封装——较小的提交可使其他开发人员更容易理解更改，并在出现问题时将其回滚。
• 写"好"的提交注释——用简短的总结语句，后续正文与开头用空白行分开。——做了什么，为什么这样做
• 经常提交会使你的提交变小，并且帮助你仅提交相关的更改。——可以更轻松地定期同步整合代码更改，并避免合并冲突
• 不要提交未完成的代码——将功能的实现分成逻辑块，并记住要尽可能早的频繁的提交
• 如果你只是因为需要干净的工作区（切换分支，同步更改等）而打算提交未完成的代码，请考虑改用git stash

分支合并错误

• 开发代码 错误的提交了到测试分支develop,使用stash迁移代码后，强制develop与远端同步

git reset --hard origin/master

• 回滚到上个版本

git reset --hard HEAD 
git commit '回滚到上个版本XXX'
git push origin HEAD --force

• 回滚到指定历史版本

git reset --hard <commit_id>  
git commit '回滚到上个版本XXX'
git push origin HEAD --force

• 把新建的本地分支推送到远端同名分支(建议在远端创建,本地pull)

  git checkout -b <新分支名>
  git push --set-upstream origin <本地分支名>
  

重写最近commit message

git commit --amend '新的注释'

移花接木

# 复制一个特定的提交到当前分支
git cherry-pick <commit_id>|分支名
git checkout targetBranch
git cherry-pick <commit_id>|分支名

# 这是一个左开右闭的操作，就是commit1不会被合并
git cherry-pick commit1..commit100

# 未提交代码转移分支 使用stash
git stash 
git checkout branchName
git stash pop

# 提交到错误分支的代码转移分支 使用stash
git reset --soft <commit_id>
git stash 
git checkout branchName
git stash pop

# 删除误提交的代码
git reset --hard <commit_id>

phpstormIDE 选中要复制的若干分支，点击【cherry-pick】，到需要的分支上，点【推送】

merge vs rebase

• git rebase 和git merge 做的事其实是一样的,都是合并分支
• merge 好在它是一个安全的操作; 缺点是

• 将代码 Merge Request 到团队共用分支 master 前，需把 master 代码 rebase 到自己分支

  git rebase master                      // 第一轮 rebase 
  git status                             // 看状态,如有冲突就处理
  git pull                               // 处理完冲突要执行这步
  git rebase --continue                  // 下一轮 rebase
  git rebase --skip                      // 执行 git status 发现没有冲突，则执行这一步
  git push -f origin <本地自己的开发分支> // 在 git rebase --skip 后，执行这一步
  

• 通过 git bisect 自动二分法快速定位问题

  某个系统，在开发过程中一直都没测试出问题，突然有一天，发现 Bug。

这种蛮多情况是衰退，如果这个 Bug 的复现几率很大的话，就可以直接用二分法快速定位了。

git bisect 就可以辅助进行自动二分法。

git bisect start
git bisect bad efa5cf
git bisect good b6fcf0
git bisect run grep -q UCONFIG Makefile

• 用 git fetch 取代 git clone，实现断点续传

  git fetch <仓库地址>
  git checkout -b master FETCH_HEAD
  

## 查看修改日志

配置

• 查看全部Git配置 git config –list
• 显示颜色提示 git config –global color.ui true

使用token 替换 ssh-key

• git remote set-url origin https://@github.com//.git

.gitignore修改无效

• git rm -r –cache .

工作流

版本一：小规模开发

• 基于 master 发布
• 基于 master 创建开发分支 feature/userName/Date/featureName
• 基于 master 创建修复分支 bugix/userName/Date/featureName
• 基于 develop 测试
• 自测通过的代码合并到 develop 分支【单向合并】
• git fetch origin master
• 产品验收通过的分支提交 mergeRequest 到 master

版本二：中规模开发

【迭代开发】

• 基于 released 分支发布
• 基于 develop 创建开发主分支 dev-Version
• 基于开发主分支 dev-Version 创建独立开发分支 dev-Version-ModuleName/userName/Date
• 自测通过的代码合并到 dev-Version 分支【单向合并】
• 基于 develop 分支【+迭代版本号】创建 test-Version
• 联测通过的代码合并到 test-Version 分支【单向合并】
• 产品验收通过的 dev 分支提交 mergeRequest 到 develop
• 运维基于 develop + 封版时间 创建 released-Version 分支
• 发版之后，将 released-Version 分支 合并到 master 【?合并时机】

【bug修复】

• 基于 develop 分支创建修复分支 released-Version-bugfix-Version
• 基于 released-Version-bugfix-Version 分支创建独立修复分支 released-Version-bugfix-Version/userName/bugName
• 自测通过的代码合并到 test-Version 分支【单向合并】
• 产品验收通过的分支提交 mergeRequest 到 released-Version-bugfix-Version
• 运维 基于 released-Version-bugfix-Version + 例行bug修复封版时间 发版
• 发版之后，将 released-Version-bugfix-Version 分支 合并到 develop、master

版本三：双周灰度发布

• 全量发布的分支不再创建 released-Version-bugfix-Version 分支