Git协作

Git协作

冲突

在版本控制系统中，特别是在使用Git时，冲突（Conflict）指的是当多个团队成员对同一个文件的相同部分进行更改并尝试合并这些更改时发生的问题。冲突通常出现在合并分支、重基（rebase）操作或应用补丁时，因为这些操作涉及将一个分支的更改整合到另一个分支上。

冲突的发生情况

冲突发生的典型情况包括：

1. 编辑冲突：
   两个或更多开发者修改了同一个文件的同一部分。例如，如果开发者A删除了一个函数，而开发者B在同一函数中添加了一些新代码，当这两个分支合并时，Git无法自动决定哪个版本是正确的。

2. 文件冲突：
   一个开发者修改了一个文件，而另一个开发者删除了同一个文件，或两个开发者重命名/移动了同一个文件但目标不同。

解决冲突

当冲突发生时，Git会标记冲突的文件，并在文件内容中插入特定的标记，指示冲突的位置。这些标记分为以下几部分：

• 开始冲突标记 <<<<<<<：此标记后跟的是当前分支的内容。
• 分隔符 =======：分隔当前分支内容和其他分支的内容。
• 结束冲突标记 >>>>>>>：此标记后跟的是合并进来的分支的内容。

例如，如果在两个分支上对同一文件的同一行进行了不同的更改，Git无法自动合并，文件将包含类似以下内容：

<<<<<<< HEAD
console.log("This is the version in the current branch.");
=======
console.log("This is the version in the branch being merged.");
>>>>>>> feature-branch

如何处理冲突

解决冲突通常涉及以下步骤：

1. 识别冲突：
   使用 git status 查看哪些文件存在冲突。

2. 手动编辑文件：
   打开冲突文件，查看冲突标记，并决定保留哪个版本的更改，或者可能合并这两个版本的更改。

3. 标记文件为已解决：
   解决完冲突后，使用 git add <file> 命令将文件标记为已解决。这告诉Git您已经手动解决了这些冲突。

4. 完成合并：
   一旦所有冲突都被解决并标记，完成合并过程，通常是通过 git commit 命令。通常，Git会提供一个默认的合并提交消息，确认即可。

处理冲突需要细致的注意力，确保合并后的结果符合预期，同时保持代码的功能和完整性。在团队环境中，有效的沟通和代码审查可以大大减少冲突的发生。

1 分支

1.1 什么是Git分支

在处理不同任务的时候开不同的分支，把不同的任务区别开

多个不同的分支可以合并成一个分支，各个分支互不影响，除非拉取新的更改

为每个任务创建分支是个值得采用的做法，可以更好的追溯变更。

1.2 创建分支

创建新的分支不会更改存储库，只是指出了提交。如下图所示，使用 git branch 命令创建一个名为issue1的分支，存储库将保持不变，只是为当前提交添加了一个新指针。

2 切换分支

git checkout 命令可更新工作树中的文件，以匹配存储在您希望切换到的分支中的版本。类似于切换目录或者工作区。

2.1 指向分支

HEAD 用于表示分支的当前快照。对于一个新的存储库，在默认情况下，Git 会将 HEAD 指向主分支。更改 HEAD 指向的位置将更新您的活动分支。

(代字号) 和 ^ (插入符号) 指向相对于特定提交的位置。这些符号与提交引用一起使用，通常是 HEAD 或提交哈希(hash)。

• ~ 指的是祖先 (多少代取决于~后的数字)。
  • HEAD~1 指的是提交的第一个父级。
  • HEAD~2 指的是提交的第一个祖父级。
• ^ 指的是合并提交的父级。
  • HEAD^1 指的是 HEAD 的第一个父级，其中 head 是合并提交。
  • HEAD^2 指的是 HEAD 的第一个祖父级，其中 head 是合并提交。

合并提交中的提交可以有多个父项。

2.2 暂存分支

当您在使用Git进行版本控制时，可能会遇到需要在多个分支之间切换的情况，同时又希望保留未提交的更改。这时，Git提供了一些策略来处理这些未提交的更改，以便您可以无碍地在不同分支间进行工作。

切换分支与未提交更改的处理

1. 基本行为：

   • 当您在工作树中有未提交的更改（包括新文件、修改或删除的文件）时，这些更改可以被带到新分支上，前提是不会与新分支的文件产生冲突。
   • 如果您提交了这些更改，它们将仅存在于您切换到的新分支上。

2. 冲突防止切换：

   • 如果存在冲突（即，当前分支的未提交更改与目标分支的文件内容不兼容），Git不会允许您直接切换分支。这是为了防止潜在的代码丢失。

使用 Stash 临时保存更改

为了解决在分支间切换时带来的问题，Git 提供了一个称为 stash 的功能，允许您临时存储未提交的更改，以便您可以清洁地切换到其他分支继续工作。

Stash 的工作原理：

• 存储更改：
  使用 git stash 或 git stash push 命令将当前工作树中的更改保存起来，这样您的工作树就回到了干净的状态（如同刚刚克隆仓库后的状态）。

  git stash
  

• 列出存储的更改：
  可以通过 git stash list 查看所有存储的更改条目。

  git stash list
  

• 恢复更改：
  当您需要恢复之前存储的更改时，可以使用 git stash pop（应用最近的更改并从stash列表中移除它）或 git stash apply（应用更改但保留在stash列表中）。

  git stash pop
  

• 让我们通过一个具体的例子来说明如何使用 git stash 来管理工作区中未提交的更改，使您能够在不同的分支之间灵活切换。

  场景设定

  假设您正在开发一个新功能，在分支 feature-x 上工作。在您开发的过程中，突然接到通知需要立刻解决主分支 main 上的一个紧急bug。

  此时，您的工作区有未提交的更改，这些更改还不够稳定，不能直接提交。同时，您需要切换到 main 分支来修复bug。

  使用 Git Stash

  1. 保存当前更改
     在您的 feature-x 分支上，使用以下命令将所有未提交的更改（包括暂存和未暂存的）存入stash：

     git stash push -m "WIP: Feature X adjustments"
     

     这里的 -m 选项允许您为stash项添加一个描述性消息，便于以后识别和恢复。

  2. 查看Stash列表