作者简介
目录
首先我们在GitHub上创建一个新的项目,然后将这个空项目拉到本地,在本地搭建起一个maven项目的骨架再推上去,全流程走一下一个项目从0开始如何托管给git,后文的操作也会基于该项目上来演示。
首先我们在GitHub上创建一个新的仓库:
在IDEA上把项目拉到本地,拉代码的时候需要进行身份验证,输入自己的用户名密码即可:
在拉下来的目录下手动建一个maven项目,按照maven项目的结构新建好项目结构,这里省略去了test文件夹和resource文件夹,各位需要的话也可以自己加上去:
pom.xml示例:
- "1.0" encoding="UTF-8"?>
- <project xmlns="http://maven.apache.org/POM/4.0.0"
- xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
- xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
- <modelVersion>4.0.0modelVersion>
-
- <groupId>org.examplegroupId>
- <artifactId>IdeaGitDemoartifactId>
- <version>1.0-SNAPSHOTversion>
-
-
-
- project>
然后将该项目变成maven项目:
然后将项目push到远端仓库上即可。
在IDEA的右上角有git推拉的选项。
绿色的新加还未commit的,蓝色表示有所改动但还未commit的。
双击想要查看的某一次commit的某一个文件,会弹出当前版本和上一个版本之间的比较面板:
比较面板里支持一些快捷操作:转跳上一处不同、转跳下一处不同,定位到该文件的源文件。
当我们想合并某一些提交,而不是合并两个分支的时候,可以用到cherry pick。
举一个使用场景的例子:
当我们有一个主分支main,然后基于main拉出来两条开发分支Dev_A和Dev_B,两个开发团队在这两条分支上各自在开发不同的功能。在开发过程中Dev_A的开发团队发现了main上的一个bug,然后在自己这条开发分支上修复了这个bug。这时候由于两条开发分支都没有完成,不可能直接将Dev_A合并到任何分支上,只能将修复bug的那一次提交合并到各个分支上,这时候就可以用cherry pick。
比如这个时候,Dev_A上有master内容的bug修复,但是后续又有新开发的内容的提交,要是直接将Dev_A分支合并到main上会将未完成测试的不稳定内容合并到main上去,从而扰乱整个main分支。如果将这个bug修复直接合并到其它开发分支上去,会扰乱其它分支正在进行的正常开发。
这时候切到main分支,,然后将修复bug那一次提交,cherry pick到main分支上:
这时候bug修复的那一次提交已经到main分支上来了,将main分支push上去即可:
在实际开发中可能会有这样的情况:
某一段代码在某一个时刻被我们重写了,然后过了没多久客户有个需求变动进来了,发现还是基于原来的代码更好做新的需求。这时候就要求我们把这一段代码回退到上个版本。
很明显是不可能用版本号来将整个代码版本回退到某个版本的,因为其它文件并不需要回退,只有当前的一段代码需要回退。这时候就需要用到revert。revert指令可以将某一个文件回退到指定版本:
revert后回退的文件肯定会和当前文件存在冲突,这时候就需要手动合并冲突:
合并完冲突后,IDEA会自动生成一个标准revert的commit message,commit然后推上服务器即可:
在实际开发中我们可能经常会遇见这样的情况:
一个文件刚刚修改完,发现没改对或者没改完,于是又继续修改,继续提交,然后提交里面一大串连续的散碎提交,这时候为了不让log看起来很乱,可以考虑合并多个commit:
首先点要合并的提交里面最早那个,选择从此处开始重构基础:
选择该节点向上的所有节点,squash into,除第一项外后面的所有都选择为squash:
(博主在操作这一步的时候忘了截图,盗了其它地方的一张图,做个示例)
start rebasing:
重新输入commit message。
continue rebasing后可以看到多条提交记录合成了一个:
该块内容有点多,一个章节的篇幅有限,博主有单独的一篇文章来详聊:
该块内容有点多,一个章节的篇幅有限,博主有单独的一篇文章来详聊: