精通 Git：高效版本控制的三个基本工作流程-洪萨配资

原文：towardsdatascience.com/mastering-git-the-3-essential-workflows-for-efficient-version-controlling-9bffe1883bd1

https://github.com/OpenDocCN/towardsdatascience-blog-zh-2024/raw/master/docs/img/1944a4751c033ba8823fcef7bcf2ff72.png

照片由 Prateek Katyal 在 Unsplash 提供

如果你希望高效且优雅地使用 Git，你找到了正确的位置！在阅读并应用了这里提出的工作流程后，我保证你的项目将提升到一个新的水平。采用 Git 工作流程对我来说不仅是一种良好的实践，而且是必须的！即使你不与他人协作，你也可以应用它，就像我发现它的好处以来我一直这样做。一开始可能觉得有些挑战，但随着实践，你会接受它并发现自己喜欢它。不拖延，让我们发现三个最重要的工作流程。

不是 Medium 会员？不用担心！通过这个*朋友链接*继续阅读。

目录：

· 1. 简介 · 2. 集中式工作流程 · 3. 功能分支工作流程 · 4. 分支工作流程 · 5. Gitflow 工作流程 · 6. 分支命名规范 · 7. 结论

1. 简介

嗯，当我刚开始接触并参与一些简单的、小型的项目时，我仅仅使用 Git 来保存我的项目并将它们上传到使用 Git 的平台。然而，当项目开始变得稍微大一些时，我发现自己在提交中迷失了方向，并且在回滚时遇到了困难。我还努力保持我的代码正常运行，因为它缺乏一致性，错误的风险增加了。此外，我还考虑了未来协作的可能性！这种策略代码审查有限，协作变得困难甚至不可能。因此，我对自己的说：“我需要一个 Git 工作流程！”这后者的开始就是我开始学习 Git 工作流程的旅程，在这篇教程中，我将与你分享我所学到的。

Git 工作流程是一套为管理 Git 仓库而建立的约定和实践。使用工作流程可以提供结构化和组织良好的 Git 仓库。它允许功能/修复的隔离；实现高效的代码审查和协作；保持主分支稳定；提高可追溯性；便于冲突解决；并简化回滚。开发团队设计了多种工作流程以满足他们的需求，以便有效地管理项目。然而，这些后者通常是以下三个基本工作流程之一或多个的采用或混合：功能分支工作流程、分支工作流程和gitflow 工作流程。

在这篇文章中，我们将探讨之前提到的三个基本 Git 工作流程。然而，在介绍这些之前，我将首先介绍集中化工作流程。

2. 集中化工作流程

https://github.com/OpenDocCN/towardsdatascience-blog-zh-2024/raw/master/docs/img/3b5fdb50bf68a8e1eeea7772d7b933ec.png

集中化工作流程是最直接的工作流程，我在引言部分已经介绍过。在这种方法中，你只有一个分支“master”进行工作，所有更改都直接提交到它。实际上，这是我们作为初学者通常使用的方法。集中化工作流程适用于简单的项目和小型团队。我可以或多或少地推荐它用于简单项目，然而，我强烈不建议在团队工作中使用它，即使团队很小，原因与之前提到的相同。

3. 功能分支工作流程

https://github.com/OpenDocCN/towardsdatascience-blog-zh-2024/raw/master/docs/img/26b8c652fe7b7ee3b516a378ad4aaae8.png

功能分支工作流程是一个直接的工作流程，它涉及为每个新的功能/修复创建一个专门的分支，而不是直接对主分支进行更改。然后，使用变基/合并将功能分支集成到主分支中。请注意，分支是从主分支创建的，它保留了项目的最新代码状态。

功能分支工作流程主要涉及以下命令：

要切换到主分支：

git checkout master

要将远程仓库中的更改更新到本地分支并自动合并：

git pull origin master

要创建分支并激活它：

git checkout-b<feature_name>

保存更改：

git commit-m"<Write a comment here>"

要将分支推送到远程仓库：

git push origin<feature_name>

要将分支合并到主分支：

# First, ensure you are on the master branchgit checkout master# Perform the mergegit merge<feature_name>

要变基分支：

# Switch to the branch you want to rebasegit checkout<feature_name># Perform the rebasegit rebase master

执行合并和推送的顺序取决于采用的策略：在团队工作中，如果合并分配给单个团队成员，则其他成员应推送他们的分支而不是合并/变基然后推送带有更改的主分支。另一种可能的场景是在合并之前，功能分支被提交进行审查和集成（通常称为 pull request），然后该分支可以被合并或关闭。

功能分支工作流程是一种高效的方法。它提供了功能隔离，简化了协作，并实现了代码审查。此外，与集中式工作流程相比，主分支通常更稳定，引入错误的风险降低。然而，在某些情况下，会应用更复杂的工作流程，如以下章节所示。

4. 分叉工作流程

https://github.com/OpenDocCN/towardsdatascience-blog-zh-2024/raw/master/docs/img/2d2f34198745ac2928c702dffe58418e.png

分叉工作流程与之前的工作流程略有不同。一般来说，当新开发者加入 Git 项目时，他会克隆单个官方服务器端仓库，然后在本地上更新它并将更改推送到该仓库。在分叉工作流程中，他们不会直接在唯一的服务器端仓库上工作，而是在服务器上创建一个副本，作为他们的个人仓库：这个操作称为分叉。然后，分叉的仓库被克隆到本地，并将更改推送到它。最后，通过拉取请求将更改提出给官方仓库，以便其维护者审查和合并推送到的内容。

分叉工作流程主要涉及以下命令：

要分叉一个仓库，通常使用托管平台提供的分叉按钮。没有直接用于分叉的 git 命令。
要将分叉克隆到本地机器：

git clone<repository_url>

要将原始仓库中做出的更改保留在分叉中，请将其添加为远程仓库：

git remote add upstream<original_repository_url>

要与主仓库同步并保持分叉与主仓库中做出的更改保持最新，请从上游远程获取更改并将它们合并/变基到本地分支：

git fetch upstream git checkout main git merge upstream/main# or git rebase upstream/maingit push origin main

要创建功能、进行更改、提交并推送到分叉，使用与分支工作流程相同的命令：

git checkout-b<feature_name>git commit-m"<Write a comment here>"git push origin<feature_name>

要从分叉功能分支向主仓库分支创建拉取请求，通常也会使用托管平台提供的拉取请求按钮。

分叉工作流程是一种高效的方法，尤其是在贡献者没有直接写入主仓库的权限，如开源项目中。除了这一点之外，其步骤和流程与功能分支工作流程非常相似。

5. Gitflow 工作流程

https://github.com/OpenDocCN/towardsdatascience-blog-zh-2024/raw/master/docs/img/32cfcb23675761e7b6e90f12fb9faed5.png

当在大型项目和大团队中工作时，保持产品和主分支的稳定，并在不同分支之间切换变得具有挑战性。为了克服这些挑战，Vincent Driessen 引入了 Gitflow。Gitflow 工作流程是一种流行的 Git 分支模型，它建立了一套关于如何组织和管理的分支的约定：它定义了特定的分支名称及其角色，以提高协作和发布管理。

Gitflow 工作流程包括两个主要分支（master 和 develop）和三种支持类型的分支（功能、发布和热修复分支）：

master分支代表已准备就绪的生产代码。
develop分支代表正在进行中的开发代码。
feature分支是为新功能开发而创建的。
发布分支是为新的生产版本创建的。
热修复分支是为了修复生产代码中的问题而创建的。

嗯，现在分支已经定义好了，它们的管理方式如下：

开发分支是从主分支创建的。
功能分支是从开发分支创建的，一旦完成，就将其合并到开发分支。
如果在主分支中检测到问题，将从一个主分支创建一个热修复分支，一旦完成，就将其合并到主分支和开发分支。
发布分支是从开发分支创建的，一旦完成，就将其合并到开发分支和主分支。然后，主分支被标记为版本号。
创建发布分支后，不能添加新功能，只能添加错误修复、文档生成和其他与发布相关的任务。

如我们所推断，这个工作流程中没有引入新的命令，只定义了命名约定和管理规则：只使用创建和合并分支以及在这些分支之间切换的命令。

Gitflow 工作流程功能强大，为我们提供了一个简单、优雅且组织良好的工作环境，我们可以在这里协作，并在不同的分支之间轻松地查找和切换。此外，它可以根据我们的需求进行调整。例如，在处理个人离线项目时，我们可以省略发布分支。

6. 分支命名约定

在 Git 或通常的版本控制系统中，分支命名约定加强了项目结构和组织。它还简化了与 CI/CD 系统和基于 Git 的平台自动化和集成。然而，命名约定可能在项目和团队之间有所不同，但有一些常见的做法：

代表生产就绪代码的默认分支命名为main或master。
开发分支命名为develop或dev。
功能分支的名称通常以前缀feature或feat开头，如下所示：feature/<feature_name>或feat/<feature_name>。
发布分支的名称通常以前缀release开头，并使用发布版本命名，例如：release/version-0.1或release/0.1。
热修复分支的名称通常以前缀hotfix开头，例如：hotfix/<hotfix_name>。