长期以来,我始终用的是git命令行治理代码,当只有一个人时,这齐全没问题,但参加团队合作,命令行就显得令不从心,这并不是说命令后做不到,只是命令须要记住太多的命令,学习老本太高,而且在解决抵触下面,如果只靠命令后,那种感觉你体验过一次就再也不想体验。在花了一两天工夫钻研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回滚代码有两种形式
这两种有什么区别呢,假如咱们提交了三次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上
有四种回滚的模式
抉择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的代码,并且修复结束后须要合并到以后分支
输出标签名称就能够拉取到代码,但此时的分支名称是分支对应的commit编号,说白了就是一个commit,咱们须要在该分支上再创立一个分支能力对代码进行批改,创立的办法和下面一样,就是点击分支名称,New Branch
即可,批改后提交,依照失常分支合并即可。
补丁
patch
能够为一个或多个commit创立一个补丁(Patch),idea会创立一个.patch的文件,外面记录了文件的变动
在分支上能够将补丁进行导入,VCS -> Apply Patch
打补丁也是一种合并的形式,也需解决代码抵触问题
cherry-pick
和打补丁相似,cherry-pick能够间接将其余分支的一个或者多个commit利用到以后分支,无需导出patch文件