Git版本控制常见问题记录

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

2.个人（本地）版本控制

单片机的项目大部分都是单人开发，一般不需要多人。有时候可以直接使用Git对软件项目工程文件夹进行版本控制，好处就是可以版本控制，每次更改都有记录，搭配VS code使用源代码管理插件，还可以查看当前变更，还是比较有帮助的，这里简单记录一下如何快速实现，以及一些问题的解决；

首先找到工程文件夹，右键选择Git Bash，输入 git init 指令后，就在当前文件夹下创建了本地仓库，但这个本地仓库是空的，需要点击提交后，手动勾选需要跟踪的文件。这里提供了一个脚本，支持一键添加所有的*.c，*.h文件，并指定取消对某些文件的跟踪；

@echo off
REM Git初始化脚本.bat：
REM 该脚本用于初始化Git跟踪文件，删除已跟踪的编译生成文件以及其他需要跟踪的文件，添加必要的.c,.h文件跟踪
REM 当路径有空格的时候使用""包含一下，例如"%GIT_BASH_PATH%"，防止解释错误
REM 注意：使用此脚本时，请在当前工作区路径下打开 git bash 命令窗口

REM 查找 Git Bash 可执行文件的路径
for /f "delims=" %%i in ('where git-bash.exe') do set GIT_BASH_PATH=%%i
REM echo GIT_BASH_PATH = %GIT_BASH_PATH%
REM 如果找到 Git Bash，则继续；否则给出提示并退出
if not "%GIT_BASH_PATH%"=="" (
  REM 打开 Git Bash，并调转到工作区
  start "%GIT_BASH_PATH%"

  REM 等待 Git Bash 启动
  :WAIT_LOOP
  timeout /t 1 /nobreak >nul
  REM 检查 Git Bash 进程是否存在
  tasklist /fi "imagename eq bash.exe" | find ":" >nul
  if errorlevel 1 goto WAIT_LOOP

  REM 执行其他指令
  echo "Git Bash 已启动，执行其他指令"

  REM 获取当前工作区路径
  set SCRIPT_PATH="%~dp0"
  REM 切换到工作区
  cd "%SCRIPT_PATH%"

  REM 添加必要的跟踪文件（包括已跟踪但有新版本的同名文件）
  REM 正在添加所有子目录中的 .c 和 .h 文件到暂存区
  for /r %%i in (*.c *.h) do git add "%%i"


  REM 删除 不需要跟踪的文件
  REM 后续新增工程需要跟踪的文件需要手动在下方添加删除指令
  REM ignore dirs：git rm -r --cached xx/

  REM ignore files：git rm -r --cached xx/T5L51.uvgui*

  REM 提交更改...
  git commit -m "初始化Git仓库的跟踪文件，删除不需要的文件，添加必要的跟踪文件"
  REM 列出已提交的文件...
  git show --name-only --oneline HEAD
) else (
  echo 未找到 Git Bash 可执行文件，请检查安装路径或环境变量设置，请将目标路径加入到系统环境变量中。
)
REM 暂停查看脚本执行情况
pause

2.推送失败报错

（1）代码冲突

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

模拟冲突：

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

远端文件修改

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

本地文件修改

本地分支推送失败：

推送失败提示

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

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

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

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

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

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

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

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

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

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

拉取远端差异内容

查看差异

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

3.仓库版本回退

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

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

Git 仓库版本回退方法https://blog.youkuaiyun.com/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.拉取（Pull）

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

2.获取（Fetch）

获取对应远端分支的最新版本保存到另一个区域中，不会影响当前的本地仓库，可以按需将远端分支的更改合并到本地分支。

拉取与获取操作的区别

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.youkuaiyun.com/u012145252/article/details/81775362