如何在IDEA上配置使用Git
一、IDEA对于Git&GitHub的支持
1、IDEA对GitHub和Git的基本配置
案例演示
首先建立一个演示项目(web项目即可),然后建立一个User类,里面写上初始测试内容
打开settings --> Version Control --> GitHub
填写GitHub网址,账号,密码,然后点击Test测试
上述测试成功后,配置Git
打开settings --> Version Control --> Git
第一栏文本框会自动识别到本地Git安装路径下的git.exe
点击测试
其他项维持默认即可
以上就是IDEA对于GitHub和Git的基本配置
以上配置完毕后,我们来操作项目
2、将IDEA项目push(推送)到GitHub
创建本地库
选中当前项目作为本地库
以上操作之后,会在当前项目的本地看到.git文件夹
说明当前项目文件夹作为本地库存在
将项目提交到暂存区
项目右键 --> Git --> Add
将项目提交到本地库
首先我们在提交前,需要忽略掉.iml文件
settings --> Editor --> File Types
添加*.iml
项目右键
选中刚刚模块中写好的未提交过的文件
点击Commit提交
将本地库中的文件上传到远程库
第一次提交,需要先写入提交的GitHub库的名字,以及上传地址
在GitHub上创建一个新仓库CRM
填写完以上信息后,推送项目到GitHub远程库
3、GitHub远程库clone项目到IDEA
新建一个空的Project,在另一个窗口打开(同时保留原有的项目窗口)
开始clone项目
填写基本信息
作为一个maven项目导入
将Maven项目目录结构写完整(注意文件夹颜色要赋予正确的颜色)
当编写java代码时,会提示没有编译环境
点击右侧的setup sdk
将加入了新属性的User类推送到远程库
注意:推送前,不要忘记先Add!!!
Add之后Commit and push
切换到第一个项目
暂时只有id属性(第二个项目有id属性和name属性)
所以第一个项目需要将name属性拉取,将更新为最新版
右键User类
如下图所示,所有默认,点击Pull
如果本地更改过文件(没有及时上传),拉取时会产生冲突
例如本地要上传的新属性是phone
但是远程库,最新的属性是address
这样会产生冲突,pull会失败
此时老版本idea,必须先要进行以下操作:
先将自己本地库最新的版本先以Stash的方式保存
然后再拉取
就会拉取成功了
最后将本地最新版(属性phone)合并进去
我们会看到即保留了刚刚pull远程库的最新版本的代码(address),又保留了自己本地库(phone)的代码
(新版本idea会直接跳到这步)调整冲突后(同时保留phone和address),执行add和commit操作,并push到远程库
注意:解决冲突后的文件,必须先add,在commit
4、GitHub实战演练
打开两个IDEA
设置GitHub远程库账号
一个登录bjpowernodeAdmin账号,一个登录bjpowernodeWorker账号
打开第一个窗口,然后打开idea中的控制台
执行命令:git branch -v 查看本地分支
执行命令:git branch -a 查看本地及远程分支
接下来按照之前的方式创建分支,并切换到该分支
在当前项目的随便一个文件上,随便敲点东西
然后观察idea右下角,就会切换为刚刚切换的分支
同时从分支信息查看可以看到,我们现在虽然创建了本地的分支,但是远程分支仍然只有master
添加代码 private int age;
然后通过当前分支bran1(上一步切换的bran1),add,commit,push到远程库
查看远程分支,就多出了bran1了
刚才的步骤相当于将本地的bran1分支强推到了远程上,让远程也拥有了bran1分支,但是本地的bran1分支和远程的bran1分支还没有正式的关联上。
接下来,我们要让本地的bran1分支和远程的bran1分支做关联,将来本地的bran1分支做的push推送都会直接推送到远程的bran1分支上
执行命令:git branch --set-upstream-to=test06/bran1
现在我们打开第二个idea,查看分支
我们会发现,第一个idea创建的bran1分支,在第二个idea中看不到
需要pull一下,这里的pull,即代表之前拉取的意义,也代表更新的意义
执行命令:get pull
我们再查看一次分支,就可以看到刚刚第一个idea建立的远程的bran1分支了
接下来在第二个idea中,新建本地分支bran2,建立完毕后查看本地分支
切换到bran2分支,并查看本地当前分支
与之前第一个idea的操作一样,在第二个idea的Person中随意敲点东西,查看idea右下角的当前分支
编辑Person,新增gender属性
以bran2的本地分支,执行add,commit,push
如果是以前没有分支的操作,push肯定会产生冲突(因为之前bran1分支推送了age,我们并没有pull),但是这一次我们的push是成功的,因为我们使用的是不同分支的push。同时,也将本地的bran2分支强推到了GitHub上。
执行git pull,然后查看远程分支,出现了bran2
执行命令:git branch --set-upstream-to=origin/bran2
将本地bran2分支和远程bran2分支做关联
观察github远程库,除了早期的master,我们由看到了刚刚推送的bran1和bran2分支
切换到bran1,我们会看到age
切换到bran2,我们会看到gender
观察master,仍然只有之前的id,name,phone,address
因为我们还没有在远程合并分支
由于Git是在自己计算机中使用的版本控制工具,所以之前学习过的本地的分支冲突以及合并只适合在自己计算机中的开发。
但是现在,我们是多台计算机合作开发,所以不同的分支是需要在远程库中进行合并,我的操作方式仍然是将所有的分支合并到master上
我们现在就要将bran1的age和bran2的gender合并到master上
点击菜单pull requests
然后点击 New pull request
选中bran1,向master合并
后点击Create pull request
点击按钮,开始进行合并
继续点击按钮
再次查看master
我们会看到bran1的age已经合并进去了
接下来我们可以通过相同的方式将bran2的gender合并进去
但是这时系统会告诉你不能进行合并
我们仍然点击下面的Create pull request按钮
填写信息,然后点击按钮
解决冲突
解决冲突
点击commit merge
这样就可以执行刚才未完成的合并master的操作了
合并之后,查看master,bran1的age和bran2的gender就都有了
接下来我们将远程master的信息,拉取到本地master上
首先将本地分支先切换到master上
master先在本地与bran1合并
然后从远程master进行拉取操作
然后可以将master的信息合并到bran1分支上
当然我们也可以使用图形界面切换分支
然后bran1也将最信息的信息更新下来了
二、Git&GitHub使用注意事项
1、保持原子性的提交
每次提交的间歇尽可能地短,以几个小时的开发工作为宜。例如在更改 UI 界面的时候,可以每完成一个 UI
界面的修改或者设计,就提交一次。在开发功能模块的时候,可以每完成一个小细节功能的测试,就提交一
次,在修改 bug 的时候,每修改掉一个 bug 并且确认修改了这个 bug,也就提交一次。我们提倡多提交,也
就能多为代码添加上保险。
2、对提交的信息采用明晰的标注
不论是在本机中使用本地库,还是未来推送到远程库,如果提交不明确的标注不仅仅会让自己怀疑当初提交
的目的,也会让项目组中其他的成员感到很无奈,项目经理无法很清晰的掌握工作进度,无法清晰的把握此
次提交的概要信息。在有必要的情况下也不能明确的的回到指定的历史记录。所以,在做提交工作时,要填
写明晰的标注,能够概要的描述所提交文件的信息,让项目组其他成员在看到标注后不用详细看代码就能了
解你所做的更新。
3、推送之前先拉取
GitHub拉取的原则是要随时拉取,随时推送。当完成了一个小功能,能够通过编译并且自己测试之后,谨慎
地推送。如果在修改的期间别人也更改了相同的文件,那么推送就可能会产生冲突,这种情况就需要同之前
的开发人员联系,两个人一起协商解决冲突,解决冲突之后,需要两人一起测试保证解决冲突之后,程序不
会影响其他功能。
4、不要推送不能通过编译的代码
代码在推送之前,首先要确认自己能够在本地编译。如果在代码中使用了第三方类库,要考虑到项目组成员
中有些成员可能没有安装相应的第三方类库。项目经理在准备项目工作区域的时候,需要考虑到这样的情
况,确保开发小组成员在签出代码之后能够在统一的环境中进行编译。
5、不要推送自己不明白的代码
代码在推送进入到GitHub之后,你的代码将被项目成员所分享。如果提交了你不明白的代码,你看不懂,别
人也看不懂,如果在以后出现了问题将会成为项目质量的隐患。因此在引入任何第三方代码之前,确保你对
这个代码有一个很清晰的了解。
6、提前协调好项目组成员的工作计划
项目经理应该合理分配工作计划。每个成员在准备开始进行某项功能的修改之前,如果有可能,先跟工作小
组的成员谈谈自己的修改计划,让大家都能了解你的思想,了解你即将对软件作出的修改,这样能尽可能的
减少在开发过程中可能出现的冲突,提高开发效率。同时你也能够在和成员的交流中发现自己之前设计的不
足,完善你的设计。