Git 的进阶功能和本领

1、分支的概念和利用

1.1、什么是分支？

分支（Branch）是在版本控制中非常重要的概念。几乎所有版本控制体系都支持某种形式的分支。在 Git 中，分支是 Git 强盛功能之一，它允许我们从主开辟线分离出来，在不影响主分支的环境下并行地举行开辟 (Git 分支管理 | 菜鸟教程)。你可以把分支想象成代码开辟的平行宇宙：在一个分支上举行的修改，不会立刻出现在另一个分支上。开辟者可以利用分支来尝试新功能、修复 Bug 或举行实验，而无需担心弄乱主分支（通常是用于发布的稳固分支）。完成工作后，再把分支的改动归并回主分支，这样主分支就得到了更新，而整个过程主分支始终保持可用和稳固。
简而言之，利用分支可以让团队并行开辟成为可能：每个人或每个新功能都在自己的分支上举行，互不干扰。等到必要整适时，再将分支归并。下面我们将介绍 Git 中有关分支操作的常用命令：创建分支、切换分支以及归并分支。
1.2、创建和切换分支（git branch, git checkout）

在 Git 中，新建分支利用命令 git branch，切换分支利用命令 git checkout（在较新的 Git 版本中，也可以利用 git switch 切换分支）。我们先来看如何创建一个分支：

• git branch <分支名>：创建一个新的分支。此命令将在当前所在提交的基础上创建出一个分支指针。留意，仅执行 git branch 命令不会切换到新分支，只是新建了一个分支。
  

比方，如果我们当前在主分支 main 上，希望创建一个新分支来开辟登陆功能，可以执行：
  

1. git branch login-feature

复制代码

此操作会在当前提交的基础上创建一个名为 login-feature 的新分支。但是此时我们仍停顿在 main 分支上。通过 git branch 不带参数可以列出所有本地分支，* 会标识当前所在的分支。

• git checkout <分支名>：切换到指定的分支。切换分支会更改工作区的文件内容，以匹配该分支最近一次提交的状态。执行切换前，确保当前工作区没有未提交的修改，否则 Git 会拒绝切换（或者要求先 stash 暂存修改）以防止未提交的更改被覆盖。
  

继续上面的例子，我们创建了 login-feature 分支后，可以切换已往：
  

1. git checkout login-feature

复制代码

执行后，Git 会提示已经切换到 login-feature 分支。现在开始的所有提交都会在 login-feature 分支上，而对 main 分支没有影响。
一个常用的快捷方式是将创建和切换合为一步完成：git checkout -b <分支名>。比方：
  

1. git checkout -b login-feature

复制代码

如果 login-feature 不存在，这条命令会创建该分支并立刻切换已往，相当于依次执行了 git branch 和 git checkout。这样更方便一些。
乐成切换到新分支后，你可以像往常一样编辑代码、添加和提交。所有这些提交将属于 login-feature 分支，与主分支main的提交汗青分离开。你可以随时利用 git checkout main
切换回主分支，如果此时打开项目文件，会发现那些在 login-feature 分支上做的改动不见了（由于此刻看到的是主分支上的内容）。别担心，这些改动仍然安全地生存在 login-feature 分支，只是当前未归并到主分支而已。
   小贴士：在多人协作中，通常每个功能或修复都会新建一个分支举行开辟，分支定名应轻便明了，如 feature/login-ui 或 bugfix/issue-101 等。主分支一样平常用来生存已经稳固并准备发布的代码。
  1.3、归并分支（git merge）

当一个分支上的开辟告一段落，必要将其成果归并回主分支（或其他分支）时，就可以利用 git merge 命令。git merge 用于将另一条分支的修改归并到当前分支上。
最常见的场景是将功能分支归并回主分支。比方，我们在 login-feature 分支上完成了登陆功能的开辟和测试，现在希望把它归并到 main。步调如下：

• 首先，切换到目的分支（即我们希望将改动归并到的分支）。这里是主分支 main：
        
  1. git checkout main

  复制代码
• 然后执行归并命令，将功能分支归并过来：
        
  1. git merge login-feature

  复制代码
     这条命令表示：“把分支 login-feature 归并到当前分支（main）”。
  

执行 git merge 后，可能出现两种环境：

• 快速前进（Fast-forward）归并： 如果主分支在功能开辟期间没有新的提交，那么主分支实际上停顿在功能分支的出发点上。在这种环境下，Git 不必要创建新的归并提交，而只会简单地将主分支指向功能分支的最新提交。这种归并被称为 “快进”，体现出来就是主分支的汗青直接向前推进，包含了功能分支的提交记录。
  
• 非快进归并： 如果主分支在功能分支开辟期间有自己的新提交，那么两个分支的汗青出现了分叉。Git 会举行一次“三方归并”（three-way merge），自动创建一个新的归并提交来把分叉的汗青归并起来。归并提交包含两个父提交，一个来自主分支原来的末端，一个来自功能分支的末端。归并提交的默认说明一样平常是“Merge branch 'login-feature' into main”。
  

在大多数环境下，如果没有冲突，Git 会自动完成以上两类归并。归并后，可以利用 git log --graph --oneline 来查看汗青，分支的提交记录现在都出现在主分支的汗青中了。完成归并后，功能分支的代码已经融合进主分支，通常我们可以选择删除那个已完成的功能分支以保持堆栈整齐。删除本地分支的命令是：
  

1. git branch -d login-feature

复制代码

-d 选项表示删除分支（该操作不会影响已经归并到的内容）。如果分支尚未归并就尝试删除，Git 会发出告诫并拒绝删除，以免丢失未归并的修改。若确定要强行删除，可以用 -D（不保举轻易利用）。
   留意：归并前请确保将待归并的分支最新内容拉取下来（如果是多人协作且远程有更新的话）。好比在归并远程分支时，先 git pull origin login-feature 更新本地的 login-feature，再切换到 main 归并。这样可以淘汰归并冲突的概率。
  2、归并冲突及办理方法

当两个分支都有各自的提交，而且修改了同一个文件的同一部分时，Git 在归并它们时就会碰到归并冲突（merge conflict）。简单来说，Git 无法自动判断以哪个分支的修改为准，必要人工介入决定。冲突最常发生于多人修改了相同代码的情形，或自己在不同分支对同一文件做了不同改动。
**冲突发生时的现象：**执行 git merge 后，终端会输出类似“Automatic merge failed; fix conflicts and commit the result.”的信息。这表示自动归并未能完成，必要手动办理冲突。此时，可以运行 git status 查看哪些文件存在冲突，输出中会列出冲突文件并标记为“both modified”。
办理归并冲突的一样平常步调：

• 定位冲突地区： 用文本编辑器打开存在冲突的文件。你会看到特殊的冲突标记。比方，假设 config.txt 文件在两个分支有冲突，打开后可能出现这样的内容：
        
  1. <<<<<<< HEAD
  2. timeout=30
  3. =======
  4. timeout=60
  5. >>>>>>> login-feature

  复制代码
     上述标记表示：HEAD（当前分支，即 main 分支）的内容是 timeout=30，而要归并进来的 login-feature 分支的内容是 timeout=60。冲突地区被 <<<<<<<、=======、>>>>>>> 分隔成两部分，开辟者必要决定哪一侧（或如何归并两者）才是精确的。
  
• 手动归并修改： 编辑冲突标记所在位置，根据必要保留或修改代码。比方，如果确定以 login-feature 分支的设置为准，就把 timeout=60 保留下来，删去其他冲突标记。如果两侧的修改都必要，可以手动归并成一个新的内容。总之，要编辑成我们想要的最终效果，并删除所有 <<<<<<, ======, >>>>>> 标记，使文件恢复正常的代码格式。
  
• 标记冲突已办理并暂存： 修改完所有冲突文件后，生存文件并退出编辑器。然后利用 git add <文件> 将刚刚办理冲突的文件添加到暂存区。标记为已办理意味着告诉 Git：“这文件的冲突我已经处置惩罚好了，可以纳入下一次提交”。
  
• 完成归并提交： 当所有冲突都办理并 git add 后，再次执行 git status 检查确认没有剩余未办理的冲突。接下来，运行 git commit 提交归并效果。值得留意的是，如果当前正处于归并过程，Git 在提交时会自动带上归并的默认提交信息（也可以自行编辑提交说明）。提交乐成后，归并冲突就算办理完成，堆栈汗青中会出现这次归并提交。
  

如果在处置惩罚冲突过程中发现归并的方向有误或者想放弃此次归并，可以利用：
  

1. git merge --abort

复制代码

该命令会中止归并操作，将分支恢复到归并开始前的状态，就像从未执行过归并一样。然后你可以重新尝试归并或者做其他处置惩罚。
   小提示：归并冲突固然听起来可骇，但有些图形化工具可以帮助办理。比方，利用 git mergetool 可以调起图形化冲突办理工具（如 KDiff3、P4Merge 等）对比冲突两边的差异，辅助你选择保留方案。另外，在团队协作中，淘汰冲突的最好办法是勤劳地沟通和同步：常常 git pull 同步他人修改，及时分享自己的改动。当冲突真的发生时，也只管和相干开辟者商量确认最终修改方案。
  3、利用 git stash
暂存变动

在日常开辟中，有时我们会碰到这样一种环境：正在一个分支上开辟新功能，代码写到一半，突然接到任务必要立刻切换到另一分支去修复紧急题目。但当前分支的修改尚未完成也不适合提交，这时该怎么办？直接切换分支会被 Git 拒绝（由于有未提交修改），把不完整的工作硬提交显然也不当当。git stash
就是为相识决这种场景而计划的。
git stash
命令可以将当前工作目录和暂存区的修改临时储藏起来，恢复到干净状态，好让你切换到别的分支去处置惩罚其他变乱。等必要恢复时，再将暂存的修改取出，继续先前的工作。git stash
类似于一个堆栈（stack），可以储存多组未完成的修改。
常用的 stash 操作为：

• 生存当前修改： 在有未提交改动的环境下运行：
        
  1. git stash

  复制代码
     这会把所有未提交的修改（包含已经 git add 暂存的僧人未暂存的）生存到一个匿名的储藏当中。Git 会输出类似 “Saved working directory and index state WIP on branchName...” 的信息，并将工作区恢复到最近一次提交的状态。你也可以加说明信息，比方 git stash
  save "message"，但较新的 Git 版本中直接 git stash
  也可以自动生存。
  
• 查看暂存列表： 可以运行：
        
  1. git stash
  2. list

  复制代码
     来查看所有储藏的记录。最新的储藏在最上面，每条记录都有一个索引（如 stash@{0}）和描述（包含当时所在的分支名和提交信息的摘要）。
  
• 恢复暂存的修改： 当你要继续之前的工作时，在相应的分支上运行：
        
  1. git stash
  2. pop

  复制代码
     这条命令会将最近一次生存的修改取出应用到当前工作目录，同时从储藏列表中移除该记录。如果你想应用但保留储藏记录，可以利用 git stash
  apply stash@{n}（其中 n 是编号）来应用某个特定储藏但不删除它。
  

举个例子：你在 feature-X 分支上开辟，写了一半代码。这时必要切换到 main 分支修复紧急 Bug。你可以执行 git stash
将 feature-X 的修改暂存起来，然后 git checkout main
切换分支（现在不会有未提交内容的拦阻）。修复完 Bug 并提交推送后，回到 feature-X 分支，用 git stash
pop 将之前的工作恢复出来，继续完成剩下的开辟。整个过程就像把工作“按停息”，处置惩罚完其他事情后再“恢复播放”。
git stash
非常适合处置惩罚工作停止、上下文切换的场景。必要留意的是，stash 默认会储存未提交的所有内容（包括已暂存和未暂存的部分）。如果你只想暂存尚未暂存的修改而保留已暂存部分，可以利用 git stash
-k (keep index)。另外，git stash
也能暂存新建但未追踪的文件（加 -u 参数），不外初学者一开始用默认行为即可。
末了，当某个储藏的修改不再必要时，可以用 git stash
drop stash@{n} 删除，或者 git stash
clear 清空所有暂存记录。合理地利用 stash，可以帮助你保持堆栈提交汗青的整齐，不会由于临时切换任务而随处留下琐屑的“WIP”提交。
4、git reset 与 git revert 的区别

在利用 Git 的过程中，难免会碰到必要“撤销”更改的时候。Git 提供了多个命令来撤销或回退提交，其中最常见的是 git reset 和 git revert。它们都能达到“让项目回到之前状态”的目的，但原理和利用场景有所不同。理解两者区别有助于我们在不同环境下选择精确的方法去撤销修改。
4.1、git reset —— 重置提交汗青

git reset 通常用于“回退”本地堆栈的HEAD到某个旧的提交。通过 reset，我们可以舍弃最近的一些提交，使堆栈退回到指定的汗青节点。根据参数不同，git reset 既可以影响提交汗青，也可以影响暂存区和工作区。
git reset [模式] <提交> 其中常用的模式有三种：

• --mixed（默认模式）：重置 HEAD 到指定提交，同时保留工作区改动但清除暂存区。简言之，就是把选定提交之后的修改全部撤出提交汗青，放回工作区未暂存的状态。
  
• --soft：更温和的重置，只重置 HEAD 提交，暂存区和工作区都保留这些改动。也就是说撤销最近的提交，但改动仍然保持在暂存区，几乎相当于把提交“取消”回暂存状态。
  
• --hard：强制重置，提交汗青、暂存区和工作区都同步到指定提交的状态。所有在那个提交之后的改动都会被彻底抛弃，从当前目录中消散（无法通过 Git 恢复）。
  

一个常见的用法是撤销最近一次提交。比方你发现刚才的提交有题目，不想要了，可以利用：
  

1. git reset HEAD~1

复制代码

这条命令将堆栈重置到上一个提交（即舍弃了最新提交）。默认模式下（mixed），最新提交的更改内容会留在工作区，这样你可以修改后重新提交，或者也可以放弃掉。相当于“退一步，但保留现场改动，允许你修正后再提交”。
如果你完全确定最近的提交是错误的且不必要其中的改动，可以用：
  

1. git reset --hard HEAD~1

复制代码

告诫：--hard 非常伤害，它会抹掉工作区中自上一个提交以来的所有改动！除非你在其他地方另有这些改动的备份，否则此操作不可逆。因此务必审慎利用。
git reset 更多地被视为一种本地操作，计划用于调整尚未公开（push）的汗青。比方，你提交了一些临时代码想回退，或者想将上一个 commit 拆分/归并，这些都可以通过 reset 在本地实现，然后重新整理 commit，再推送。但是如果你已经把提交推送到远程堆栈，其他人也基于它睁开了工作，贸然 reset 自己的分支并强制推送（force push）会导致团队其他人的堆栈汗青不一致。因此，git reset 一样平常不应用于已发布到公用堆栈的提交。
除了回退整个提交，git reset 还可以用于取消暂存（unstage）。好比不小心 git add 了不想提交的文件，可以用 git reset HEAD <文件> 将其从暂存区移除，回到未暂存状态。
4.2、git revert —— 还原提交

与 reset 不同，git revert 是通过创建一个新的提交来抵消某个汗青提交的影响，从而达到“撤销更改”的目的。git revert <提交> 会根据指定的提交，产生一个内容相反的新提交，应用这个新提交后，堆栈状态看起来就像撤回了指定的提交一样。但是，原先的提交记录依然保留在汗青中，只是反面附加了一个“反向提交”来消除它的效果。
git revert 常用于已经推送到远程堆栈并分享给他人的提交的撤销。由于 revert 不会重写汗青，它是往汗青里添加记录，以是对团队其他成员不会产生粉碎性的影响。实际上，revert 后大家同步代码时，会拿到一个新的提交，该提交做了撤销更改的操作。
举例来说，如果在主分支有一个错误的提交 C 已经推送，现在想撤销它。如果用 reset，我们必须强制修改汗青，会给协作者带来困扰；但利用 revert：
  

1. git revert <提交C的哈希>

复制代码

Git 会自动创建一个新提交 C'（内容为将提交 C 引入的改动反向修改归去），提交消息会注明它是一次 revert。比方 “Revert "添加XX功能"”。推送这个新提交后，其他人拉取更新，他们的堆栈会保留提交 C 和 C' 两条记录，但最终文件内容与 C 未发生前一致了。
git revert 的语法通常是指定具体的提交哈希，也可以利用诸如 HEAD、HEAD~2 这类引用来表示相对位置。还可以一连 revert 多个提交（必要逐个执行或利用...范围）。必要留意，如果要 revert 的提交不是最新的，或者涉及文件改动与后续提交有重叠，可能也会出现冲突，处置惩罚方式和归并冲突类似：修改冲突文件然后继续 git revert --continue 完成操作（revert 一个提交序列的环境）。
小结比较：git revert 和 git reset 的根本区别在于是否保留汗青。git revert 是用一次新的 commit 往返滚之前的 commit，而 git reset 是直接删除指定的 commit 。换句话说：

• 利用 git reset，堆栈会“抛弃”某段汗青，就好像那些提交从未发生过。而利用 git revert，堆栈汗青会完整保留每一次改变，只是附加记录某次改动被撤销了。
  
• git reset 改变了当前分支的 commit 链（HEAD 向后移动），而 git revert 则让 HEAD 继续前进，只是新增的那个提交的内容与被还原的提交相反，从效果上抵消了它 。
  
• 从协作角度，reset 要求所有协作者都共同修改汗青（否则会出现分歧），而 revert 则是一个正常的提交，其他人只需拉取即可。因此，撤销公开辟布的提交建议利用 git revert ；仅在本地调整尚未发布的提交时可以利用 git reset。
  

利用场景建议：

• 当你提交后立刻发现错误，且该提交尚未推送，想彻底抹除这次错误提交，可以考虑 git reset 将 HEAD 回退（或者用 git commit --amend 更正提交，这也是改汗青的方法之一）。但如果该提交已经分享出去，不要用 reset 撤销。
  
• 当某次提交已经推送并被他人拉取，如果后来证实必要撤销，就用 git revert 来安全地回滚。这样所有人的汗青都会保持一致，只是多了一条修正记录。
  
• 如果必要清除多个无用的提交（好比试验性子的提交），而这些提交尚未推送，可以用 git reset 一次性回退。不外Git另有更高级的工具如交互式 rebase 可以用于整理多个提交（见下一节）。
  

   总之，谨记：不要在公共堆栈的分支上利用 git reset --hard 等粉碎性命令；撤销公开提交请选择 git revert。两者各有效途：reset 修剪汗青，revert 保持汗青一连性地举行撤销。
  5、利用 git rebase 优化提交汗青

在多人协作和长期开辟的项目中，提交汗青很容易变得复杂。频仍的归并会产生很多分支交叉点和归并提交，而且每个人的提交粒度和风格也不尽相同。Git 提供的 git rebase 命令可以在一定程度上优化和整理提交汗青，使之更加线性和轻便。不外，rebase 修改汗青的特性也必要我们小心利用。
5.1、变基（Rebase）简介

git rebase 的直译是“变基”。它的作用是改变提交的基底。具体来说，就是将一系列提交“剪下来”，然后重新应用（Replay）在另一位置。效果就是提交汗青发生了重排或重构。在实际操作中，rebase 常用于两种环境：

• 在分支归并前，更新分支以基于最新的主分支： 假设我们有一个功能分支 feature 从主分支 main 分出。一段时间后，main 上有了新的提交，而 feature 也有自己的提交。这时，我们可以在将 feature 归并回 main 之前，先切到 feature 分支执行 git rebase main。这会把 feature 分支上的提交转移到 main 分支最新提交之后，仿佛 feature 是从当前最新的 main 开始开辟的一样。这样处置惩罚后，当我们再归并 feature 到 main 时，可以避免产生额外的归并提交，使汗青出现为一条直线。
  比方：最初 main 有 A 提交，feature 分支从 A 分出做了提交 B；期间 main 上又有了提交 C。此时 feature 分支执行 git rebase main 后，feature 上的 B 提交会被移到 C 的反面，形成一个新的提交 B'。现在 main 的汗青是 A - C，feature 的汗青是 A - C - B'。随后如果 fast-forward 归并，主分支将线性包含 A - C - B'，看起来就像 B'是在 C 之后提交的一样，消除了分叉记录。
  Rebase 后由于提交被重新应用，其 SHA-1 哈希值会发生变革（B 变成 B'），以是这个过程重写了分支的汗青。Git 会逐个应用 feature 分支的每个 commit，因此如果这些提交与 main 的更改有冲突，会停息并要求办理冲突（类似前面归并冲突的过程，但命令变为 git rebase --continue 继续下一个，或者 git rebase --abort 放弃变基）。
  
• 整理本地的多次碎片提交： 在开辟一个功能时，可能我们会举行很多次临时的提交（好比调试信息、实验尝试等）。在提交到主分支前，团队往往希望这些汗青被整理得整齐一些，比方归并相干的改动、编辑规范提交消息等。git rebase -i（交互式变基）可以帮助实现这一点。通过交互式 rebase，我们可以选择**压缩（squash）**多个提交为一个、修改（edit）某些提交的内容或消息、乃至改变提交顺序等。
  比方，假设我们在当前分支有最近的5个提交必要整理，只需执行：
        
  1. git rebase -i HEAD~5

  复制代码
     Git 会打开一个文本界面，列出这5个提交以及可选的操作（pick, squash, edit 等）。根据必要编辑生存后，Git 就会按照新的指令重新依次应用这5个提交（期间如果有冲突需办理）。整理完成后，分支汗青就被改写成了我们想要的样子。常用的操作包括将多次“小提交”归并成一次有意义的大提交（squash），或修改提交信息（reword/edit）以更清晰地描述改动。
  

rebase vs merge： Rebase 和 Merge 是实现分支集成的两种方式，各有优劣。Merge保留了完整的汗青轨迹（包括分叉点和归并节点），能看出代码是如安在分支上演进再合流的；而Rebase则让汗青看上去像一条直线，没有分叉（就像所有改动都串行发生在一个分支上）。Rebase后的汗青往往更加轻便、线性，利用 git log 浏览时不会被大量的归并提交干扰。但另一方面，Merge不改变已有汗青，而Rebase通过重写汗青来达成线性，可能会让汗青记录失去分支上下文。
**利用留意：由于 rebase 会重写提交汗青，以是有一个“变基黄金法则”**必须牢记：绝不要在公共分支上对已经推送的提交执行 rebase 。换句话说，仅对尚未分享给别人的本地分支利用 rebase。一旦你在协作的分支（好比 origin/main 或团队共享的feature分支）上做了变基，然后强制推送，会导致他人的堆栈出现冲突和混乱（由于他们的提交汗青与你的不一致）。因此，在共享环境下，rebase 只能用于更新自己本地的开辟分支，再正常推送，或用于自己fork后在PR归并前整理提交。遵循“变基黄金法则”：绝不在公有堆栈的分支上执行 rebase。
5.2、举例：利用 rebase 更新分支

假设你正在开辟分支 feature-A 上工作，此时必要同步主分支 main 最新的更新。在 merge 和 rebase 两种做法中，如果选择 rebase：
  

1. # 确保主分支是最新的git checkout main
2. git pull origin main# 切回功能分支，执行变基git checkout feature-Agit rebase main

复制代码

执行上述操作后，Git 会将 feature-A 分支上的提交一个接一个地转移到 main最新提交之后。如果没有冲突，变基会自动完成。如有冲突，Git 会制止并让你办理冲突，办理完毕后用 git add 将更改暂存，然后 git rebase --continue 继续剩下的提交。全部竣事后，切换到 main，可以利用 git merge feature-A 快速归并（fast-forward）或者直接 git push origin feature-A:main 推送 feature-A 分支作为 main 分支的新更新（好比在pull request被担当时）。这样 main 的汗青就是线性的，没有额外的分叉点。相比直接 merge，这种方法避免了归并提交，使汗青更干净。
5.3、举例：交互式 rebase 整理提交

如果在开辟一个功能过程中，你做了3次提交：第一次提交遗漏了一些文件，第二次补上遗漏，第三次修正了前面提交信息的一个拼写错误。最终这些其实都是为实现同一个功能，理想环境下可以归并成一个提交。利用 git rebase -i 可以实现：
  

1. git rebase -i HEAD~3

复制代码

在打开的编辑界面中，你会看到类似：
  

1. pick f1a2b3c Implement feature X
2. pick a3d4e5f Add missing files for feature X
3. pick b4c6d7e Fix typo in feature X description

复制代码

将后两行的 pick 改为 squash（或缩写 s），表示将它们压缩到第一个提交中。生存退出后，Git 会应用第一个提交，然后将后两个提交的改动归并进第一个。在这个过程中会让你编辑归并后的提交消息，你可以整合原先三个提交的信息为一条完整描述。完成后，汗青中就只剩下一条提交，包含所有改动。这就是一次提交压缩操作。类似地，你可以重新排序提交顺序（调整行的先后）、抛弃某些提交（改为 drop），或者标记 edit 手动修改某个提交的内容（在 rebase 过程中停息让你修正然后继续），等等。
通过 rebase 的这些本领，我们能够在不影响最终代码效果的环境下，让提交汗青更符合阅读和维护的必要。比方，将“修复拼写错误”“调整格式”这类杂碎 commit 归并到主要 commit 中，保持主干汗青的清晰。固然，这种修改汗青的动作只应对自己本地分支举行，在与团队协作前完成整理。
6、保举的 Git 利用流程与团队协作本领

掌握了上述 Git 高级功能后，我们来讨论一下在团队协作中，如何高效地利用 Git 工作，以及一些值得遵循的实践规范。精良的协作流程可以避免很多题目，确保团队所有成员各司其职又步调一致。
下面是一套常见的 Git 团队协作开辟流程（以功能开辟为例）：

• 同步主分支： 在开始新的工作之前，先切换到主分支（比方 main 或 develop），执行 git pull 拉取远程最新代码。这样可以确保你的主分支是最新状态，为后续创建新分支打好基础。
  
• 新立功能分支： 从主分支创建一个新的功能分支用于开辟你的任务：
        
  1. git checkout -b feature/some-feature

  复制代码
     分支定名应清晰反映工作内容，好比 feature/login-auth 或 bugfix/issue-101。在这个分支上举行你的开辟工作，与此同时主分支的代码保持不变。
  
• 在分支上举行开辟并频仍提交： 在功能分支上编写代码。建议遵循“早提交、勤提交”的原则，每实现一个独立的小功能或达到一个里程碑就利用 git add 和 git commit 提交一次。提交信息要清晰描述修改目的，比方 “Add login form UI” 而不是 “update code”。频仍提交有助于记录开辟轨迹，也使得出现题目时更容易定位和回溯。
  
• 将分支推送到远程： 固然还在开辟中，但也最好常常将本地分支推送到远程堆栈备份，并让团队可见你的进展：
        
  1. git push -u origin feature/some-feature

  复制代码
     利用 -u 将本地分支与远程同名分支创建跟踪关系。之后如果继续有新的提交，可定期 git push 更新远程。这样纵然你的电脑发生故障，代码也不会丢失，同时同事也能看到并拉取你的最新代码（如果必要协作）。
  
• 与主分支保持同步： 开辟过程中，主分支可能也在推进其他更新。为避免分支长期偏离主线，最好定期用主分支的变革更新你的功能分支。比方可以执行 git pull origin main（或 git fetch 然后在分支上 git merge origin/main）将主分支的修改归并过来。如果希望更整齐，可以用 git rebase origin/main 将你的提交变基到主分支后。这能淘汰最终归并时的冲突概率。
  
• 提交归并请求（Pull Request）并代码查察： 功能开辟完成并颠末自测后，将你的分支代码归并回主分支。通常做法是在托管平台上创建一个 Pull Request（归并请求），描述你的更改，通知团队其他成员审核代码。代码查察（Code Review）可以发现潜在题目并确保代码质量。在 PR 通事后，维护者会将你的功能分支归并到主分支。归并可以采用 Squash Merge（压缩成一次提交）或者普通 Merge，根据团队约定。
  
• 清算分支并摆设： 功能乐成归并进主分支后，可以删除远程和本地的功能分支（以避免过多分支混乱堆栈）：
        
  1. git branch -d feature/some-feature        # 删除本地分支
  2. git push origin --delete feature/some-feature  # 删除远程分支

  复制代码
     之后，在本地切回主分支并 git pull 获取最新的代码。如果必要摆设或发布，可以根据主分支最新代码举行。
  

在上述流程中，有一些值得夸大的团队协作本领和最佳实践：

• 确保主分支始终可用： 主分支（如 main/master）通常代表产品的稳固版本。不在主分支上直接开辟新功能，所有对主分支的修改都通过分支归并来完成。这样主分支上的代码始终是可以随时发布或摆设的。如果必要紧急修复，也利用热修复分支来完成并尽快归并。
  
• 善用分支定名和标签： 清晰的分支定名有助于协作。比方见到 feature/login-auth 自然知道是开辟登录认证功能。对于重要的里程碑或发布版本，利用 Git 标签（tag）来标记提交，方便以后查找对应版本的代码。
  
• 编写有意义的提交消息： 一个好的提交消息能够轻便概括更改内容或原因，方便日后查阅汗青时相识每次改动的目的。避免利用含糊不清的描述如“修改代码”“更新了几个文件”。常见格式是在简短的标题后可选地补充细节描述，团队可以采用一致的 commit message 风格（好比遵循 Angular 提交信息规范等）。
  
• 及时拉取和归并： 团队协作中，每个人应常常同步远程堆栈的最新变革（git pull），特殊是在开始新的任务或准备将自己的修改推送前。这可以最大限度淘汰冲突。当发现与他人有冲突时，积极沟通，共同决定如何办理。
  
• 不要在公共分支上强制推送： 避免利用 git push --force 强制推送主分支或他人也在用的分支。如果必须（比方更正错误的汗青），也要提前与团队说明，确保别人没有基于旧汗青继续工作。强制推送可能覆盖他人的提交，通常只有堆栈管理员在特殊环境下才执行，而且通常通过 Pull Request 来协同完成。
  
• 利用 .gitignore 保持堆栈整齐： 在协作项目中，订定 .gitignore 文件很重要，确保编译产物、临时文件、不必要纳入版本控制的文件不被提交。比方日志文件、IDE配置、依赖天生的文件等应被忽略。这可以淘汰不必要的冲突和堆栈臃肿。
  
• 定期备份和维护堆栈： 固然远程堆栈自己就是备份，但也可以克隆镜像堆栈作为额外备份。对长期项目，定期清算无用的分支，避免堆栈中累积过多逾期分支。对于超大的汗青（好比大量二进制文件不测提交），可以考虑利用 Git 工具（如 BFG Repo-Cleaner）清算，但这些都是进阶话题了。
  

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。