git团队_加入团队之前，您需要了解的10种Git技术

git团队

Have you been using Git for some time but never in a team environment? Are you familiar with the basics of Git but unsure how large teams use Git at work?

您使用Git已有一段时间了，但从未在团队环境中使用过吗？ 您是否熟悉Git的基础知识，但不确定有多少团队在工作中使用Git？

In this post, I’ll talk about the basic Git techniques that you must be familiar with before you join a team. I’ve listed them in an order that you’d logically follow to contribute to a repository, as the importance of each step is paramount. Let’s now jump into the list.

在本文中，我将介绍加入团队之前必须熟悉的基本Git技术。 我已经按照您逻辑上要为存储库做出贡献的顺序列出了它们，因为每个步骤的重要性都是至关重要的。 现在让我们进入列表。

1.克隆：团队入门 (1. Cloning: Getting Started in a Team)

If you’ve used Git for personal projects, you may only have initialized a project from scratch and added to it over time. When you’re working on an existing codebase, the first step is to clone the codebase into your local system. This enables you to work on your copy of the repository without any interference from other changes.

如果您已将Git用于个人项目，则可能只是从头开始初始化了一个项目，然后随着时间的推移将其添加到其中。 在使用现有代码库时，第一步是将代码库克隆到本地系统中。 这使您可以在存储库副本上工作，而不会受到其他更改的干扰。

To clone a repository, run the git clone command, followed by the path to the repository:

要克隆存储库，请运行git clone命令，然后运行存储库的路径：

git clone /path/to/repo

If your source doesn’t reside in the same system, you can SSH to a remote system and clone too:

如果您的源代码不在同一系统中，则可以SSH到远程系统并进行克隆：

git clone username@remote_system_ip:/path/to/repo/on/remote

If you’re cloning from a source on the Internet, you can simply add the URL:

如果要从Internet上的源进行克隆，则只需添加URL：

git clone https://github.com/sdaityari/my_git_project.git

Whenever you’re cloning a repository, you’ve the choice of multiple protocols to connect to the source. In the GitHub example above, I’ve used the https protocol.

每当克隆存储库时，您都可以选择多种协议来连接到源。 在上面的GitHub示例中，我使用了https协议。

2.在Git中管理遥控器 (2. Managing Remotes in Git)

Once you’ve cloned your repository, it still maintains a pointer to the source. This pointer is an example of a remote in Git. A remote is a pointer to another copy of the same repository. When you clone a repository, a pointer origin is automatically created which points to the source.

克隆存储库后，它仍然维护着指向源的指针。 该指针是Git中遥控器的一个示例。 远程是指向同一存储库的另一个副本的指针。 克隆存储库时，将自动创建一个指向origin的指针origin 。

You can check a list of remotes in a repository by running the following command:

您可以通过运行以下命令来检查存储库中的远程服务器列表：

git remove -v

To add a remote, you can use the git remote add command:

要添加远程，可以使用git remote add命令：

git remote add remote_name remote_address

You can remove a remote using the git remote remove command:

您可以使用git remote remove命令git remote remove ：

git remote remove remote_name

If you’d like to change the address of a remote, you can use the set-url command:

如果要更改遥控器的地址，可以使用set-url命令：

git remote set-url remote_name new_remote_address

3.在Git中分支 (3. Branching in Git)

The biggest advantage of Git over other version control systems is the power of its branches. Before I jump into the essentials of branching, you may be wondering what a branch is. A branch is a pointer to a commit in your repository, which in turn points to its predecessor. Therefore, a branch represents a list of commits in chronological order. When you create a branch, you effectively create only a new pointer to a commit. However, in essence, it represents a new, independent path of development.

与其他版本控制系统相比，Git的最大优势在于其分支机构的强大功能。 在开始介绍分支的基本知识之前，您可能想知道分支是什么 。 分支是指向存储库中的提交的指针，而该提交又指向其前身。 因此，分支代表按时间顺序排列的提交列表。 创建分支时，实际上只能创建指向提交的新指针。 但是，从本质上讲，它代表了一条新的，独立的发展道路。

If you’ve been working on your own project, you may never have consciously used branches. By default, Git uses the master branch for development. Any new commits are added to this branch.

如果您一直在从事自己的项目，则可能从未有意识地使用过分支。 默认情况下，Git使用master分支进行开发。 任何新的提交都将添加到该分支。

Branching is necessary for Git to bifurcate lines of work in a project. At a single time, there may be many developers who are working on a variety of different problems. Ideally, these problems are worked on in different branches to ensure logical separation of new code until code review and merge.

对于Git来说，分支对于项目中的工作分支是必要的。 在同一时间，可能有许多开发人员正在处理各种不同的问题。 理想情况下，这些问题应在不同的分支中进行处理，以确保新代码在逻辑上分开，直到代码复审和合并为止。

To check a list of branches and the current active branch, run the following command:

要检查分支列表和当前活动分支，请运行以下命令：

git branch

To create a new branch, run the following command:

要创建一个新分支，请运行以下命令：

git branch new_branch

Even though Git creates a new branch, notice that your active branch is still the old one. To start development in a new branch, run the following:

即使Git创建了一个新分支，请注意您的活动分支仍然是旧分支。 要在新分支中开始开发，请运行以下命令：

git checkout new_branch

To create a new branch and change the active branch, run the following command:

要创建新分支并更改活动分支，请运行以下命令：

git checkout -b new_branch

To rename the current branch, run the following command:

要重命名当前分支，请运行以下命令：

git branch -m new_renamed_branch

Use the -D option to remove a branch:

使用-D选项删除分支：

git branch -D new_renamed_branch

Here’s a detailed guide on branching in Git.

这是有关在Git中分支的详细指南。

4.更新您的本地存储库：合并 (4. Update your Local Repository: Merging)

While we’ve checked the basics of branching in Git, the next logical step is to merge a branch into your base branch when you’ve finished working on a problem. To merge a branch, run the following command:

虽然我们已经检查了Git中分支的基础知识，但下一步的逻辑步骤是在完成问题处理后将分支合并到基础分支中。 要合并分支，请运行以下命令：

git checkout base_branch
git merge new_branch

While it may sound like an easy process, merging is potentially the most time-consuming process in Git, as it can give rise to conflicts.

虽然听起来很简单，但是合并可能是Git中最耗时的过程，因为它可能引起冲突。

5.处理冲突 (5. Handle Conflicts)

Imagine that you’re working on a file in a new branch. After you commit the changes, you request Git to merge your new branch with your base branch. However, the same part of the same file in the base branch has been updated since you created the new branch. How does Git decide which changes to keep and which changes to discard?

假设您正在处理新分支中的文件。 提交更改后，您请求Git将新分支与基础分支合并。 但是，自创建新分支以来，基本分支中同一文件的相同部分已经更新。 Git如何决定保留哪些更改以及丢弃哪些更改？

Git always tries to not lose any data in the process of a merge. If the changes to the same file were done in different parts of the file, you could get away by keeping both sets of changes. However, if Git is unable to decide which changes to keep, it raises a conflict.

Git总是尝试在合并过程中不丢失任何数据。 如果对同一文件的更改是在文件的不同部分进行的，则可以通过保留两组更改来避免更改。 但是，如果Git无法决定保留哪些更改，则会引发冲突。

When a conflict has been raised, running git status on your repository shows a list of files that were modified in both branches being merged. If you open any file with a conflict, you’d notice the following set of lines:

发生冲突后，在存储库上运行git status显示在两个合并分支中已修改的文件的列表。 如果您打开任何有冲突的文件，则会注意到以下几行：

<<<<<<<< HEAD
...
...
========
...
...
>>>>>>>> new_branch

The part of the file between <<<<<<<< HEAD and ======== contains that code which is present in the base branch. The lines of code between ======== and >>>>>>>> new_branch are present in the new_branch branch. The developer who’s merging the code has the responsibility to decide what part of the code (or a mix of both parts) should be included in the merge. Once edited, remove the three sets of lines shown, save the file, and commit the changes.

<<<<<<<< HEAD和========之间的文件部分包含该代码，该代码存在于基础分支中。 在new_branch分支中有========和>>>>>>>> new_branch之间的代码行。 合并代码的开发人员有责任决定应在合并中包括代码的哪一部分(或这两部分的混合)。 编辑后，删除显示的三组行，保存文件，然后提交更改。

6.与远程同步更改 (6. Synchronize Changes with the Remote)

While we’ve discussed how to commit code in new branches, and merge it with the base branch, let’s now see how you can synchronize code with the remote. Before you can publish your changes to the remote, you need to update your local copy of the repository to account for any changes that may have occurred since your last update. To update changes from the remote, run the following command:

我们讨论了如何在新分支中提交代码并将其与基础分支合并时，现在让我们看看如何与远程代码同步。 在将更改发布到远程服务器之前，需要更新存储库的本地副本，以解决自上次更新以来可能发生的任何更改。 要从远程更新更新，请运行以下命令：

git pull remote remote_branch:local_branch

The git pull command first downloads the data from the remote and then merges with the local branch as specified in the command. Conflicts can arise while pulling changes from a remote too. In such a case, the last line in a conflict file would contain >>>>>>>> commit_hash instead of >>>>>>>> new_branch, where commit_hash would be the identifying hash for the commit being added to your branch.

git pull命令首先从远程下载数据，然后按照命令中的指定与本地分支合并。 从远程提取更改时也会发生冲突。 在这种情况下，冲突文件的最后一行将包含>>>>>>>> commit_hash而不是>>>>>>>> new_branch ，其中commit_hash将要添加到您的分支的提交的标识哈希。

To publish changes to the remote after merging with the latest code from the remote, use the git push command:

要与远程服务器的最新代码合并后将更改发布到远程服务器，请使用git push命令：

git push remote local_branch:remote_branch

7.云上的Git：分叉 (7. Git on the Cloud: Forking)

If your team works on the cloud, you’re introduced to an added concept called a fork. A fork is a copy of the central repository of the cloud under your username. You have write access to your fork, which is a safe place for you to push changes without affecting the original repository.

如果您的团队在云上工作，则会为您介绍一个称为fork的附加概念。 分支是用户名下云中央存储库的副本。 您具有对fork的写访问权，这是在不影响原始存储库的情况下进行更改的安全位置。

This affects the very technique step that I covered above. You clone your fork, so the origin of your local repository points to your fork on the cloud. How do you get the updates from the latest repository then? You need to manually add a remote, upstream, which points to the original repository.

这影响了我上面介绍的技术步骤。 您可以克隆分叉，因此本地存储库的origin指向云上的分叉。 那么，您如何从最新的存储库获取更新？ 您需要手动添加一个远程upstream ，它指向原始存储库。

While you can easily publish changes to your fork, how do you get new code accepted into the original repository? That brings us to the next step.

虽然您可以轻松地将更改发布到fork中，但是如何将新代码接受到原始存储库中？ 这将我们带入下一步。

8.通过拉取请求进行代码审查 (8. Code Reviews through Pull Requests)

A pull request is a request to merge code from a branch to another. It’s a concept that has developed since cloud services for Git became popular. A pull request summarizes the comparison between the two branches in question and initiates a discussion between the developer and the organization’s admins.

拉取请求是将代码从一个分支合并到另一个分支的请求。 自从Git的云服务开始流行以来，这个概念就得到了发展。 拉取请求总结了所讨论的两个分支之间的比较，并引发了开发人员与组织管理员之间的讨论。

A code review may culminate in more changes before it can be merged. When the admins are satisfied with the changes, it can be merged with the repository.

在可以合并之前，代码审查可能最终导致更多更改。 当管理员对更改感到满意时，可以将其与存储库合并。

9.了解Git工作流程 (9. Know About Git Workflows)

When you’re working alone on a single project, you’re probably using just a single branch. Unknowingly, you’re adhering to the centralized or trunk workflow, where all changes are made to a single branch.

当您一个人在一个项目上工作时，您可能只使用一个分支。 不知不觉中，您将遵循集中式或中继工作流程，其中所有更改都在一个分支上进行。

The next, more complex workflow is the feature-branch workflow, where a single branch is attributed to each feature or bug fix. No development happens directly on the master or development branches.

下一个更复杂的工作流程是功能分支工作流程，其中将单个分支归因于每个功能或错误修复。 没有开发直接发生在master分支或development分支上。

A Git workflow that encompasses a wide range of situations is the Gitflow workflow. It has separate branches for development, features, releases and hotfixes.

涵盖多种情况的Git工作流是Gitflow工作流 。 它具有用于开发，功能，发行和修补程序的独立分支。

Here’s a detailed guide on Git workflows.

这是有关Git工作流程的详细指南。

10.处理大文件：Git LFS (10. Handle Large Files: Git LFS)

While Git does a great job of handling text files, it’s unable to track changes in binary and executable files. While you can add such files to Git, it could potentially lead to a large repository size with an increase in the number of commits.

虽然Git在处理文本文件方面做得很出色，但它无法跟踪二进制文件和可执行文件中的更改。 虽然您可以将此类文件添加到Git，但可能会导致存储库很大，并且提交数量增加。

The solution is to use Git Large File Storage, which handles large binary files through Git. This tool stores these files on the cloud, and replaces them with text pointers. Here’s an implementation of using Git LFS to track Photoshop design files.

解决方案是使用Git大文件存储 ，它通过Git处理大型二进制文件。 该工具将这些文件存储在云中，并用文本指针替换它们。 这是使用Git LFS跟踪Photoshop设计文件的实现 。

进一步阅读 (Further Reading)

In this post, I’ve talked about various Git techniques that may help you when joining a team for the first time. I hope it’s helped you in your preparation for the future. Did I miss out on anything? Do let me know on Twitter!

在本文中，我讨论了各种Git技术，这些技术在首次加入团队时可能会对您有所帮助。 希望对您的将来有所帮助。 我错过了什么吗？ 在Twitter上告诉我！

For a deeper understanding of Git, check out these resources:

为了更深入地了解Git，请查看以下资源：

• Jump Start Git: A concise guide that will get you up to speed in a single weekend.

  Jump Start Git ：简洁的指南，可让您在一个周末内快速掌握。

• Professional Git: A deeper dive that’ll take you on the path to Git mastery.

  专业Git ：更深入的了解，将带您进入Git精通的道路。

翻译自: https://www.sitepoint.com/git-techniques-to-know-before-you-join-a-team/

git团队