如何成为一名更好的 GIT 协作者






4.81/5 (7投票s)
关于与开源项目协作的一些最佳实践。
GIT 似乎已成为大众事实上的新源代码控制系统,事实上,现在大多数甚至所有开源项目都是通过一个或另一个 GIT 存储库管理的,因为它与 SCRUM 式开发和团队协作能力保持一致。
另一方面,它无疑是我所见过的相当长一段时间以来最复杂的管理系统之一,GIT 有它自己的一套规则,如果你不遵守,你就会被困住。GIT 并不完美,但就分布式版本控制系统 (DVCS) 而言,它提供了很多。
本文的主要目的是向您展示与开源项目协作的一些最佳实践,市面上大多数教程都向您展示如何使用 git 本身,而且可悲的是,其中大多数都关注命令行功能,但我像其他人一样,喜欢我的图形界面世界。 所以,我不会教您 git,而是会引导您如何成为一名更好的 GIT 贡献者。
必备组件
有许多 GIT 客户端,有的比其他的更好,每个都有其优点。我实际上主要使用 3 个客户端来处理不同的任务。 我完全可以只用一个客户端就能有效地工作,但我喜欢我使用的每个客户端所带来的灵活性。
首先,您需要 适用于 Windows 的 GIT,它源自广受欢迎的 MSysGit。
其他平台也有其他客户端,虽然以下说明可能适用于那些平台,但本教程的主要重点是 Windows 客户端。
没有上述工具,您将举步维艰,因为其他客户端都在 MSysGit 的基础上进行构建(有些客户端会附带一个版本,但与安装最新客户端一起使用效果更好)。
Windows 版 Git 将为您提供许多资源管理器和命令行功能(外加一两个有用的 GUI 场景),这是一个不错的开始。 如果您只习惯使用命令行,那么这可以说是您所需要的一切,这些功能包括:
Git 解释器 – 命令行
用于存储库管理的 Git 资源管理器扩展
Git GUI 浏览器
这些都很好,但说实话,非常有限。
为了更进一步,还有几个其他客户端值得考虑:
TortoiseGit – IMHO 是目前最好的资源管理器管理客户端。
GitHub for Windows – 用于管理本地存储库的巧妙的 Metro 风格仪表板。
Visual Studio Tools for Git – 来自 TFS 团队的 VS Git 工具。
SmartGIT – 一个付费的 Git 客户端,功能众多。
SourceTree – 一个多功能的 Mercurial 和 Git 客户端。
Git-cola – 一个基于 Python 的 Git 客户端。
GitEye – 专注于协作的 Git 客户端,具有任务管理功能。
您可以在 此处 找到适用于其他平台的更多客户端列表。
我个人使用 TortoiseGit 在资源管理器中进行操作和与远程存储库同步,使用 GitHub for Windows 来管理我的存储库,在 VS 中工作时使用 VS Tools for GIT。
GIT 主机
如今,几乎所有的源代码存储库都提供 GIT 功能,例如:
GitHub – 首选且最主要的站点。
BitBucket – 使用广泛,但需要一些工作才能使客户端与其良好兼容。
Codelex – 最近增加了支持,但功能不如其他全面。
Team Foundation Service for GIT – Visual Studio 的 TFS 系统在 2013 年增加了 GIT 支持,值得一看 - 它是免费的。
Assembla – 很棒的网站,但你需要付费才能获得全部功能。
Beanstalk – 一个付费的高可用性系统,具有高端同步功能。
Indefero – 基于 Google Code 的开源系统,但支持更多客户端。
ProjectLocker – 功能齐全的项目管理系统,支持 SVN 和 GIT。
每个主机都有其优点和缺点,所以个人来说,我使用前三个,因为它们能让我有效地工作,但您应该选择适合您使用模式的。
只有当您要托管自己的项目时,才需要一个主机。如果您正在与其他项目协作,那么选择显然是由对方决定的,因为您不能混合使用不同的主机,嗯,您可以,但这会变成一场管理噩梦
最佳实践
在我参与或合作过的项目的大多数情况下,都有一些标准的“规则”需要遵守。
您应该
尽可能以小块的方式工作。
只在您的私有分支或存储库中工作。
在提交修复之前,先针对最新的 main / master 分支进行测试。
在论坛上讨论您的修复,并评论其他开发人员建议的更改,以使您保持更新。
您永远不应该考虑
提交超过一个月前的更改(取决于托管项目的速度)。
反复更新您的开发分支并提交修复,因为它们会淹没在信息流中。
清理您的本地开发分支以切换到另一个分支,而没有提交所有更改。
告诉主要项目贡献者/托管者他们是错的,这只会适得其反。
如果你这样做,你会死的!
尝试从主开发分支而不是您自己的修复分支提交 PR。
从反编译的 DLL 或 CodeProject 帖子中复制代码到存储库,而没有发布许可。版权是真实存在的!
公开抨击项目托管者不听您的话,毕竟这是他们的项目。
总而言之,请努力成为一只友善的小狗。
开始贡献
好了,您找到了一个开源项目,并觉得您有东西可以贡献或者可以帮助修复,接下来该做什么,您需要做什么才能开始? 如果您遵循以下步骤,答案将非常直接和简单。
1:Fork(复刻)
根据项目所在的网站,应该有一个“Fork”项目的选项,这将在网站上为您创建一个项目的镜像。不用担心它占用空间,因为只有您的更改才会被记录在案。 GIT 服务器通常足够智能,不会在每个地方都创建文件副本。用力 Fork,经常 Fork。
主存储库
复刻的存储库
是的,您可能已经注意到您可以 Fork 已经复刻的存储库,疯狂无止境 (但我建议您不要这样做,除非您要合并)。
2:Clone(克隆)
有了您自己的复刻存储库,现在是时候在本地获取该副本了,基本上是将源代码复制到您的计算机,同时保留与网站的链接。
有几种方法可以做到这一点。最简单的方法是点击网站上的“Clone in Desktop”按钮(如果它存在),这将启动您的本地 Git 客户端,设置一个本地存储库并开始将其复制到您的计算机。
如果您没有安装兼容的客户端,您可能会被转到安装客户端的页面,或者它根本不起作用。
另一种方法是复制 Clone URL(指向您在线存储库的链接),然后手动使用您的 Git 客户端将存储库克隆到您的计算机。
![]() |
![]() |
Tortoise GIT 右键菜单 | TortoiseGit 克隆提示,源和本地目录 |
如果您选择手动下载项目并解压缩,那也可以,但一旦您创建了本地存储库,您将需要添加一个源(稍后介绍)。
3:Branch(分支)
将复刻的项目托管在本地后,您现在拥有了该源代码项目的 Main / Default / Master 分支的一个副本。首先,您应该尽可能保持其干净,并且无论何时何地,都要使其与原始项目保持同步。
永远,永远,永远,直到永远,不要向 Main / Default / Master 分支提交更改。
在进行修复或改进时,您应该始终在您的复刻存储库中针对特定修复创建一个本地分支。 进行 3 次修复,为每次修复创建 3 个单独的分支(除非它们直接相关或相互依赖)。
创建分支有三种选择:
在选择“新分支”选项时执行 Switch / Checkout – 有效地选择另一个分支进行工作,但创建一个新的分支。
如果您的客户端支持,请选择“创建新分支” – 几乎与第一个选项相同,但又不完全是…
在 main / default / master 分支上开始进行更改,但在“Commit”(提交)更改时,选择新分支选项 – 这会将您的更改移到一个全新的分支。
![]() |
![]() |
TortoiseGit Switch/Checkout & Create Branch | TortoiseGit 提交时的“Create Branch”选项 |
最安全的选择显然是选项 1 或 2,因为这可以在您工作时保护您,以防万一您需要更新 main / master / default 分支(这是一种不太可能发生的情况)。 它还可以保护您,防止您忘记在提交时选择“新分支”选项,意外地将更改合并到您的本地 main / master / default 分支中 #facepalm。 如果发生这种情况,您将陷入困境(您可以回退,但然后您将丢失您的更改,并最终弄脏了您的本地 main / master / default 分支副本)。
您的本地存储库现在已准备好进行工作。
4:做事
您开始工作了,您正在进行代码操作。
但请记住,尽量保持修复的小型化。如果它需要很长时间,您有几个选择:
将您当前的分支仅用作开发/概念验证 (POC) 分支。 跟踪您的文件,然后在提交前根据当前 master 创建一个新分支并将文件移入(稍后详述)。
继续工作,记住您很可能需要在提交之前从源更新项目。
决定您正在做的事情不值得,然后继续。
贡献时有很多种工作方式,第一种方式是有一个自己的私有开发分支,您会将其与源代码保持同步,然后在提交拉取请求时,将您特定的修复移到一个基于干净的 master/main/default 分支的新分支上。这种方法是相当普遍的。
理想情况下,您应该快速、专注,只做完成您正在做的事情所必需的更改。没有人喜欢在一项更改中混合大量修改。
记住:
保持小巧。
保持专注。
只更改您需要的。
这样大家都会更开心。 拥有 10 个小型独立分支比一个大型复杂更改要好,项目团队更难测试和决定是否要接受您的辛勤工作。
现在,当您对更改感到满意时,只需将更改“提交”到您的本地存储库即可。 您可以根据需要频繁地这样做,这样如果需要,您还可以回退。 如果您仍在 master/main/default 分支上,请务必检查“New Branch”(新分支)选项,否则您将像疯子一样在办公室里跑来跑去尖叫。 #BeenThereDoneThat
5:Push(推送)和 Pull(拉取)
那么,您完成了更改,测试了它并且很满意,接下来呢?
首先,您需要更新您本地代码的开发副本,与您托管的复刻存储库同步,这称为 Push 请求。 您可以根据需要频繁执行此操作,它不会影响任何人。在大多数情况下,您会在每次提交后执行此操作,以确保您的更改已远程备份。 请注意,如果没有提交(半途而废),则无法推送。
![]() |
只需使用 Push 命令(有时称为 Sync)将您的代码发送到您的复刻存储库服务器。 |
一旦您对完成的更改感到满意,并且所有代码都已上传到您的复刻存储库服务器,您就可以发起一个“Pull request”。 | ![]() |
与所有事情一样,有几种方法可以发起拉取请求。有些客户端在执行推送请求后会提供此选项,但我发现最好的方法是访问托管复刻存储库的网站并使用其按钮或命令。例如,GitHub 现在会在您的复刻存储库页面上突出显示一个按钮来启动该过程。
一旦您开始此操作,系统将询问您要将您的拉取请求命名为什么。默认情况下,大多数网站会复制最后一次提交的文本,但您应该能够更改它。 使标题有意义,并在描述中尽可能多地提供信息,以准确描述您的更改/添加。
然后,原始项目的管理员/组织者将负责检出/测试并决定是否将您的更改合并到他们的 main 分支。 一旦合并,您就可以删除您的开发分支,因为代码现在位于 main / default / master 分支中了。
保持更新
在您工作期间,显然您希望将您的本地存储库与主项目的源代码保持同步。这是一个相对简单的任务,但它会给大多数新手带来一个令人困惑的领域。
为了用主项目的源代码更新您的本地开发环境,您需要执行 Pull 请求(等等,我刚才不是做了一次吗?)。
Pull 请求简单来说就是您想从一个项目获取更改并将其添加到另一个项目,同步两者。当您从您的复刻存储库执行拉取请求时,您实际上是在要求主项目将您的新分支复制到他们的存储库,以便他们可以与该远程分支进行合并。 在这里,我们做同样的事情,但方向相反,您将从主项目拉取代码并将其添加到您的项目中。唯一的区别是,而不是一个新的分支,您是在更新您本地的代码副本。 有意义吗?Pull 复制项目之间的代码。
现在,为了不污染您正在进行的任何开发工作,请确保您已签入您正在进行的任何更改,然后切换/检出您本地存储库中的 main / default / master 分支。您可以使用前面提到的相同技术,但不要选择“新分支”选项,而是选择 main / default / master 分支,或者使用 MSysGit(Git for Windows)提供的方便的资源管理器上下文菜单。
完成此操作后,**再次检查!!**
我不会告诉您我更改/切换分支,开始工作,然后才意识到它实际上没有成功执行了多少次。
确保安全,再次检查。 这种情况很少见,但 git 客户端不会让您更改分支,除非您当前的分支一切正常。 问题可能很简单,比如一些未保存的文件或者您没有提交。 在大多数情况下,git 客户端不会告诉您有问题(真他妈烦人)。
随着经验的积累,您会找到一个对您来说效果良好的客户端。通常,如果出现问题,我会使用完整的 GUI 路由或恢复到使用命令行,最终它会告诉您为什么无法切换分支。
找到问题,清理干净,当它最终在 main / default / master 分支上注册后,您就可以继续前进。
设置上游源
要成功地从主项目更新您的本地源代码,您只需告诉它源代码在哪里。 因为它不是您的主存储库,所以您的本地客户端对此一无所知(我个人希望 GIT 客户端能识别这是一个复刻的存储库并为您完成此操作,但在此之前…)。
一旦您习惯了,这个过程非常简单。 现在,根据您的客户端,您需要找到您本地项目的“Remotes”(远程)配置。这可能是:
GIT 项目属性中的 Remotes 设置(如下面的 tortoiseGIT 所示)。
推送/同步窗口中的源选择旁边的 Manage(管理)按钮。
Switch / Checkout 选项中的 Sources 或 Manage 按钮。
找到它之后,您应该会发现列表中只有一个“Remote”(远程),这是指向您复刻存储库的链接。 我们只需为主项目的 Git 存储库添加另一个。
惯例是将这个新的“Remote”称为“upstream”(上游)源,如上例所示,您只需添加一个新项,将其命名为 upstream,然后粘贴主项目源的 Git HTTP 路径。 如果您没有,只需浏览到主项目在其 GIT 网站上的页面,然后复制 GIT 克隆 URL。
您应该注意到,您可以向您的项目添加多个远程。我敢肯定这是为了灵活性,但我无论如何也想不出原因。也许是为了让您能够访问同一个代码分支的多个复刻,并能够访问它们。我从未这样做过,所以我不会进一步阐述。
现在,添加了新远程之后,使用您的 GIT 客户端执行 Pull 请求,但这次将“Source”(源)更改为我们新的“upstream”路径。
**在**实际执行之前,请务必检查:
您选择了正确的 REMOTE 分支要从中拉取,不要假设它总是 main / default / master 分支。
您选择了正确的“Remote”URL / 源。
一旦您“Pulled”(拉取)了,您应该会收到一份关于自上次更新源代码以来与主项目相比发生了什么变化的报告,包括所有提交消息以及有关哪些文件已更改的信息。如果您愿意,拉取后,别忘了将合并推回到您的复刻存储库以保持其更新。请记住将源改回“origin”,否则您将不知为何无法上传
您不必只从本地 main / master / default 分支执行此操作,您可以从本地任何分支执行此操作。 所以,如果您正在使用一个您想保持更新的本地开发分支,或者主项目管理员要求您在接受并合并之前(因为时间过长)针对最新源代码进行测试。
但请记住:
保持您的本地 master / main / default 分支干净,不要包含您的工作。它应该镜像源项目。
不要提交从源刷新过的分支的请求,除非主项目管理员要求您这样做。
您可以从多个分支拉取代码到一个大型本地分支,只是不要期望从中接受 PR。
做一个好的协作者,让您的主项目管理员满意。别忘了有一天您也可能是他/她。
结束
希望您觉得这篇文章很有用。 像往常一样,如果您有任何评论或问题,请在下方发布,我会尽力回答每一个问题,即使您想说这是一堆垃圾,而且不是这么做的,我也欢迎不同的观点。 这只是我从许多抱怨我贡献的(而且我不会说名字,我从每一次负面反馈中学到了很多)心怀不满的管理员那里学到的。
我可能会跟进一篇关于如何成为项目管理员以及如何测试和合并 PR(拉取请求)的文章,如果您正在运行一个项目,您自己可以这样做。 待定。
回头见。