IDEA使用Git进行代码管理教程
系列文章目录
1.Win11Git安装教程
2.git同时配置Gitee和GitHub
文章目录
- 系列文章目录
- 前言
- 一、Git提交代码
- 二、合并分支
- 三、版本回退
前言
这一篇文章主要用来记录如何使用IDEA中的git进行代码管理，包括日常开发中进行代码提交，以及如何将开发分支的代码提交到主分支。如果想要看如何安装Git以及Git同时配置Gitee和GitHub的可以看一下上面的两篇文章。
一、Git提交代码
-
首先在idea中配置git，如图所示
选择git的安装路径，之后点击test，如果出现git的版本号表示配置成功。 -
然后在idea登录自己的gitee账号或者github账号
根据提示登录即可。 -
然后如果是新建项目，则可以在建立项目的时候勾选创建Git仓库(多module项目不推荐，如果是单项目可以使用该种方式)。如下图所示。
这样创建的向项目，我在使用过程中遇到了如下问题：
当我在该项目中，创建多个module时，默认会给每个module创建git仓库，也就是当你提交到远程Gitee时，需要把各module分别提交到单独的仓库。如下示例：
当我创建了一个eureka-demo项目，在创建的时候勾选了创建git仓库，然后又为该项目创建了几个module时，会发现每个module下都会有一个.git文件夹，表示每个module都创建了单独的仓库。这个时候，你去把整个项目提交到Gitee的时候，提交的项目文件是不包括module的。所以我一般都是先直接创建一个项目，然后在IDEA中VSC选择share project on gitee创建git仓库，这样每个module也很会包含在整个仓库中。 -
如果在创建项目时，没有勾选创建仓库，可以在进入项目后再通过VSC添加Git仓库，如下所示：
选则share project on gitee，然后填写仓库名，分支，仓库描述，并选择是公开还是私有。
然后点分享即可。
之后就可以再Gitee看到刚刚上传的分支了。 -
然后你可以创建一个dev分支，用来做开发环境，当dev修改测试通过之后，就可以把dev分支合并到主分支master。
-
平时的代码编写在dev分支，然后每次写完一个功能之后可以进行提交并推送到远程仓库，下面是如何进行推送。
-
在平时使用的使用，可以点击Git，然后下面有一些常用功能，介绍如下：
- commit： 将代码提交到本地仓库
- push：将本地仓库推送到远程仓库
- update：将远程仓库中的项目拉取到本地，更新本地项目（idea中的update进行的操作是可以设定的是以merge还是rebase进行更新）
- pull：拉取项目到本地
- merge：合并分支，保留分支提交历史，能从图谱中看到分支提交曲线
- rebase：合并分支，提交分支为一条直线，直观简洁。比如，将dev分支rebase到master分支，合并后的则在master分支。会改变提交历史，如果有冲突，需要手动解决。
- new branch： 新建分支
如上所示，当你代码修改后，可以先commit（绿色对号）到本地，然后push（绿色向上箭头）到远程，当需要将远程仓库中的更新拉取到本地则可点击蓝色向下箭头。
二、合并分支
对于合并分支，有两种方式merge和rebase，两种方式各有优点，具体如下所示：
git merge和rebase的区别如下：
- 操作方式不同：git merge会创建一个新的合并提交，这个提交有两个父提交，分别指向合并之前的两个分支。而git rebase则是将源分支的提交逐个应用在目标分支的顶部，使它们看起来像是在目标分支上连续提交的。
- 提交历史不同：git merge在提交历史中保留了明确的合并记录，能够清晰地展示分支的合并情况。而git rebase会改变提交历史，让提交历史更加线性和干净，但可能会丢失源分支的合并信息。
- 分支保留情况不同：git merge操作后，原始分支的历史保持不变。而git rebase虽然原始分支的提交仍然存在，但如果未保留源分支，则可能会被删除。
- 适用场景不同：git merge通常用于合并长期维护的分支到主分支或其他稳定分支，这样可以保留完整的分支历史。而git rebase通常用于保持提交历史的整洁和线性，特别是在临时性修复分支上工作时。它也常用于将最新的更改从目标分支合并到本地分支以避免合并冲突。
在实际使用中，可以根据项目的工作流和合并策略，根据需要选择合适的命令。请注意，使用git rebase时需要小心，避免在公共分支上使用，因为它会改变历史，可能导致冲突。而我一般是在dev中进行开发，然后master主分支为稳定分支，然后当需要把测试通过后的内容push到dev，然后使用merge合并到主分支，这样不仅能够保留明确直观的分支历史，也能通过提交历史中查看一个团队的工作方式，分配等。如果是多人合作项目，则rebase的应用场景是将主分支的内容合并到自己的开发分支，这样自己的分支提交历史清晰明了是一条线性的。
- 当你在dev分支的更新需要合并到其他分支的时候，可以在idea中进行合并，但合并前一般先update一下，拉取远程仓库中的最新更改，然后再进行合并。
- 打开git，查看当前分支
如上图所示，左侧显示的是本地分支和远程分支，右侧显示的是当前dev分支的活动历史。当你需要把dev上的更改提交到master上时，可以右键当前分支，如图所示：
这里有两个选择，一个是切换并将当前分支rebase到master分支上，另一个就是将当前分支merge到master上。提交时注意查看目前所在分支。
三、版本回退
原始项目结构如下所示
仓库提交历史如下；
-
首先选中自己要回退到的提交，然后右键选择copy Revision Number
-
然后在git中选择Reset HEAD
选择重置类型为hard，把刚刚复制的数字粘贴到第二个框内，然后点reset即可
可以看到我的提交已经变成了刚刚选中的那一个。
上面进行的时本地回退，这是如果我们进行push到远程仓库会出现被拒绝的问题，因为回退会导致远程仓库的内容比本地的提前，解决方法就是，去左侧的远程分支下复制当前的版本number（也就是在回退前的那个），然后回退类型为Mixed，如下所示。
之后，提交到本地，然后再push到远程仓库就行了。
提示:
在git中，reset head命令的reset type有三种类型，分别是soft、mixed和hard。它们各自的作用如下：
- Soft模式：通过使用
reset head --soft参数，可以将HEAD指针移动到指定提交，但不改变工作区和暂存区的内容。这意味着，当前分支的最新提交会变为指定的提交，但工作区和暂存区的文件内容不会发生改变。这种模式适用于需要重新提交之前的修改的情况。 - Mixed模式（默认模式）：通过使用
reset head --mixed参数，可以将HEAD指针移动到指定提交，并且将工作区的内容重置为指定提交的内容，但不会改变暂存区的内容。这意味着，当前分支的最新提交会变为指定的提交，工作区的文件内容会变为指定提交的内容，但暂存区的文件内容保持不变。这种模式适用于需要撤销工作区的修改的情况。 - Hard模式：通过使用
reset head --hard参数，可以将HEAD指针移动到指定提交，并且将工作区和暂存区的内容都重置为指定提交的内容。这意味着，当前分支的最新提交会变为指定的提交，工作区和暂存区的文件内容都会变为指定提交的内容。这种模式是最彻底的重置模式，适用于需要完全舍弃之前的修改的情况。
综上所述，这三种模式在重置HEAD指针时具有不同的影响范围，可以根据实际需求选择适合的模式。