1、创建新项目、配置本地git
忽略文件.gitignore
①HELP.md 忽略HELP.md文件 ②*.log 忽略所有.log文件 ③target/ 忽略当前路径下的target文件夹,该文件夹下的所有内容都会被忽略,不忽略target文件 ④**/foo 忽略/foo, /foo, a/b/foo等 ⑤!**/src/main/** 不忽略相应文件
配置git
Settings -> Version Control ->Git
2、基本Git操作
- 初始化本地仓库:git init
提交到本地仓库:
①git add 文件名 / git add . (这一步是将工作区的文件,添加到暂存区) ②git commit -m "日志信息" [文件名]
这一步相当于将文件从工作区添加到暂存区。
这一步相当于将暂存区的待提交文件提交到本地仓库。
以上就代替了之前提交到本地仓库的繁琐步骤,现在只需要操作可视化界面即可完成文件的提交。
查看当前git的信息:
- 设置远程仓库:git remote add origin 仓库地址
首先我们要新建一个远程仓库:
下面在Idea中,设置这个远程仓库:
- 推送远程服务器:git push origin master
- 修改或新增文件推送远程服务器:
下面去gitee的远程仓库查看代码是否推送过去了:
可见此时确实在远程仓库中,更新了最新推送的文件。
如果你偏偏不想通过可视化界面的方式,完成修改/新增代码的推送工作:
但是上面哐哐敲一堆代码,不如人家按两下按钮快捷。因此具体选择哪一种,还是看个人喜好罢了。
- 拉取:git pull origin 分支名
当然如果你还是不愿意通过可视化界面完成远程仓库拉取代码,那么你还可以通过命令行的git pull
origin 分支名 , 来完成代码的拉取。
3、克隆与分支操作
- 克隆项目:git clone 仓库地址 本地目录
由于没有将IDEA的某些配置文件上传到gitee的远程仓库,因此我们需要手动添加模块、重新加载pom.xml文件:
经过以上的操作,我们克隆下来的代码,应该就能跑了。
创建并切换分支:
①git branch 分支名 ②git checkout 分支名
创建分支操作:
将当前分支切换到主分支(master):
- 推送、新建分支:
在IDEA中,切换到dev分支,然后稍微改动一下pom.xml文件(是为了改动而改动,不然没有新代码可以推送):
然后将该分支,推送到远程仓库:
去远程仓库,查看一下,是否新建了dev分支:
那么我们如何让远程仓库的master分支、dev分支的代码同步呢?
答案:在IDEA中,将dev分支合并到master分支上,然后推送到远程仓库即可:
然后将主分支,推送到IDEA的主分支即可:
去gitee的远程仓库上,查看master分支:
可见此时master分支也是4次提交,做到了和dev分支的代码同步。
4、合并冲突解决
冲突发生的场景:两人改动了同一个文件。
- 正常拉取:git pull origin 分支名
- 拉取后冲突合并: - git merge 分支名- 人工处理
场景模拟(声明:下面的springMVC项目,克隆的是远程仓库的big-event项目,因此这俩项目,操作的都是远程仓库 - gitee上的springMVC项目):
①小李同学(springMVC项目),在master主分支中,编写UserController的test接口,如下:
去gitee远程仓库,查看是否更新:
②小明同学(big-event项目),不知道小李同学提交了①中的内容,也在master主分支中,编写UserController的test接口,如下:
这个过程,就是先将远程仓库的对应代码拉取下来,然后再人为合并一下,看看留下哪一段代码,解决冲突后,再推送到远程仓库即可。
以上我们就完成了分支冲突,然后直接推送到远程仓库即可:
去gitee的远程仓库,查看代码是否成功被推送过去了:
此时我们的冲突得到了解决,并将合并后的代码推送到了远程仓库,下一步就需要小李(springMVC项目)自己去拉取远程仓库的代码,让自己电脑的项目也得到更新:
以上就是模拟冲突发生 -> 冲突解决 -> 拉取(更新)代码 的全部过程。
5、友情提示
- 代码及时提交,提交过了就不会丢,有历史版本可以切换
- 切换分支前先提交本地的修改
- 遇到任何问题都不要盲目删除 - 在公司,找组长- 在学校,找老师或学长
6、Git的冲突的理解与忠告
Git 冲突(Conflict)通常发生在多个开发者同时修改同一个文件的不同部分,并将这些修改合并到同一个仓库时。Git 冲突是版本控制系统中非常常见的问题,特别是在团队协作中。以下是几种可能导致 Git 冲突发生的场景:
- 并行开发:当两个或更多的开发者在几乎相同的时间对同一个文件的不同部分进行修改,并尝试将这些修改合并到主分支(如
master
或main
)或其他分支时,就可能发生冲突。 - 分支合并:当两个分支各自独立开发了一段时间后,需要将这些分支合并到一个主分支时,如果这两个分支都修改了同一个文件,就可能发生冲突。这包括功能分支合并到主分支,或者多个功能分支之间合并的情况。
- 远程仓库更新:如果你正在本地分支上工作,并且在此期间其他开发者已经向远程仓库推送了更新(这些更新也修改了你在本地分支上正在工作的文件),当你尝试将你的更改推送到远程仓库时,Git 会尝试合并这些更改,这可能会导致冲突。
- 回退(Rebase)操作:当你尝试将你的更改(在一个特性分支上)回退到另一个分支(如主分支)的顶端时,如果这两个分支在合并点之后对同一个文件进行了修改,就可能发生冲突。回退操作试图创建一个线性的提交历史,这要求解决所有潜在的冲突。
解决 Git 冲突通常需要手动编辑冲突的文件,找到冲突的部分,并决定保留哪些更改(因为机器是无法判断你需要保留、需要删除哪些代码,因此只能人为地操作)。Git 会在冲突的文件中标记出冲突的部分,并提示你如何解决这些冲突。解决冲突后,你可以将更改添加到暂存区(stage)并提交合并后的更改。
即:git没有那么先进,不知道冲突发生时,谁对谁错,因此还是需要人为手动解决合并冲突(冲突发生时,先把有冲突的代码从远程仓库拉取下来,然后人工解决冲突后,再推送到远程仓库即可)。
为了避免或减少冲突的发生,团队成员之间应保持良好的沟通,并确保在合并前解决所有已知的冲突。使用工具如 Pull Requests(拉取请求)可以帮助在合并之前审查代码,从而及早发现并解决潜在的冲突。
版权归原作者 雪碧聊技术 所有, 如有侵权,请联系我们删除。