在开源项目中使用Git

If you have developed software as part of team, no matter what its size, you probably have used a source code management (SCM) system, be it Subversion, Mercurial, Bazaar, Git, or others. Every organization has its own guidelines on submitting code — from the style guide to be followed to what tests to write.

如果您作为团队的一部分开发了软件，则无论其规模如何，您都可能使用了源代码管理(SCM)系统，包括Subversion ， Mercurial ， Bazaar ， Git或其他。 每个组织在提交代码方面都有自己的准则-从要遵循的样式指南到编写哪些测试。

In this post, I’ll explain the general guidelines followed by many open-source organizations regarding the use of Git, beginning with some general discussion of open-source.

在本文中，我将解释许多开源组织遵循的有关Git使用的一般准则，首先是对开源的一些一般性讨论。

经典方式 (The Classic Way)

Up until a few years ago, most organizations accepted contributions to their open-source projects through email. They hosted their central repository on a public server, where you could clone the code. On adding and committing changes, a patch had to be generated to to be sent via email. If there were changes to be made, a new patch had to be generated. This process is very clumsy, but is still being used by many big organizations.

直到几年前，大多数组织都通过电子邮件接受了对其开源项目的贡献。 他们将其中央存储库托管在公共服务器上，您可以在其中克隆代码。 添加和提交更改后，必须生成补丁程序才能通过电子邮件发送。 如果要进行更改，则必须生成一个新补丁。 这个过程非常笨拙，但是许多大型组织仍在使用它。

In years past, Subversion, Mercurial, and Bazaar were very popular. So why does it seem that we only see the use of Git nowadays?

在过去的几年中，Subversion，Mercurial和Bazaar十分受欢迎。 那么，为什么现在看来我们只看到Git的使用？

Git的出现 (The Emergence of Git)

The launch of GitHub changed developers’ lives for the better. It eliminated the need for communication over email and made code review very easy. In GitHub, a huge chunk of Git features were given a web interface, leading to many organizations shifting to Git.

GitHub的推出改变了开发人员的生活。 它消除了通过电子邮件进行通信的需求，并使代码审查变得非常容易。 在GitHub中，大量的Git功能都提供了Web界面，导致许多组织转移到Git。

As a consequence, a large number of open-source organizations have shifted to Git from Subversion or Mercurial (although Mercurial is still preferred by Facebook because of its huge commit numbers every day). With the code now being hosted in the cloud through GitHub, the process of contributing has changed significantly.

结果，大量的开源组织已经从Subversion或Mercurial转向了Git(尽管Mercurial仍然是Facebook的首选，因为它每天的提交量很大)。 由于现在通过GitHub将代码托管在云中，因此贡献过程发生了显着变化。

“分叉”的概念 (The Concept of ‘Forking’)

If you want to contribute to a project directly, it is possible to push changes if you have write access to the repository. However, due to security concerns, write access is provided only to long-time contributors to the project. How then do you contribute?

如果您想直接为项目做出贡献，那么如果您对存储库具有写权限，则可以推送更改。 但是，出于安全考虑，仅向项目的长期贡献者提供写访问权限。 那你怎么贡献？

GitHub introduced the idea of forking for this purpose. A fork is your own copy of the central repository, where you have full write access. You can play around all you want with your fork, without disturbing the main repository.

GitHub引入了为此目的进行分叉的想法。 分支是您自己的中央存储库副本，在其中您具有完全写访问权。 您可以用叉子玩所有想要的游戏，而不会打扰主存储库。

Once you have fixed a bug (which you can find in a project’s bug tracker, or perhaps by asking through a mailing list or on IRC), you can submit a pull request to merge your code into the central repository. Your commit history and changed files are visible, with comments enabled for each line.

修复错误后(可以在项目的错误跟踪器中找到该错误，或​​者可以通过在邮件列表中或在IRC上进行查询)，可以提交提取请求，以将您的代码合并到中央存储库中。 您的提交历史记录和更改的文件均可见，并为每一行启用了注释。

There are other cloud-based solutions like BitBucket and GitLab, but the process remains roughly similar to GitHub.

还有其他基于云的解决方案，例如BitBucket和GitLab ，但是该过程大致类似于GitHub。

Git遥控器 (Git Remotes)

Although it is not really mandatory and doesn’t affect your workflow, there are two remote branches that are generally popular among developers: origin and upstream. Origin points to your fork, whereas upstream points to the central repository. You pull from upstream to keep your code updated and push bug fixes and patches to origin for a pull request.

尽管它不是强制性的，并且不会影响您的工作流程，但是有两个通常在开发人员中流行的远程分支 ：原始分支和上游分支 。 Origin指向您的fork，而上游指向您的中央存储库。 您从上游拉动以保持代码更新，并将错误修复程序和补丁推送到拉动请求的来源。

分支机构的使用 (Use of Branches)

If you are working on a new bug, start in a new branch. If you want to experiment, do so in the new branch. You should never push your changes to your master branch; the master branch must be used only to update your fork from the upstream.

如果您正在处理新错误，请从新分支开始。 如果您想进行实验，请在新分支中进行。 您永远不应将所做的更改推送到主分支。 master分支只能用于从上游更新fork。

Keep meaningful names for branches. When you are working on a large codebase with frequent changes, it is very easy to lose track of what you had been doing a few days earlier. Branch names must suggest the purpose of making such a branch. Use many branches; do not stick with a single master or developer branch.

为分支保留有意义的名称。 当您在频繁更改的大型代码库上工作时，很容易忘记几天前的工作。 分支名称必须表明建立这样一个分支的目的。 使用许多分支； 不要只使用一个master或developer分支。

Why should you use branches in this way? Imagine a scenario where you pushed a bug fix to your fork’s master and created a pull request. Before the pull request is merged, you decide to work on a new bug and push to master again. At this point, your existing pull request would get updated with the code of the new bug fix.

为什么要以这种方式使用分支？ 想象一个场景，您将错误修复推送到fork的master并创建了pull请求。 在合并拉取请求之前，您决定处理一个新的错误，然后再次推送到母版。 此时，您现有的请求请求将使用新的错误修复程序的代码进行更新。

That is why your master should always be clean. Alternately, you could create a branch using a different name that serves as the reference, but the master branch was created for the same purpose, so it’s best to stick to the method I outline above.

这就是为什么您的主人应始终保持清洁的原因。 或者，您可以使用其他名称创建分支作为参考，但是master分支是出于相同目的而创建的，因此最好坚持我上面概述的方法。

保持代码更新 (Keep Your Code Updated)

If you have worked with open-source organizations, you know that they are very strict regarding accepting code, especially from new contributors. Your code needs to be perfect, following all guidelines set by that organization (which you generally find in their documentation).

如果您与开源组织合作过，那么您就会知道，他们在接受代码方面非常严格，尤其是从新贡献者那里接受代码。 您的代码必须完美，并遵循该组织设置的所有准则(通常可以在其文档中找到这些准则)。

Due to the need for perfection, it often happens that the contributor is asked to make further changes in a patch. In the few days before those changes are incorporated, the code base has often changed significantly. In such cases, you should pull from upstream and merge all your commits for the patch into one (using git squash) to update the pull request.

由于需要完善，经常会要求贡献者在补丁中进行进一步更改。 在合并这些更改之前的几天中，代码库通常已发生重大更改。 在这种情况下，您应该从上游拉出并将对补丁的所有提交合并为一个(使用git squash )以更新拉取请求。

Git GUI工具 (Git GUI Tools)

Although all Git commands can be run successfully from the terminal, they may be overwhelming and even ugly for some. There are applications to help you manage Git repositories through a graphical interface, making it simpler to visualize all the data. If your Git basics are clear, these tools ultimately speed up your work! An example of such a tool is Source Tree by Atlassian (coincidentally the same company that owns BitBucket), a free Git and Mercurial client for Windows and Mac.

尽管所有的Git命令都可以从终端成功运行，但是对于某些人来说，它们可能是压倒性的甚至是丑陋的。 有一些应用程序可帮助您通过图形界面管理Git存储库，从而使所有数据的可视化变得更加简单。 如果您的Git基础知识很明确，那么这些工具将最终加快您的工作速度！ 这种工具的一个示例是Atlassian的Source Tree (碰巧是拥有BitBucket的同一家公司)，这是Windows和Mac的免费Git和Mercurial客户端。

If you need one just for GitHub, you can use GitHub for Windows, developed by GitHub just for the Windows platform. It has a great looking UI, which makes cloning, branching, and syncing easy with just a few clicks of the mouse. A downside is that complex commands are not possible through GitHub for Windows, meaning you need to fire up a terminal through the software in order to execute them.

如果您仅需要GitHub，则可以使用GitHub for Windows ，它由GitHub开发，仅用于Windows平台。 它具有美观的用户界面，只需单击几下鼠标，即可轻松进行克隆，分支和同步。 缺点是无法通过GitHub for Windows使用复杂的命令，这意味着您需要通过该软件启动一个终端才能执行它们。

交互式学习Git基础 (Learn Git Basics Interactively)

There is an interactive tutorial by Code School available free of cost, which focuses on teaching Git in general. This tutorial is great for beginners and teaches you to execute Git commands right from your browser! If you haven’t used Git before, you should definitely give it a try.

Code School提供了一个免费的交互式教程，该教程主要着重于Git的教学。 本教程非常适合初学者，并教您直接从浏览器执行Git命令！ 如果您以前从未使用过Git，则一定要尝试一下。

结论 (Conclusion)

Open-source contributions are mostly voluntary — you don’t get paid for them unless you run a parallel consultancy service or work for a large organization. Most contribute in this way as a hobby. As a consequence, the members working on a project are often distributed globally, which makes the use of an SCM absolutely necessary.

开源捐款大部分是自愿的，除非您运行并行的咨询服务或为大型组织工作，否则您不会获得报酬。 大多数人以这种方式贡献自己的兴趣。 结果，从事项目工作的成员通常分布在全球各地，这使得使用SCM绝对必要。

Developing software is an exciting yet challenging endeavor. Tools like Git have changed team-based development for the better. I hope this overview has helped you understand some of the concepts related to Git and how they can be used when contributing to open-source.

开发软件是一项令人兴奋但又充满挑战的工作。 像Git这样的工具已经使基于团队的开发变得更好。 希望本概述有助于您了解与Git相关的一些概念，以及在为开源做贡献时如何使用它们。

If you have any tips to share on your own Git workflow or your experiences in contributing to large open projects, we’d love to hear them in the comments.

如果您有任何技巧可以分享您自己的Git工作流程，或者您在大型开放项目开发中的经验，我们很乐意在评论中听到。

翻译自: https://www.sitepoint.com/using-git-open-source-projects/