关于intellij-idea:IntelliJ-Idea-git操作指南

写在后面

长期以来，我始终用的是 git 命令行治理代码，当只有一个人时，这齐全没问题，但参加团队合作，命令行就显得令不从心，这并不是说命令后做不到，只是命令须要记住太多的命令，学习老本太高，而且在解决抵触下面，如果只靠命令后，那种感觉你体验过一次就再也不想体验。在花了一两天工夫钻研 idea 的 git 工具后，我就决定彻底放弃命令行拥抱 gui，因而这边将这两天的研究成果记录下来，供大家学习参考。

创立仓库

创立近程仓库

第一步须要在 github 或者 gitee 代码治理平台创立好仓库，这里以 github 为例

• 输出仓库名称
• 抉择仓库类型，public 示意所有人都可见，private 示意只有受权过才有权限

仓库创立好后，默认是一个空仓库，这时候界面会提醒如何往仓库推送代码

留神到界面上有个仓库地址，地址有 ssh 和 https，这两个有什么区别呢

• https：通过 http 协定进行代码的治理，须要应用用户名明码
• ssh：通过 ssh 协定进行代码治理，应用的是密钥（你能够了解为一个凭证）

推送仓库的操作前面会具体阐明，这里就不介绍。

关联本地仓库

如果是本地已有我的项目须要关联刚创立的近程仓库，具体步骤如下

• 初始化我的项目

在菜单栏抉择VCS -> Import into Version Control -> Create Git Repository，抉择后会弹出文件夹抉择窗口抉择以后文件夹即可

抉择文件夹后 idea 会在当前目录下创立一个 .git 的文件夹，示意该我的项目曾经是一个应用 git 版本控制的我的项目，如果你的终端是比拟敌对的终端（如 Oh My ZSH)，这时候会显示以后分支，默认是 master 分支

➜  git-learning git:(master) ✗

• 关联近程仓库

近程仓库称在 git 中称为 Remote，一个我的项目能够关联多个 reomte，也就是你的我的项目能够同时推送到多个近程仓库，这个是很有用的，比方咱们的代码既要推送到客户仓库进行集成，又要推送到公司的仓库进行代码审查，这时候就能够应用多 remote 进行推送，点击VCS -> Git -> Remotes 增加近程仓库，如果是第一仓库，名称默认 origin，倡议不要批改该名称

这样咱们就实现了本地仓库和近程仓库的关联，后续就能够进行代码的提交，分支的创立等操作。

克隆仓库

如果是他人创立好并提交过代码的仓库，你须要同步到本地，那么就须要对仓库进行克隆（clone）操作，抉择File -> New -> Project from Version Control，输出近程仓库代码地址即可

gitignore

在我的项目中有些工程文件或者程序运行时文件咱们不心愿提交到仓库里，那么咱们就须要筹备一个名为 .gitignore 的文件，将不心愿提交的文件都写到该文件里，git 就不会对这些文件进行提交和治理。

一个.gitignore 样例

/out/
/classes/
.mvn
/node_modules/
.idea
*.iws
*.iml
*.ipr
.DS_Store
/target/

能够在文件或者文件夹上右键将其增加到 gitignore 上

提交代码

代码批改后需提交到本地仓库，这个过程称为Commit，代码提交到本地仓库后就能够将 commit 提交到近程仓库，这个过程称为push，从远处仓库更新代码的过程称为pull，这三个 git 操作是最罕用的三个操作，在 idea 的右上角有这三个操作对应的按钮

• ① 更新代码，pull 操作
• ② 提交到本地仓库，commit 操作
• ③ 提交到近程仓库，push 操作

点击 commit 图标就能够提交代码，提交代码界面如下

• ① 本次提交波及到批改的文件
• ② 提交信息，提交信息是必填，每一次提交都需写明本次批改了哪些内容，原则上每一次不同的目标的批改都应对应一次 commit，对于如何写好 commit 能够参考以下两篇文章
• https://github.com/joelparkerhenderson/git-commit-message
• https://github.com/RomuloOliveira/commit-messages-guide

留神到①文件后面都有一个复选框，如果是新增加的文件，没有非凡配置的话是不会主动勾选的，新增加的文件须要手动勾选能力提交，能够间接对顶层文件夹全选即可，commit 后须要进行 push 能力同步到近程仓库，点击 push 按钮

push 胜利后就能够登录近程仓库查看最新的代码

留神到零碎提醒咱们增加一个 README 文件，README 是一个名称为 README.md 的文件，位于我的项目根目录下，一个好的 README 文件有助于其他人疾速理解我的项目状况，对于如何写好 README 文件，能够参考以下文档

• https://github.com/RichardLitt/standard-readme

批改代码后，在提交的界面还会对本地提交和上一次提交进行比照，不便咱们查看批改的内容

回滚代码

git 回滚代码有两种形式

• reset
• revert

这两种有什么区别呢，假如咱们提交了三次 commit

commit1 -> commit2 -> commit3

如果我想会滚到 commit2，如果用 reset 的话，那么 commit2 之后的所有批改都会被抛弃，也就是把 commit2 之后的 commit 全副砍掉了，revert 有点像 undo，会把 commit2 做的操作反做一遍，也就是 undo，并且生成一个新的 commit，变成

commit1 -> commit2 -> commit3 ->4

具体利用在什么场景呢，举个例子，比方咱们在调试的时候可能要加一些调试语句，比方 system.out，当调试结束，咱们心愿可能移除这些调试语句就能够在调试前提交一次 commit，调试结束后 reset 到该次 commit 就行，当然你也能够通过分支来实现，调试结束把分支删掉即可。

咱们的零碎在一直的迭代，忽然某一天，产品经理说之前曾经上线的一个性能不要了，那么就能够找到该性能对应的 commit 进行 revert，这样既移除对应的性能又能保留后续的新性能。

reset

在 idea 境地工具栏，点击 Git 工具栏，切换到 Log 标签页，能够看到本地 commit 日志和近程 commit 日志，在指定 commit 上右键抉择 Reset Current Branch to Hear 就能够以 reset 的形式回滚到该 commit 上

有四种回滚的模式

<img src=”http://zhengjianfeng.cn/images/R2byAplCbygdWlcNS98tcHuYiflKF4FC.jpg” style=”zoom:60%;” />

抉择 Hard 模式，将会革除本地版本，强制回滚到指定 commit 状态，然而通过 reset 是无奈进行 push 操作，因为本地的版本比近程版本要低，此时能够强制 push 到近程分支

idea 默认是禁止在 master 分支上进行强制 push，如果是 master 分支须要强制 push 能够在终端应用命令行 git push --force

force push 是一种十分不好的习惯，除非你分明的意识到 force push 带来的结果，不然千万不要执行 force push

revert

revert 能够将指定的 commit 所做的批改全副撤销掉，而不影响其余 commit 的批改，假如咱们有三个文件，别离为 file1.txt，file2.txt，file3.txt，当初提交三个 commit，三个 commit 别离为

• Commit1：向 file1.txt 中增加内容
• Commit2：向 file2.txt 中增加内容
• Commit3：向 file3.txt 中增加内容

当初咱们在 Commit2：文件 2 批改 这个 commit 下面右键抉择Revert Commit，这时候会弹出提交窗口，idea 会主动提交一次新的 commit，commit 后咱们发现文件 2 的内容没有了，也就是撤销了 commit2 批改的内容，commit 后执行 push 操作就能推送到近程仓库了，因为是生成了新的 commit，所以无需 force push 就能提交到近程仓库

revert 操作会常常碰到代码抵触的状况，这时候就须要手动去解决抵触，解决办法上面也会具体阐明

分支治理

分支是 git 中十分重要的概念，假如没有 git 的状况下，咱们零碎上线了，在线上稳固运行，这时候你须要开发后续的性能但又想保留目前线上版本的代码，因为可能线上有紧急 bug 须要修复，你须要应用过后的版本进行批改，所以你可能会 copy 一份代码做备份，等新性能开发完，你还须要将这段时间在备份的代码上批改的代码整合过去，如果这个过程是人工进行的，非常容易出错，所以 git 提供了分支解决这个问题，线上运行的代码能够在主分支上，比方 master 分支，开发新性能能够从 master 分支切一个分支进去，比方 dev 分支，修复 bug 也能够从 master 分支上切一个分支进去，比方 fix 分支，当 bug 修复结束，将 fix 分支整合 (merge) 到 master 分支上，当新性能开发结束后，将 dev 分支整合到 master 分支，就实现了上述所有的操作。

新建分支

在 idea 右下角显示以后分支

点开就能够在以后分支下新建一个分支

你也能够从某个 commit 切出一个分支，具体做法在 commit 日志上右键 New Branch 即可

切换分支

如果想要切换到其余分支，点击要切换的分支，抉择Checkout

切换分支前须要把以后分支的批改提交或者暂存，暂存后续也会提到

分支合并

比方我要把 fix 分支合并到 dev 分支上，那么将以后分支切换到 dev 上，抉择 fix 分支Merge into Current

合并过程可能会产生抵触，须要解决完抵触能力实现合并，解决抵触下文也会提到

合并完分支后，倡议把 fix 分支进行删除，防止误将分支提交到近程仓库，导致分支凌乱。

rebase

留神到下面菜单中在 Merge 下面还有一个 Rebase Current onto Selected 的抉择，合并有两种形式，一种是 merge，一种是 rebase，这两种有什么区别呢，如下午，1 时 rebase 形式合并，2 和 3 是 merge 形式合并

• merge 会保留分支提交信息
• merge 会创立一次 Merge branch 的 commit 信息
• 相比 merge，rebase 会将分支上的 commit 整合到以后分支上，让整个代码周期更为清晰
• 相比 merge，rebase 并不会产生多余的 commit 信息

具体用 rebase 和 merge，各有各的益处，取决于我的项目的标准要求。

抵触解决

不论是 rebase 还是 merge，在进行合并时难免会产生抵触，所谓的抵触是指两个分支上的代码对同一个中央进行批改，零碎无奈判断该保留哪一份代码，须要人工进行干涉解决抵触的过程。如果有抵触产生，在进行合并时会列出所有抵触的代码

这时候有三个选项能够抉择

• Accept Yours：保留以后分支代码，抛弃被合并的分支代码
• Accept Theirs：保留被合并分支代码，失落以后分支代码
• Merge：手工进行合并

抉择 Merge 后进入手工合并代码界面

• ① 以后分支代码
• ② 合并后的代码
• ③ 被合并的分支代码

idea 会把两边不同的进行高亮显示，你能够依据理论状况进行合并

合并后会弹出一个确认框，如果所有的抵触都解决结束，能够点击Apply Change and Mark Resolved，示意抵触已解决

标签治理

创立标签

个别咱们在公布一个新版本时会对我的项目打一个标签（tag），以示意其重要性，在 gihub 上咱们也常常看到我的项目公布新版本时都会打上标签

在 commit 的 log 上右键 commit 就认为为该 commit 创立一个标签，标签名称个别为版本号，比方 v1.0 v1.1 等

在 push 代码时能够抉择将标签一起提交至近程仓库

这样咱们就能在近程仓库中看到标签，并且零碎会主动将标签对应的 commit 过后的代码进行打包归档

依据标签拉取代码

比方须要对 v1.0 的代码进行修复，咱们须要拉取 v1.0 的代码，并且修复结束后须要合并到以后分支

• 依据 tag 拉取代码

输出标签名称就能够拉取到代码，但此时的分支名称是分支对应的 commit 编号，说白了就是一个 commit，咱们须要在该分支上再创立一个分支能力对代码进行批改，创立的办法和下面一样，就是点击分支名称，New Branch即可，批改后提交，依照失常分支合并即可。

补丁

patch

能够为一个或多个 commit 创立一个补丁（Patch），idea 会创立一个.patch 的文件，外面记录了文件的变动

在分支上能够将补丁进行导入，VCS -> Apply Patch

打补丁也是一种合并的形式，也需解决代码抵触问题

cherry-pick

和打补丁相似，cherry-pick 能够间接将其余分支的一个或者多个 commit 利用到以后分支，无需导出 patch 文件