Git工作流 | 青训营

翼同学
267 阅读27分钟

【学习资料 | 原文】：Comparing Git Workflows

📝 前言

当谈论Git工作流时，我们指的是在团队中协同开发代码时使用的一系列规则和流程。不同的工作流适用于不同的团队和项目，取决于项目的规模、复杂性以及团队的需求。

工作流不仅仅关乎版本控制工具的使用，更关乎整个项目的流程管理和开发协同约定。有效的工作流可以极大地影响团队的开发效率、代码质量以及协作能力。

📖 内容

📂 Centralized Workflow

集中式工作流是Git工作流中最简单的一种，特别适用于那些熟悉Subversion（SVN）或其他集中式版本控制系统的开发团队。它的基本思想是在一个主分支（通常是master或main分支）上进行开发，类似于传统的集中式版本控制系统。

工作方式

  1. 单一主分支（主干）： 在集中式工作流中，只存在一个主分支（通常是master或main分支）。所有的开发工作都在这个主分支上进行。
  2. 克隆代码库： 开发者首先会从中央代码库克隆（或者拉取）最新的代码到本地仓库。
  3. 开发工作： 开发者在本地仓库中进行自己的开发工作，包括添加新特性、修复bug等。
  4. 提交更改： 开发者将他们的更改提交到本地仓库的主分支。
  5. 获取更新： 在提交自己的更改之前，开发者通常会先获取远程主分支的最新更新，确保自己的代码是基于最新代码进行开发的。
  6. 解决冲突： 如果有多个开发者同时修改了同一部分的代码，就可能会产生冲突。在集中式工作流中，冲突通常在本地解决，然后再提交到主分支。
  7. 合并到主分支： 开发者的更改经过测试并且没有冲突后，会将这些更改合并到主分支中。
  8. 发布版本： 当开发达到某个里程碑或版本号时，团队可以选择发布一个新的版本。这通常涉及将主分支的特定状态标记为一个版本，并且可以创建一个标签（tag）来标识这个版本。

优势

使用 Git 的集中式工作流优势在于：

  1. 每个开发者拥有本地拷贝： 每个开发者都可以在自己的本地环境中拥有整个工程的拷贝，这种隔离的环境使得各个开发者的工作与其他部分的修改独立开来。
  2. 自由提交到本地仓库： 开发者可以自由地提交修改到自己的本地仓库，而不需要立即考虑上游的开发。这意味着开发者可以在自己的本地环境中先进行一些实验性的修改，然后在方便的时候再将这些修改反馈到主仓库。
  3. 强大的分支和合并模型： Git提供了强大的分支和合并模型，使得创建、管理和合并分支变得更加容易。这是相对于集中式版本控制系统的一个显著优势。

冲突解决

在集中式工作流中，中央仓库通常代表了正式项目的状态，而提交历史的稳定性和一致性对于团队的协作和版本管理至关重要。在Git中，确保本地的提交历史与中央仓库保持一致的操作是通过分支合并和推送的方式来实现的。

具体来说，如果开发者在本地进行了修改并提交了一些更改，想要将这些更改推送到中央仓库（例如master分支），Git会执行以下操作：

  1. 获取远程更新： 开发者在推送之前，首先应该获取中央仓库的最新更新。这可以通过执行git pull origin master命令来实现，其中origin是远程仓库的名称，master是主分支的名称。
  2. 合并本地修改： 如果从中央仓库拉取更新后，发现本地提交历史和中央仓库有了分歧，Git会尝试自动合并这些更改。如果合并过程中出现冲突，开发者需要手动解决冲突，并进行提交。
  3. 推送到中央仓库： 一旦本地的提交历史和中央仓库保持一致，开发者可以执行git push origin master命令将本地的更改推送到中央仓库的master分支。如果推送成功，中央仓库的历史将会更新。
  4. 防止覆盖稳定提交： 如果在推送的过程中，发现本地的提交历史会覆盖中央仓库中的稳定提交，Git会拒绝推送。这是为了确保中央仓库的提交历史保持稳定和一致。

示例

让我们一起逐步分解，来看看一个常见的小团队如何用这个集中式工作流来协作的。

小明开发功能

小明使用标准的Git过程开发功能，包括编辑、暂存和提交。他可以使用以下命令进行操作：

  • git status：查看本地仓库的修改状态。
  • git add：将文件暂存，准备提交。
  • git commit：提交暂存的文件。

这些本地提交可以根据需要多次操作，而不影响中央仓库的操作。

central-01.png

小红开发功能

与小明类似，小红也在她的本地仓库中使用相同的编辑、暂存和提交过程来开发功能。她同样不需要担心中央仓库的新提交情况，也不需要关注小明在他的本地仓库中的操作。每个本地仓库都是私有的，因此她的操作不会影响其他人，包括小明。

central-02.png

小明发布功能

一旦小明完成了他的功能开发，他可以将他的本地提交发布到中央仓库，以便其他团队成员可以看到他的修改。他可以使用以下命令进行推送：

git push

注意，这里省略了远程仓库别名和推送分支两个参数。在主流的Git版本中，这两个参数的默认值分别为 origin 和当前分支（通常是 master）。这样的用法更加简单和自然。

由于从小明克隆仓库以来，中央仓库还没有被更新过，所以推送操作不会有冲突，能够成功完成。

central-03.png

小红试着发布功能

在小明发布修改后，如果小红尝试使用相同的 git push 命令来推送她的修改，情况如下：

她的本地提交历史与中央仓库的提交历史已经产生了分岐。这会导致Git拒绝推送操作，并显示类似以下的错误消息：

error: failed to push some refs to '/path/to/repo.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Merge the remote changes (e.g. 'git pull')
hint: before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

这个错误提示表明，小红的当前分支在远程分支之后。

为了解决这个问题，她需要先将小明的更新（也就是中央仓库的更新）拉取到她的本地仓库，合并到她的本地修改后，然后才能再次尝试推送。

central-04.png

小红在小明的提交之上 rebase

小红使用了 git pull --rebase 命令来合并上游的修改到她的本地仓库中。

git pull --rebase

这条命令的作用类似于 SVN 中的 svn update 命令，它会拉取所有上游的提交到小红的本地仓库，并尝试将这些修改与她本地的修改合并。

central-05.png

在这里，--rebase 选项告诉Git将小红的提交移动到已同步了中央仓库修改后的 master 分支的顶部。如果忘记加上这个选项，pull 操作仍然能够完成，但每次执行 pull 操作以同步中央仓库的他人修改时，提交历史会在末尾生成一个多余的"合并提交"。对于集中式工作流，推荐使用 rebase 而不是生成额外的合并提交，以保持提交历史的整洁性。

central-06.png

小红解决合并冲突

rebase 操作的过程是逐个将本地提交迁移到已更新的中央仓库 master 分支之上。这意味着可能需要解决在迁移某个提交时出现的合并冲突，而不是解决包含了所有提交的大型合并时的冲突。这种方式有助于保持每个提交的聚焦，以及项目历史的整洁性。这样做还简化了在代码中定位引入Bug的地方，如果需要，回滚修改也可以最小化对项目的影响。

如果小红和小明的功能开发是不相关的，那么在 rebase 过程中可能不太可能出现冲突。然而，如果出现冲突，Git会在有冲突的提交处暂停 rebase 过程，并输出类似以下的信息，同时附带相关的指令：

CONFLICT (content): Merge conflict in <some-file>

这时就需要解决冲突，使得两个不同的修改能够协调一致地合并在一起。

central-07.png

Git非常强大的一点是，任何人都可以解决自己的冲突。在这个例子中，小红可以通过运行 git status 命令来查看哪里出现了冲突。冲突文件会列在 "Unmerged paths"（未合并路径）一节中，类似于以下的显示：

# Unmerged paths:
# (use "git reset HEAD <some-file>..." to unstage)
# (use "git add/rm <some-file>..." as appropriate to mark resolution)
#
# both modified: <some-file>

接下来，小红可以编辑这些冲突文件。修改完成后，她可以使用常规的方式将这些文件暂存，然后使用 git rebase --continue 让 Git 完成剩下的合并过程：

git add <some-file>
git rebase --continue

这就完成了。Git会继续一个一个地合并后面的提交，如果其他提交也存在冲突，只需重复这个过程。

如果在解决冲突时发现难以处理，不要惊慌。只需执行以下命令，就可以回到执行 git pull --rebase 命令之前的状态：

git rebase --abort

小红成功发布功能

在小红完成与中央仓库的同步后，她就可以成功地将她的修改发布出去：

git push

这样，小红的修改将被推送到中央仓库中供其他团队成员查看和使用。

central-08.png

📂 Feature Branch Workflow

功能分支工作流是在集中式工作流基础上的一种演变，它强调了更好的代码隔离和协作。在功能分支工作流中，每个新功能都有一个专门的分支，这种分支被称为“功能分支”。这些功能分支独立于主分支（通常是master或main分支），并且可以在开发、测试和审查阶段进行单独管理。

工作方式

  1. 中央仓库和主分支： 仍然存在一个中央仓库，其中的 master 分支代表了正式项目的历史。这是所有开发者共同的代码库，master 分支的内容应该保持稳定和可部署。
  2. 功能分支的创建： 在开始新的功能开发前，开发者会创建一个新的功能分支。这个分支会有一个描述性的名称，以清楚地表达该分支的目的，比如修复某个问题、添加某个功能等。
  3. 独立的修改空间： 功能分支和 master 分支之间没有技术上的区别，但是它们提供了独立的修改空间。开发者可以在功能分支上进行编辑、暂存和提交修改，而不会影响主分支中的代码。
  4. 功能分支的共享： 功能分支也可以推送到中央仓库，这样其他开发者就可以查看、合并和测试这些功能分支的修改，而不会影响主分支。这种方式可以实现在不影响正式代码的情况下，进行代码的分享与合作。
  5. 分支的并行存在： 因为 master 分支是唯一的“特殊”分支，所以在中央仓库上同时存在多个功能分支是完全可行的。这有助于更好地管理并行开发和备份本地提交。

Pull Requests

功能分支工作流结合了Pull Requests来促进代码审查和讨论。具体如下：

  1. 功能开发分支： 开发人员从 master 分支创建一个新的功能分支，例如 feature/animated-menu-items。在这个分支上开发新的功能或修复问题。
  2. Pull Request (PR) 创建： 一旦开发人员完成了功能的开发，他们将代码推送到中央仓库中的相应功能分支，并发起一个 Pull Request 到 master 分支。这允许其他团队成员对代码进行审查、讨论和提供反馈。
  3. 代码审查和讨论： 其他团队成员或相关人员可以查看 Pull Request，进行代码审查、讨论和提出建议。这有助于捕捉潜在问题、提出改进意见，并确保代码质量。
  4. 持续改进： 开发者根据代码审查的反馈进行适当的更改和修复。这个循环可能会重复多次，以确保代码质量和最佳实践。
  5. Pull Request 接受： 一旦代码审查满意，Pull Request 可以被接受。在这一步，功能分支的代码会被合并到 master 分支中。
  6. 同步本地 master 分支： 开发者本地的 master 分支可能需要更新，以包含刚刚合并的功能。可以使用 git pull origin master 来同步本地分支。
  7. 推送本地更改： 开发者将更新后的 master 分支推送到中央仓库，以确保其他团队成员也能获取最新的主分支代码。

这种流程可以促进团队合作、提高代码质量，并使团队成员能够更紧密地协作。同时，它也提供了一个透明的方式来跟踪每个功能的开发进度，从而使整个项目的管理更加有序。

示例

下面的示例演示了如何把Pull Requests作为Code Review的方式，但注意Pull Requests可以用于很多其它的目的。

小红开始开发一个新功能

在开始进行功能开发前，小红需要一个独立的分支。她可以使用以下命令来新建一个分支：

git checkout -b marys-feature

在这个命令中，使用了 -b 选项表示如果指定的分支还不存在，则新建一个名为 marys-feature 的分支。在这个新分支上，小红按照之前的步骤进行编辑、暂存和提交修改，根据需要提交来实现功能：

git status
git add <some-file>
git commit

小红可以根据需要提交多次，以逐步完成她的功能开发。这样的方式可以确保她的修改不会直接影响到主分支（通常是 master 分支），并且允许她独立地进行功能开发。

branch-01.png

小红要去吃个午饭

早上，小红为新功能添加了一些提交。在去吃午饭前，将功能分支推送到中央仓库是一个不错的做法，这样可以方便地备份代码，并且如果需要与其他开发人员协作，他们也可以看到小红的提交。

她使用以下命令将 marys-feature 分支推送到中央仓库（origin）：

git push -u origin marys-feature

在这条命令中，-u 选项用于设置本地分支跟踪远程对应的分支。设置好跟踪分支后，小红就可以在以后的推送中省略指定推送的分支参数。这样，她只需使用 git push 命令即可将修改推送到中央仓库。

branch-02.png

小红完成功能开发

午饭后，小红回来后完成了整个功能的开发。在将修改合并到 master 分支之前，她想发起一个 Pull Request，以通知团队其他成员功能已经完成。然而，在发起 Pull Request 之前，她需要确认中央仓库中已经包含了她最近的提交：

git push

然后，她可以使用她的 Git GUI 客户端，在客户端中发起 Pull Request，请求将 marys-feature 分支合并到 master 分支。团队的其他成员会自动收到通知。Pull Request 的一个很酷的功能是可以在相关的提交旁边显示评论，这样可以方便地对某个变更集进行提问或讨论。这样的方式帮助团队更好地协作和审查代码。

branch-03.png

小明收到 Pull Request

当小黑收到 Pull Request 后，他会查看 marys-feature 分支的修改。然后，他可以决定在将这些修改合并到正式项目之前是否需要进行一些修改。在这个过程中，小黑和小红可以通过 Pull Request 进行来回的讨论，以确保对于修改的理解和意图是一致的。这种讨论可以在 Pull Request 页面上进行，他们可以在每个提交旁边添加评论，提出问题、建议或者进行技术讨论。

这样的讨论和审查过程有助于确保代码质量、功能完整性以及团队协作的顺畅。小黑可以根据讨论的结果，对提交的修改进行适当的调整，然后将修改合并到 master 分支，以完成整个功能的集成。

branch-04.png

小红再做修改

如果小红需要再次进行修改，她可以使用与第一个迭代相同的过程：编辑、暂存、提交，然后将更新推送到中央仓库。所有这些活动都将在 Pull Request 上显示，允许小黑进行逐步的评注和审查。

如果小黑认为有必要，他还可以将 marys-feature 分支拉取到本地，进行自己的修改。这些额外的提交也会显示在 Pull Request 页面上，确保整个讨论和修改过程的透明度。这种方式允许团队成员之间的紧密协作，以确保最终的修改达到高质量并符合团队的期望。

branch-05.png

小红发布她的功能

branch-06.png

一旦小黑可以接受 Pull Request，就可以将功能合并到稳定项目代码中。这个操作可以由小黑或小红来执行。下面是一个可能的合并过程：

首先，执行以下命令：

git checkout master
git pull
git pull origin marys-feature
git push

在这个过程中，首先切换到 master 分支并确保它是最新的。然后，通过执行 git pull origin marys-feature 将 marys-feature 分支的修改合并到本地的 master 分支。最后，通过 git push 将更新后的 master 分支推送回中央仓库。

上述过程通常会生成一个合并提交。有些开发者喜欢保留这个合并提交，因为它可以作为新功能与原始代码基线的连接点。但如果你更偏爱线性的提交历史，可以在合并时使用 rebase 将新功能分支 marys-feature 的修改移动到 master 分支的顶部，以实现快进（fast-forward）合并。

一些 GUI 客户端可以通过点击一个“接受”按钮来自动执行上述命令，以自动化 Pull Request 的接受过程。即使不自动执行命令，至少在功能合并到 master 分支后，GUI 客户端可以自动关闭相应的 Pull Request。

📂 Gitflow Workflow

Gitflow工作流是一个在Git中广泛使用的强大工作流模型，特别适合于需要严格分支管理和发布流程的项目。它引入了不同类型的分支，从而更好地管理功能开发、版本发布以及维护修复。

Gitflow工作流是一种在软件开发中使用的版本控制工作流程模型，旨在帮助团队更有效地协同开发和管理代码。它是基于Git版本控制系统的分支管理策略，并由Vincent Driessen于2010年提出。Gitflow工作流的核心思想是将开发过程分解为不同的分支，以便更好地管理特性开发、bug修复和发布等任务。

工作方式

Gitflow工作流仍然基于中央仓库的概念，所有开发者在本地进行开发，然后将他们的更改推送到中央仓库以进行协同合作。

主要分支

Gitflow工作流通过使用两个主要分支，即master和develop，来更好地管理项目的历史和功能集成。这种分支结构有助于将不同类型的工作隔离开来，同时也提供了更好的版本控制和管理。

gitflow-01.png

  1. master分支： master分支是稳定的、正式发布的分支。它存储了项目的历史发布版本，每次发布一个新版本时，将相应的更改合并到master分支。这使得master分支成为一个可靠的代码基础，可以随时用于生产环境部署。
  2. develop分支： develop分支是功能的集成分支，也可以称为开发主干。所有开发者的特性分支都合并到develop分支，以便在一个共同的代码库中集成各种特性和改进。这有助于确保代码的一致性和集成，同时避免了在主分支上进行实验性的开发。

功能分支

在Gitflow工作流中，每个新功能都位于自己的特性分支，并且这些特性分支是从develop分支而不是master分支上拉出来的。这种方式确保了develop分支作为功能的集成分支，同时master分支保持稳定和只包含已发布的代码。

gitflow-02.png

功能分支的使用步骤大致为：

  1. 创建特性分支： 每当要开发一个新的功能，开发者从develop分支创建一个新的特性分支，例如feature/new-feature。在这个特性分支上进行功能开发工作。
  2. 本地提交： 开发者在特性分支上进行代码修改，然后将这些修改提交到本地仓库。
  3. 推送到中央仓库： 开发者可以将特性分支推送到中央仓库，以便备份和协作。这让其他团队成员能够查看和合并特性分支上的更改。
  4. 完成特性开发： 一旦特性开发完成，开发者可以将特性分支合并回develop分支。
  5. 合并请求： 在合并特性分支回develop分支之前，可以创建一个合并请求（Pull Request）以便其他团队成员进行代码审查。
  6. 合并到develop分支： 经过审查后，特性分支将被合并回develop分支。这将把新功能集成到主要开发线中。

通过这种方法，develop分支充当了功能集成的主干，所有新功能都经过严格的测试和审查，确保它们能够良好地与其他功能协同工作。而master分支则仅包含已经经过稳定性验证的版本，用于生产环境部署。

发布分支

gitflow-03.png

主要步骤：

  1. 创建发布分支： 当开发进展到一定程度，或者接近预定的发布日期时，从develop分支上创建一个新的发布分支，例如release/1.0.0。
  2. 发布准备工作： 在发布分支上进行一些准备工作，例如版本号更新、文档生成、Bug修复等。这个分支专注于准备发布所需的任务。
  3. Bug修复和文档生成： 在发布分支上，可以进行与发布相关的Bug修复、文档生成等任务，以确保发布版本的质量。
  4. 合并回develop分支： 在发布分支上进行的修改需要合并回develop分支，以确保将这些变更纳入下一个开发周期。
  5. 合并回master分支： 一旦发布分支准备好，并且发布的工作都已完成，将发布分支合并回master分支，以及为发布版本打上一个版本号的标签（Tag）。
  6. 继续开发： 合并回master分支后，可以继续在develop分支上开发新的功能，开始新的开发周期。

通过这种发布准备分支的方式，团队可以同时处理准备发布的任务和继续开发新功能，使得开发和发布之间的过渡更加平稳。这种方法也使得团队可以在不影响生产环境的情况下进行测试和准备，同时保持了代码的稳定性和版本控制。

维护分支

gitflow-04.png

维护分支（或热修复分支）是用于紧急修复生产环境中出现的bug，从master分支直接创建，然后修复完成后合并回master分支和develop分支，以确保修复同步到当前的发布分支。主要步骤如下：

  1. 创建维护分支： 当在生产环境中出现紧急的bug需要修复时，从master分支创建一个新的维护分支，例如hotfix/bug-fix.
  2. 进行修复工作： 在维护分支上进行必要的修复工作，解决生产环境中的问题。
  3. 合并回master分支： 修复完成后，将维护分支合并回master分支，以确保生产环境中的问题得到解决。
  4. 合并回develop分支： 为了确保修复在下一个版本中也得到修复，将维护分支的修改合并回develop分支。
  5. 打上Tag： 在master分支上打上一个新的版本号的标签，以标识这个修复版本。

维护分支的使用允许团队在不影响当前开发周期的情况下，快速响应和解决生产环境中的问题。这种方式确保了高效的bug修复和发布过程，同时不干扰正在进行的开发工作。这在保持生产环境稳定和可靠的同时，也使得团队能够及时应对紧急情况。

示例

Feature Branch Flow 示例：

  1. git checkout main：切换到主分支（main或master分支）。
  2. git checkout -b develop：基于主分支创建一个名为develop的新分支。这是用于功能集成的主要分支。
  3. git checkout -b feature_branch：从develop分支创建一个新的特性分支，名为feature_branch。在这个分支上进行特性开发。
  4. 在feature_branch上进行工作：在特性分支上进行代码修改和开发工作。
  5. git checkout develop：切换回develop分支。
  6. git merge feature_branch：将feature_branch分支上的工作合并回develop分支，以将特性集成到主要开发线。
  7. git checkout main：切换回主分支。
  8. git merge develop：将develop分支的变更合并回主分支，以便将所有的特性集成到主分支。
  9. git branch -d feature_branch：在完成特性分支的工作后，删除特性分支，因为它已经不再需要。

Hotfix Flow 示例：

  1. git checkout main：切换到主分支。
  2. git checkout -b hotfix_branch：从主分支创建一个新的分支，名为hotfix_branch。在这个分支上进行紧急修复工作。
  3. 在hotfix_branch上进行工作：在热修复分支上进行代码修改和修复工作。
  4. git checkout develop：切换到develop分支。
  5. git merge hotfix_branch：将hotfix_branch分支上的修复合并回develop分支，以确保修复同步到下一个开发周期。
  6. git checkout main：切换回主分支。
  7. git merge hotfix_branch：将hotfix_branch分支上的修复合并回主分支，以将修复引入到生产环境。

📂 Forking Workflow

Forking工作流是一种分布式Git工作流，广泛应用于开源项目和多人协作环境中。它充分利用了Git的分支和克隆特性，为大型团队和公开项目提供了一种安全和可靠的协作方式。

介绍

Forking工作流与其他Git工作流类似，首先需要有一个正式仓库，该仓库存储在服务器上，并对所有团队成员开放。然而，Forking工作流在开发者想要为项目做出贡献时有所不同。开发者不直接从正式仓库克隆代码，而是在服务器上对正式项目进行分叉（Fork），创建一个个人的公开仓库副本。

这个个人仓库副本是开发者的公开仓库，其他开发者可以拉取其修改，但不能直接推送到该仓库。这个特点在后续的合作中非常重要。在创建了个人仓库副本后，开发者可以使用git clone命令将仓库克隆到本地机器，作为私有的开发环境。

在提交本地修改时，开发者将修改推送到自己的公开仓库，而不是正式仓库。接着，开发者向正式仓库发起一个“拉取请求”（Pull Request），通知项目维护者已经准备好将更新集成到正式代码库中。这个拉取请求也可以作为讨论的场所，方便进行代码审查和交流。

为了将功能集成到正式代码库中，项目维护者会将贡献者的更改从个人仓库中拉取到自己的本地仓库，仔细检查以确保不会引入问题。然后，将这些更改合并到自己本地的master分支，并将master分支推送到服务器上的正式仓库。这样，贡献的更改就成为项目的一部分，其他开发者可以通过拉取操作将其同步到自己的本地仓库。

工作方式

在Forking工作流中，个人公开仓库实际上是为了方便与其他开发者共享分支。每个开发者都应该使用分支来隔离不同的功能，就像在功能分支工作流和Gitflow工作流中一样。唯一的区别在于，这些分支在Forking工作流中是通过拉取操作同步到其他开发者的本地仓库，而在功能分支工作流和Gitflow工作流中是直接推送到正式仓库。

示例

  1. 项目维护者初始化正式仓库： 项目维护者在服务器上创建一个正式仓库，让所有团队成员都可以访问。正式仓库通常也作为项目维护者的公开仓库。
  2. 开发者Fork正式仓库： 其他开发者都从正式仓库进行分叉（Fork），在服务器上创建自己的仓库副本。可以通过代码托管平台的界面进行操作。
  3. 开发者克隆自己的Fork仓库： 开发者克隆自己的公开仓库到本地，使用类似git clone的命令。
  4. 开发者进行开发： 开发者在本地仓库中创建新分支，进行代码编辑、提交等操作。所有的修改都是私有的，直到推送到个人仓库。
  5. 开发者发布功能： 开发者将自己的更改推送到个人公开仓库，使用git push命令。然后，向项目维护者发起一个拉取请求，请求将自己的更改合并到正式仓库。
  6. 项目维护者审查并集成更改： 项目维护者会审查开发者的拉取请求，在GUI中查看代码差异，进行评注和合并。如果出现合并冲突，维护者需要手动解决冲突。
  7. 开发者同步更改： 一旦贡献的更改被项目维护者合并到正式仓库，其他开发者需要使用git pull命令从正式仓库同步更改到自己的本地仓库，以保持代码最新。

🌟 总结

不同的Git工作流适用于不同团队和项目的需求。从集中式工作流、功能分支工作流、Gitflow工作流到Forking工作流，每种工作流都有独特优势，为项目开发提供了有力的支持。选择合适的工作流能够显著提升团队的开发效率、代码质量和协作能力，使项目开发过程更加高效有序。

avatar
文章
阅读
粉丝