Git版本控制常见问题记录

HTxinghai

已于 2024-03-15 08:59:55 修改

阅读量405

点赞数 6

文章标签： git

于 2024-01-27 10:32:35 首次发布

本文链接：https://blog.csdn.net/HTxinghai/article/details/135867596

版权

前言

为了管理多人协同开发的软件项目，引入Git版本控制，在前人的博客基础上总结目前开发项目中使用 Git 可能会遇到的一些问题，并记录一些解决方法

一、前期准备工作

Git，TortoiseGit安装到工作电脑
代码托管和协助研发平台（Gitee&GitHub）账号，也可以自己搭建本地局域网的GitLab，用于存放、管理远程代码仓库
创建好自己的项目代码仓库
Git 常用命令的使用方法

Git、小乌龟、Gitee的概述与安装应用超详细（组长与组员多人开发版本）

二、常见问题

1.组员的工作流程

本地新建一个文件夹（工作区），克隆远端仓库到该文件夹，一般克隆的是远端仓库的master分支（最终版本分支）；远端仓库一般有master，dev分支，本地需要创建与远端仓库相同名称的分支，组员需要再创建个人开发分支，自定义名称。dev分支用于组员提交代码，管理者对组员提交的dev分支代码审核通过后合并到master分支。建议组员先在本地个人分支修改代码，提交到个人工作区分支后再合并到本地的dev分支，最后再推送到远端仓库的dev分支。

2.推送失败报错

（1）代码冲突

冲突原因：当前提交的分支（版本）与远端分支（版本）的同一文件的同一位置（行）的内容不一致。

模拟冲突：

修改远端分支的 README.md 文件，模拟其他组员修改后提交到远端，导致该组员本地分支落后一个版本。

远端文件修改

组员修改本地分支相同文件的相同位置的内容，且与远端不一致。

本地文件修改

本地分支推送失败：

推送失败提示

解决方法：拉取远端分支，手动修复冲突

点击冲突文件，手动修改冲突

在当前分支的工作区去提交合并后的修改内容到本地仓库，并推送到远端以完成冲突修复。

（2）版本落后导致推送失败

版本落后的主要原因：其他组员提交了变更到远端分支，导致你本地的分支落后了。

模拟问题：修改远端分支的 README.md 文件，模拟其他组员修改后提交到远端，导致该组员本地分支落后一个版本。增加一个网页链接，本地在不同位置增加其他内容；

远端分支的 README.md 修改内容

本地分支的 README.md 修改内容

从暂存区提交到本地仓库是没问题的，但本地的分支已经落后远端的分支一个版本以上，这个时候点击推送会提示错误，推送失败；

解决问题：先拉取远端分支的变更点，你可以在拉取完成后查看本地分支的与远端分支的差异点有哪些。一般拉取完成后若没有冲突的话，会自动合并，然后就可以直接点击推送，将合并后的分支推送到远端。

拉取远端差异内容

查看差异

列出所有的有差异的文件，可点击其中任意一个查看

3.仓库版本回退

版本回退的场景和方法可以参考下方的博客文章，这里根据本项目实际需求进行一些使用演示和说明。

Git 回退版本几种操作https://blog.csdn.net/kiritomzzz/article/details/131546316

Git 仓库版本回退方法https://blog.csdn.net/jackyzheng/article/details/76672921?ops_request_misc=&request_id=&biz_id=102&utm_term=git%20%E8%8E%B7%E5%8F%96%E4%BA%86%E5%85%B6%E4%BB%96%E7%BB%84%E5%91%98%E6%8F%90%E4%BA%A4%E7%9A%84%E7%89%88%E6%9C%AC%EF%BC%8C%E4%BD%86%E5%8F%88%E4%B8%8D%E5%90%88%E9%80%82%E6%83%B3%E5%9B%9E%E9%80%80%E5%88%B0%E4%B9%8B%E5%89%8D%E7%9A%84%E7%89%88&utm_medium=distribute.pc_search_result.none-task-blog-2~all~sobaiduweb~default-0-76672921.142%5Ev99%5Epc_search_result_base1&spm=1018.2226.3001.4187

（1）本地仓库

先在当前工作区（分支文件夹）打开Git命令行终端。

$ git log // 查看当前分支的提交信息
$ git reflog // 查看当前仓库所有分支的提交信息
// 注意：退出log查看请按‘Q’按键，信息太多使用‘B’按键翻页

Git log 查询提交日志

$ git reset --hard [commit ID] // 将仓库和工作区都回退到指定的版本
$ git reset --hard HEAD^ // 回退到上一次提交的版本

注意： 该方法会导致跳转版本之后的版本丢失，目前不知道如何恢复，请谨慎操作

（2）远端仓库

如果远端仓库提交了错误的版本导致需要回退，这个操作会复杂一些，如果涉及范围太广，建议直接修改问题代码，不要进行回退，组员在本地确认好后再上传，避免版本混乱。此外组员在远端仓库有重要更改需在小组开发群通知其他组员！

4. 忽略部分文件跟踪

项目中的一些文件是不需要跟踪，也就是不需要保存到库的。一些工程中间生成文件，比如*.lst，*.obj 文件，每次重新编译都会自动生成的。若想在提交时，不让这些文件的变更提示出来，可以根据（2）的说明创建 .gitignore 文件，若有已跟踪的文件可按照（1）的说明进行清除。

（1）已跟踪文件的忽略方法

// 忽略已被跟踪的文件
$ git rm -r --cached <dir> // 取消dir文件夹下的所有文件的跟踪状态并删除
$ git rm -r --cached <file> // 取消指定文件的跟踪状态并删除

取消 Listing 文件夹下所有文件的跟踪状态

已显示为未跟踪的状态

取消跟踪后需要提交到本地分支，然后上传到远端即可同步此次的操作。

不取消勾选的话，又会跟踪所有的文件

（2）.gitignore 忽略规则文件

创建 .gitignore 忽略规则纯文本（UTF-8）文件，适用于还未被跟踪的文件。在工作区文件夹下创建一个文本文件，并重命名为 .gitignore ，在文件中添加忽略规则文本。保存提交后同步到远端完成部分文件忽略。

# 常用忽略规则，该文件放在工作区文件夹下，根目录即工作区文件夹
# /dir1/：忽略根目录下的dir1文件夹以及dir1文件夹下的所有子文件夹和文件
# dir2/：忽略根目录下或者根目录下任意子目录下的dir2文件夹以及dir2文件夹下的所有子文件夹和文件
# /file1：忽略根目录下的file1
# file2：忽略根目录下或者根目录下任意子目录下的file2
# 

# ignore dirs
/SoftwareProject/T5L51-2022.04.15master/Listings/
/SoftwareProject/T5L51-2022.04.15master/Objects/

/SoftwareProject/T5L51-2022.04.15slave1/Listings/
/SoftwareProject/T5L51-2022.04.15slave1/Objects/

/SoftwareProject/T5L51-2022.04.15slave2/Listings/
/SoftwareProject/T5L51-2022.04.15slave2/Objects/

/SoftwareProject/T5L51-2022.04.15slave3/Listings/
/SoftwareProject/T5L51-2022.04.15slave3/Objects/


# ignore files
测试文本.txt

.gitignore 文本内容

5. 工作区索引更新

工作区索引更新是指在仓库分支中删除，增加文件。

对于已跟踪的文件的删除，Git会自动跟踪其状态，包括删除记录。若增加新的文件，则需要添加跟踪，可以在 Git bash 使用git add <filePathName>；也可以在使用小乌龟的提交时，在提交界面简单直观的添加，如下图所示。

三、实际的使用记录

1.拉取

可以将远端对应分支的差异同步到本地分支，目前发现.bat文件的内容差异并不会引发冲突。

2.获取

获取对应远端分支的最新版本，可以按需将远端分支的更改合并到本地分支。

3.工作流程

以下是ChatGPT生成的回答，挺正确的，在这里直接引用了

常用操作流程：

创建 Pull Request 的流程主要涉及以下步骤，这是基于常见的 Git 版本控制系统的操作，如 GitHub 或 GitLab：

1. **创建分支：** 在本地仓库中，基于目标分支（通常是主分支）创建一个新的分支，用于进行您的修改或添加新功能。

```bash
git checkout -b feature-branch
```

2. **进行修改：** 在新分支上进行必要的代码修改，添加新功能，或者进行其他更改。

3. **提交更改：** 将您的更改提交到新分支。

```bash
git add .
git commit -m "Your commit message"
```

4. **推送分支：** 将新建的分支推送到远程仓库。

```bash
git push origin feature-branch
```

5. **在远程仓库中创建 Pull Request：** 登录到您使用的版本控制平台（如 GitHub、GitLab 等），找到您的仓库，选择创建 Pull Request。选择您的新分支作为源分支，选择要合并到的目标分支，然后填写描述信息。

6. **Review 和讨论：** 团队成员可以查看您的 Pull Request，并提出评论、建议修改或批准合并。

7. **可能的修改：** 如果有评论或建议，您可能需要在本地进行修改，并将更改提交到相同的分支，然后再次推送。

```bash
git add .
git commit -m "Addressing feedback"
git push origin feature-branch
```

8. **合并 Pull Request：** 一旦 Review 完成，您或者其他有权限的人可以选择合并 Pull Request。这会将您的更改合并到目标分支中。

9. **删除分支：** 一旦 Pull Request 合并完成，可以选择删除您的新分支（可选）。

```bash
git branch -d feature-branch # 本地删除分支
git push origin --delete feature-branch # 远程删除分支
```

这个流程可以根据使用的具体版本控制平台和团队的工作流程而有所不同，但通常遵循相似的步骤。确保在创建 Pull Request 之前进行充分测试，写明清晰的描述，以便 Reviewer 和团队了解您的更改的目的和影响。

上面的流程适用比较大型的项目，开发者比较多的情况。目前我的项目没有那么多开发人员，所以第五步我们可以不用去做，直接在本地拉取Dev分支，获取最新版本，然后组员在本地直接合并同步组员的更改、新增，最后在推送到远端。用下述流程替换上述第五步，后续步骤亦不用再做，减少不必要的流程，提高效率。当然也可能会导致项目质量不太好把控。

如果您在本地解决了合并冲突并且直接推送到远程仓库而不是通过创建 Pull Request，这通常是一种操作方式，尤其在一些个人项目或者小团队中可能更为直接。这个流程适用于您拥有对目标分支的直接推送权限的情况。

步骤如下：

1. **拉取最新代码：** 在您的本地仓库中，确保您的目标分支是最新的。

```bash
git checkout target-branch
git pull origin target-branch
```

2. **切换到待合并的分支：** 切换到您要合并的分支。

```bash
git checkout feature-branch
```

3. **合并并解决冲突：** 执行合并操作，并解决任何合并冲突。

```bash
git merge target-branch
```

4. **提交解决冲突的更改：** 解决完冲突后，提交更改。

```bash
git add .
git commit -m "Resolve merge conflict"
```

5. **推送合并后的分支：** 将合并后的分支推送到远程仓库。

```bash
git push origin feature-branch
```

6. **直接推送到目标分支（可选）：** 如果您有直接推送到目标分支的权限，您也可以将更改直接推送到目标分支。

```bash
git push origin target-branch
```

请注意，这种直接推送的方式需要谨慎使用，特别是在多人协作的项目中。在大型项目或者开源项目中，通常更推荐使用 Pull Request 或者合并请求等机制，以便进行更全面的代码审查和集体讨论。这可以帮助确保代码质量和团队协作的透明性。

4.新增工程文件

首先使用 git add 【工程文件路径】指令，添加跟踪。使用 git ls-files 指令查看当前路径下已跟踪的文件。Git默认配置下查看已跟踪文件时，不能正常显示中文，可以参考下方博客进行配置修改。Git Bah 显示中文配置https://blog.csdn.net/u012145252/article/details/81775362