Git协作

Git协作

辩论

在版本控制体系中，特殊是在利用Git时，辩论（Conflict）指的是当多个团队成员对同一个文件的类似部分举行更改并实验归并这些更改时发生的题目。辩论通常出现在归并分支、重基（rebase）操纵或应用补丁时，由于这些操纵涉及将一个分支的更改整合到另一个分支上。
辩论的发生环境

辩论发生的范例环境包罗：

  

• 编辑辩论：
  两个或更多开发者修改了同一个文件的同一部分。比方，假如开发者A删除了一个函数，而开发者B在同一函数中添加了一些新代码，当这两个分支归并时，Git无法自动决定哪个版本是准确的。
    
  
• 文件辩论：
  一个开发者修改了一个文件，而另一个开发者删除了同一个文件，或两个开发者重定名/移动了同一个文件但目的差别。
  
  

办理辩论

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

  

• 开始辩论标记 <<<<<<<：此标记后跟的是当前分支的内容。  
  
• 分隔符 =======：分隔当前分支内容和其他分支的内容。  
  
• 竣事辩论标记 >>>>>>>：此标记后跟的是归并进来的分支的内容。
  

比方，假如在两个分支上对同一文件的同一行举行了差别的更改，Git无法自动归并，文件将包罗类似以下内容：

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

复制代码

如那里理辩论

办理辩论通常涉及以下步调：

  

• 辨认辩论：
  利用 git status 检察哪些文件存在辩论。
    
  
• 手动编辑文件：
  打开辩论文件，检察辩论标记，并决定保存哪个版本的更改，大概大概归并这两个版本的更改。
    
  
• 标记文件为已办理：
  办理完辩论后，利用 git add <file> 下令将文件标记为已办理。这告诉Git您已经手动办理了这些辩论。
    
  
• 完成归并：
  一旦全部辩论都被办理并标记，完成归并过程，通常是通过 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提供了一些战略来处置惩罚这些未提交的更改，以便您可以无碍地在差别分支间举行工作。
切换分支与未提交更改的处置惩罚

  

• 根本活动：
  
     
  
  • 当您在工作树中有未提交的更改（包罗新文件、修改或删除的文件）时，这些更改可以被带到新分支上，条件是不会与新分支的文件产生辩论。   
    
  • 假如您提交了这些更改，它们将仅存在于您切换到的新分支上。   
    
     
  
• 辩论防止切换：
  
     
  
  • 假如存在辩论（即，当前分支的未提交更改与目的分支的文件内容不兼容），Git不会答应您直接切换分支。这是为了防止潜伏的代码丢失。   
    
    
  

利用 Stash 临时生存更改

为了办理在分支间切换时带来的题目，Git 提供了一个称为 stash 的功能，答应您临时存储未提交的更改，以便您可以干净地切换到其他分支继续工作。
Stash 的工作原理：

  

• 存储更改：
  利用 git stash
  或 git stash
  push 下令将当前工作树中的更改生存起来，如许您的工作树就回到了干净的状态（犹如刚刚克隆堆栈后的状态）。
  
  1. git stash

  复制代码
  
  
• 列出存储的更改：
  可以通过 git stash
  list 检察全部存储的更改条目。
  
  1. git stash
  2. list

  复制代码
  
  
• 规复更改：
  当您必要规复之前存储的更改时，可以利用 git stash
  pop（应用迩来的更改并从stash列表中移除它）或 git stash
  apply（应用更改但保存在stash列表中）。
  
  1. git stash
  2. pop

  复制代码
  
  
• 让我们通过一个详细的例子来阐明怎样利用 git stash
  来管理工作区中未提交的更改，使您可以或许在差别的分支之间机动切换。
  场景设定
  
  假设您正在开发一个新功能，在分支 feature-x 上工作。在您开发的过程中，突然接到关照必要立刻办理主分支 main 上的一个告急bug。
  此时，您的工作区有未提交的更改，这些更改还不敷稳固，不能直接提交。同时，您必要切换到 main 分支来修复bug。
  利用 Git Stash
     
  
  • 生存当前更改
    在您的 feature-x 分支上，利用以下下令将全部未提交的更改（包罗暂存和未暂存的）存入stash：
    
    1. git stash
    2. push -m "WIP: Feature X adjustments"

    复制代码
    这里的 -m 选项答应您为stash项添加一个形貌性消息，便于以后辨认和规复。
       
    
  • 检察Stash列表
    输入以下下令检察当宿世存的stash项：
    
    1. git stash
    2. list

    复制代码
    这会表现全部stas