Git 的基本操作、开发流程、实用技巧总结(陈彦贝)

GitFlow 比前文讲的基于功能分支的开发流程要复杂得多，它更适合大型的复杂项目。 它围绕项目发布流程定义了一个严格的分支模型，所有的开发流程都是围绕这个严格的分支模型进行。 而这个模型约定了每个分支的角色，以及他们如何沟通。

我们先来看看 GitFlow 开发流程中几个约定的分支，以及他们各自承担的角色是怎么样的？

✦ Master分支：用于存放线上版本代码，可以方便的给代码打版本号。 ✦ Develop分支：用于整合 Feature 分支。 ✦ Feature分支：某个功能的分支，从 Develop 分支切出，并且功能完成时又合并回 Develop 分支，不直接和 Master 分支交互。 ✦ Release分支：通常对应一个迭代。将一个版本的功能全部合并到 Develop 分支之后，从 Develop 切出一个 Release 分支。这个分支不在追加新需求，可以完成 bug 修复、完善文档等工作。务必记住，代码发布后，需要将其合并到 Master 分支，同时也要合并到 Develop 分支。 ✦ Hotfix分支：紧急修复的分支，是唯一可以从 Master 切出的分支，一旦修复了可以合并到 Master 分支和 Develop 分支。

从每个分支的功能和约定可以看出，它流程多约束多，对于小规模应用并不适合。 当然 GitFlow 有一些辅助工具 gitflow 可以自动化的完成这些任务，对于大型项目也很有帮助。

前面讲了 Git 有哪些基本操作，然后介绍了两个主流的工作流程。 接下来我们看看 Git 有哪些特别的技巧值得一提。

Git 有哪些小技巧？

Git 操作除了基本的代码管理功能，还有一些小技巧能够让你眼前一亮。

git reflog，查看操作记录

这个我一定要放在第一个介绍，因为它曾经数次解救了我的代码

仔细看上图，reflog 记录了你所有的 git 命令操作，对于复原某些莫名其妙的场景或者回滚误操作有极大的帮助。 试想一个场景：你使用 git reset --hard commitID 把本地开发代码回滚到了一个之前的版本，而且还没有推到远端，怎么才能找回丢失的代码呢？ 你如果使用 git log 查看提交日志，并不能找回丢弃的那些 commitID。 而 git reflog 却详细的记录了你每个操作的 commitID，可以轻易的让你复原当时的操作并且找回丢失的代码。 当然，如果你丢失的代码都没有提交记录，那么恭喜你，你的代码真的丢了。

压缩提交记录

这也是一个很实用的功能，前文提过，我们在开发中的时候尽量保持一个较高频率的代码提交，这样可以避免不小心代码丢失。但是真正合并代码的时候，我们并不希望有太多冗余的提交记录，而且 rebase 合并代码的时候，会把每个 commit 都处理一下，有时候会造成冗余的工作。 所以，压缩日志之后不经能让 commit 记录非常整洁，同时也便于使用 rebase 合并代码。

那么，如何压缩commit记录呢？ ✦ 使用 git log 找到起始 commitID ✦ git reset commitID ，切记不要用 --hard 参数 ✦ 重新 git add && git commit ✦ git push -f origin branchName ，因为会有冲突，所以需要强制覆盖远端分支，请务必谨慎。 ✦ 合并到 master 中，然后更新远端 master。

此外还有两种压缩日志的办法： git commit --amend ：追加 commit 到上一个 commit 上。 git rebase -i ：通过交互式的 rebase，提供对分支 commit 的控制，从而可以清理混乱的历史。

从实际应用来说，三种日志压缩都很优秀， git reset 更简单， git rebase -i 更细腻。

git rebase，合并代码

前文简单介绍了 git rebase 和 git merge 的区别，坦率讲，他们各有优劣。 git rebase 能让你的 commit 记录非常整洁，无论是线上回滚还是 CodeReview 都更轻松；但却是一个有隐患的操作，使用时务必谨慎。 git merge 操作更安全，同时也更简单；但却会增加一些冗余的 commit 记录。

这儿简单说说 rebase 的合并流程和注意事项吧。看下图

（编辑：焦作站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!