Git超实用总结，不再怕记忆力很差了

欢迎你们前往腾讯云+社区，获取更多腾讯海量技术实践干货哦~

本文由腾讯工蜂发表于云+社区专栏

Git 是什么？

Git 是一个分布式的代码管理容器，本地和远端都保有一份相同的代码。 Git 仓库主要是由是三部分组成：本地代码，缓存区，提交历史，这几乎是全部操做的本质，可是为了文章更加简单易懂，就不围绕这块展开了，有兴趣的能够去了解下。 开门见山，咱们直接来讲说 Git 有哪些常见的操做。

Git 有哪些常规操做？

咱们简单说说Git有哪些常规操做，可以让咱们应付简单的开发需求。

克隆代码

✦ 克隆远端代码

git clone + 远程库地址
复制代码

✦ 查看本地的代码状态

// 能够明确的呈现出本地仓库的状态
// 哪些文件发生改动，哪些文件已经提交到本机
// 以及一些操做指示。
git status
复制代码

✦ 同步远端分支变化

// 拉取指定分支的变化
git fetch origin master 
// 拉取全部分支的变化
git fetch 
// 拉取全部分支的变化，而且将远端不存在的分支同步移除【推荐】
git fetch -p
复制代码

✦ 同步远端代码变化。

// 都是先 git fetch，而后执行合并操做
// 不一样的是，git pull 执行的是 git merge，git pull -r 执行的是git rebase
git pull origin master 
git pull -r origin master
复制代码

关于 git merge 和 git rebase 各自的优劣，后文会详细介绍。

这部分主要介绍了关于代码克隆，同步远端代码变化的相关操做。接下来，咱们看看关于本地代码的一些操做。

操做 commit

首先咱们要明确一个概念：就是每一个 commit 都是一份完整的代码状态，用一个 commitID 来惟一标志。

从某个角度上来讲，Git维护的就是一个commitID树，分别保存着不一样状态下的代码。 因此你对代码的任何修改，最终都会反映到 commit 上面去。

✦ 新增 commit

// 添加文件到缓存区，而后提交到本地仓库
git add files
git commit -m '提交备注'
复制代码

✦ 撤销 commit

// 会将提交记录回滚，代码不回滚
git reset b14bb52

// 会将提交记录和代码所有回滚
git reset --hard b14bb52

// 将部分代码文件回滚
git checkout -- files
复制代码

✦ 合并 commit 合并 commit，本质上合并两份不一样状态下的代码。

// Git 提供了两种合并 commit 的方式
git merge master
git rebase master
复制代码

那么 git rebase 和 git merge 到底有什么区别呢？ merge是两个分支处理冲突后，新增一个 commit 追加到master上。 rebase是将someFeature分支上的commit记录追加到主分支上，值得注意的是，这个时候他的commit其实已经发生变化。

相对来讲，git merge 处理冲突更直接，而git rebase 可以保证清晰的 commit 记录。

合并 commit 的时候，一般会发生冲突。 能够全局搜索特殊字符好比<<<，找到须要处理的代码位置，而后认真分析应该保留哪一部分代码。

在团队协做的时候，分支是必不可少的。那么应该如何对分支进行操做呢？

操做分支

所谓的分支其实就是一个指向 commitID 的指针，你能够去.git/refs/heads里去看看。

一般状况下，咱们建议分支至少可以明确的标记功能名称，若是能标记用户就更好了，好比qixiu/feature。

✦ 查看分支

能够同时看到本地分支和远端分支，配合上前文介绍的git fetch -p能够第一时间查看到最新的分支信息。

✦ 新增本地分支 其实就是建立一个指针指向某一个 commitID。

// git branch qixiu/feature + git checkout qixiu/feature
// 从当前分支新增一个新的分支qixiu/feature
// 通常状况下，咱们应该从master或者其余稳定分支来新增分支
git checkout -b qixiu/feature // 新建分支
git checkout qixiu/feature // 切换分支
复制代码

✦ 删除本地分支 其实就是移除一个指向 commitID 的指针。

// 删除本地分支，若是本地还有未合并的代码，则不能删除
git branch -d qixiu/feature
// 强制删除本地分支
git branch -D qixiu/feature
复制代码

✦ 新增远端分支 一般状况下，咱们是新建本地分支，而后更新到远端的方式来新增一个远端分支

git push origin qixiu/feature
复制代码

✦ 删除远端分支 一样，咱们也是经过更新到远端的方式来删除一个远端分支

// 等同于git push origin -d qixiu/feaure
git push origin :qixiu/feature
复制代码

简单汇总一下

上面说的可能有些分散，这儿简单总结一下有哪些常用的操做：

git status // 查看本地代码状态
git add files // 添加代码到缓存区
git commit -m '提交内容的备注' // 提交代码到本地仓库
git checkout -b branchName // 不加-b就是普通切换分支
git fetch -p // 同步远端分支状态
git pull -r origin branchName // fetch远端代码到本地，而且以rebase的方式合并代码
git push origin branchName // 更新本地代码到远端
复制代码

以上几条命令已经可以应付平常的操做，稍微复杂一些的场景后文会介绍

基于基本操做，在实际项目中，咱们应该怎么利用 Git 实现协做呢？

Git 有哪些比较好的实践？

Git 有一些成熟的开发流程，比较主流的有两种：基于功能分支的开发流程 和 GitFlow开发流程。 相对来时，我更推荐前者，若是是复杂的大型项目，推荐GitFlow开发流程。 接下来，简单介绍下这两种协做模式。

基于功能分支的协做模式

基于功能分支的开发流程其实就是一句话：用分支来承载功能开发，开发结束以后就合并到 master 分支。 他的优势是可以保证master分支的整洁，同时还能让分支代码逻辑集中，也便于 CodeReview。

分支命名规范

推荐使用以下格式：ownerName/featureName。 这样既便于知道分支覆盖的功能，也便于找到分支的负责人。之后清理分支的时候也很方便。

开发流程

✦ 从 master 切出一个新分支

git checkout -b qixiu/newFeature
复制代码

✦ 开发一些新功能，而后提交 建议较多频次的提交代码到本地仓库，以便可以更灵活的保存或撤销修改。 此外为了保证提交日志的清晰，建议备注清楚的注释。

git status
git add files // 挑选须要提交的文件，或者所有提交
git commit -m '提交备注'
git push origin qixiu/newFeature
复制代码

✦ 若是功能开发完成，能够发起一个CodeReview流程 ✦ 若是代码测试经过，合并到 master，而后准备上线

// 冗余版 合并到 master
git checkout master 
git pull -r origin master
git checkout qixiu/newFeature
git rebase master // 处理冲突
git checkout master
git merge qixiu/newFeature
git push origin master

// 精简版 合并到 master
git checkout qixiu/newFeature
git pull -r origin master // 将master的代码更新下来，而且rebase处理冲突
git push origin master // 将本地代码更新到远端
复制代码

有几点须要注意： 不要在master合并代码，保证master的可用性很重要。 确保在正确的分支执行正确的操做。 不管是处理冲突仍是更新远端代码，请保有敬畏之心。

到此，一个正常的基于功能分支的开发流程就完成了。接下来看看另一个开发流程。

GitFlow 开发流程

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 的合并流程和注意事项吧。看下图

有三个点须要注意： ✦ rebase 先找出共同的祖先节点 ✦ 从祖先节点把 pay 分支的提交记录摘下来，而后 rebase 到 master 分支 ✦ rebase 以后的 commitID 其实已经发生了变化 尤为是第三点，常常会让人误操做，因此务必注意。

试想一下，开发过程当中，若是咱们频繁的 rebase master 分支，会有什么后果呢？

当你不断 rebase master 的时候，其实你本地的 d 都变成了 d` ，再要和远端 pay 分支保持一致，你的本地分支 commit 记录已经不堪入目了。

另外要注意，毫不要在公共的分支上使用 rebase！！！

因此，为了安全，团队能够考虑采用 merge。

pull request，方便CodeReview

Git 不只提供了代码托管以及代码开发的帮助，还提供了代码审核相似的功能。 当咱们在功能分支开发完成以后，能够发起一个 pull request 请求，选择须要对比的两个分支

它会建立一个 pull request，制定相关人员来对代码进行 review。 一般状况下，团队应该鼓励交叉 review，涉及到公共代码的时候，必定要让相关人 review。

git hook，Git 的生命周期

这个大多数人应该都，据说过，git操做有它自身的生命周期，在不一样的生命周期，咱们能够作一些自动化的事情。

举两个简单的例子： ✦ pre-commit的时候咱们能够作 eslint ✦ post-commit的时候，咱们能够作利用 jenkins 相似的工具作持续集成

固然还有更多的声明周期，具体能够参考 Git 钩子

git submodule && git subtree，管理第三方模块

这两个命令一般用来管理公用的第三方模块。好比一些通用的底层逻辑、中间件、还有一些可能会频繁变化的通用业务组件。 固然，二者仍是有区别的。 git submodule 主要用来管理一些单向更新的公共模块或底层逻辑。 git subtree 对于部分须要双向更新的可复用逻辑来讲，特别适合管理。好比一些须要复用的业务组件代码。在我以前的实践中，我也曾用subtree来管理构建系统逻辑。

git alias，简化 Git 命令

咱们能够经过配置 git alias 来简化须要输入的 Git 命令。 好比前文的 git subtree 须要输入很长的 Git 命令，咱们能够配置 .git/config 文件来解决。

// git stpull appfe demo/xxx
// git stpush appfe demo/xxx
[alias]
    stpull = !git subtree pull --prefix=$1 appfe $2 \
        && :
    stpush = !git subtree pull --prefix=$1 appfe $2 \
        && git subtree split --rejoin --prefix=$1 $2 \
        && git subtree push --prefix=$1 appfe $2 \
        && :
复制代码

总结说点啥？

该文首先介绍了 Git 常规操做 ✦ 包括克隆代码、操做 commit、操做分支等。其实 Git 常规操做的命令并很少，请看第一部分的简单总结。

其次介绍了 Git 开发流程 ✦ 该部分主要介绍了两种主流的开发模式：比较轻量的 基于功能分支的开发流程 和适合复杂项目的 GitFlow 开发流程 ，两种模式各有使用的场景，对于常规使用，前者就已经足够了。

最后介绍了一些 Git 实用技巧 ✦ 主要包括：reflog 操做，压缩日志，rebase 的注意事项，利用 pull request 作 codeReview，利用 git hook 作一些自动化工做等。

相关阅读

Spark 灰度发布在十万级节点上的成功实践

EMR常见FAQ

Ceph部署mon出现0.0.0.0地址问题定位

【每日课程推荐】机器学习实战！快速入门在线广告业务及CTR相应知识

此文已由做者受权腾讯云+社区发布，更多原文请点击

搜索关注公众号「云加社区」，第一时间获取技术干货，关注后回复1024 送你一份技术课程大礼包！

海量技术实践经验，尽在云加社区！