git 代理 git_Git简介，第2部分

git 代理 git

In Part 1 of this series I introduced the basics of using Git – creating repositories, adding files, committing files, and using the Git’s log and diff tools to view a timeline of your changes. This part will move on from that to cover some slightly more advanced topics: reverting changes, creating branches, and merging changes from one branch into another.

在本系列的第1部分中 ，我介绍了使用Git的基础知识-创建存储库，添加文件，提交文件以及使用Git的日志和差异工具查看更改的时间线。 接下来，本部分将覆盖一些更高级的主题：还原更改，创建分支以及将更改从一个分支合并到另一个分支。

搞砸后还原更改 (Reverting Changes after You’ve Screwed Up)

Let’s take a classic example involving some unintentionally deleted work. You’ve edited a source file to make a simple change and you’re are about to hit Ctrl + S (assuming you’re not using vi) to save your work when the palm of your hand brushes across your laptop’s touch pad which causes a large chunk of the file to be selected. Then you inadvertently hit some other key which causes the selection to wipe out your work, and before you know what has happened, Ctrl + S saves your work. This is easy to recover from if you’re using Git.

让我们以一个涉及一些意外删除工作的经典示例为例。 您已经编辑了源文件以进行简单的更改，并且当您的手掌越过笔记本电脑的触摸板时，如果您不使用vi，将要按Ctrl + S (假设您不使用vi)来保存工作。要选择的文件的很大一部分。 然后，您无意中按下了其他键，这会使选择内容消失，并且在不知道发生了什么之前， Ctrl + S保存您的工作。 如果您使用的是Git，这很容易恢复。

将文件还原到以前提交的版本 (Reverting a File to a Previously Committed Version)

This scenario assumes you have not yet committed the broken file. Using the config.php file from the first part, let’s say somehow you’ve wiped out most of the database configuration array leaving it looking something like this:

此方案假定您尚未提交损坏的文件。 使用第一部分中的config.php文件，让我们以某种方式说出您已经抹去了大部分数据库配置数组，使之看起来像这样：

<?php
$database = array(
    "database"  => "new_project");

You can run git diff to see what has changed; the driver, host, username, and password values are all gone.

您可以运行git diff来查看已更改的内容； 驱动程序，主机，用户名和密码值都消失了。

-    "driver"   => "mysql", 
-    "host"     => "locahost", 
-    "username" => "Foo", 
-    "password" => "pass",

How do you restore the file? With git checkout config.php. The simplest way to undo some changes is to restore a file to the state it was in at your last commit.

您如何还原文件？ 使用git checkout config.php 。 撤消某些更改的最简单方法是将文件还原到上一次提交时的状态。

Sometimes you’ll want to undo some changes and restore a file back to how it was many commits ago. If you only want to restore a single file rather than all the files that are in a commit, you can use git checkout followed by the hash of the commit which contains the version of the file you want to restore, and the filename.

有时，您将需要撤消某些更改并将文件恢复为许多提交之前的状态。 如果只想还原单个文件而不是还原提交中的所有文件，则可以使用git checkout后跟提交的哈希，其中包含要还原的文件的版本和文件名。

Let’s say you ran git log config.php and it turned out that commit c1d55debc7be8f50e363df462f84672ad029b703 contained the version of foo.php you want to restore. Now you can run:

假设您运行了git log config.php ，事实证明，提交c1d55debc7be8f50e363df462f84672ad029b703包含要还原的foo.php版本。 现在您可以运行：

sean@beerhaus:~/new_project$ git checkout c1d55debc7be8f50e363df462f84672ad029b703 config.php
sean@beerhaus:~/new_project$ git commit config.php -m "Reverted to previous revision."
[master b125806] Reverted to previous revision.
 1 files changed, 1 insertions(+), 1 deletions(-)

Your working copy of config.php will be overwritten with the version from the earlier commit. Be careful when running your checkout command though, because it overwrites the file and you can’t restore a working copy… you can only restore versions that have been committed and are being tracked by Git.

您的config.php工作副本将被先前提交中的版本覆盖。 不过，在运行checkout命令时要小心，因为它会覆盖文件，并且您无法还原工作副本……您只能还原已提交并由Git跟踪的版本。

将所有内容还原为先前的提交 (Reverting Everything to a Previous Commit)

Another way to revert changes in Git is to revert everything to a specific commit. When you revert to a commit you revert every file in it, whether the commit contains one or one hundred files.

还原Git中更改的另一种方法是将所有内容还原为特定的提交。 还原为提交后，您将还原其中的每个文件，无论提交包含一个文件还是一百个文件。

Let’s create a timeline of fake changes to illustrate reverting entire commits. Create a file named foo.php in your test repository.

让我们创建一个虚假更改的时间表，以说明还原整个提交的过程。 在测试存储库中创建一个名为foo.php的文件。

<?php
// this is our original, pristine version

Add the new file and commit:

添加新文件并提交：

sean@beerhaus:~/new_project$ git add foo.php
sean@beerhaus:~/new_project$ git commit -am "This is the original version."
[master 4d7add0] This is the original version.
 1 files changed, 2 insertions(+), 0 deletions(-)
 create mode 100644 foo.php

Make a second change to foo.php that will look like this:

对foo.php进行第二次更改，如下所示：

<?php
// this is our original, pristine version
// this is a version that might be useful

Commit the changes again.

再次提交更改。

sean@beerhaus:~/new_project$ git commit -am "Added a comment."
[master 9e87750] Added a comment.
 1 files changed, 1 insertions(+), 0 deletions(-)

Make one more change that will be something you don’t want to keep:

再进行一次更改，这是您不想保留的：

<?php 
while (true) {
    exec("yes");
}

sean@beerhaus:~/new_project$ git commit -am "Added a really bad version of the file."
[master d4cb9dd] Added a really bad version of the file.
 1 files changed, 3 insertions(+), 2 deletions(-)

Once you have these three changes committed, take a look at the log. Since you’re mainly after the commit hashes here, you can pass a formatting option to git log to remove some of the extra information.

提交这三个更改后，请查看日志。 由于您主要是在这里进行提交哈希之后，因此可以将格式选项传递给git log来删除一些额外的信息。

sean@beerhaus:~/new_project$ git log --pretty=oneline foo.php
d4cb9ddbcb72cccf61e8682ecc2485a9a7a57a29 Added a really bad version of the file.
9e877501c2ad74d177a77b88eb66bfa8be7c18bd Added a comment.
4d7add037b4b38faba3392be988e0e9813daa8a7 This is the original version.

To undo the last commit, you can use git revert. The command expects an argument referring to the bad commit that needs to be reverted; since you want to undo only the most recent commit, you can use HEAD for the argument. In this context, HEAD is simply a reference to the last commit recorded.

要撤消上一次提交，可以使用git revert 。 该命令需要一个参数，该参数表示需要还原的错误提交； 由于您只想撤消最近的提交，因此可以使用HEAD作为参数。 在这种情况下， HEAD只是对记录的最后一次提交的引用。

sean@beerhaus:~/new_project$ git revert HEAD

The default editor will open allowing you to enter a message. In my case, a suggested message is already provided.

默认编辑器将打开，允许您输入消息。 就我而言，已经提供了一条建议消息。

Revert "Added a really bad version of the file."
    
This reverts commit d4cb9ddbcb72cccf61e8682ecc2485a9a7a57a29.

# Please enter the commit message for your changes. Lines starting 
# with '#' will be ignored, and an empty message aborts the commit. 
# On branch master 
# Changes to be committed: 
#   (use "git reset HEAD 
   
   
    
    ..." to unstage) 
# 
#       modified:   foo.php 
# 
   
   

Once git revert completes, take another look at your log.

git revert完成后，请再次查看您的日志。

sean@beerhaus:~/new_project$ git log --pretty=oneline foo.php
264208850a690ba1dc6de13c701390d395706830 Revert "Added a really bad version of the file."
d4cb9ddbcb72cccf61e8682ecc2485a9a7a57a29 Added a really bad version of the file.
9e877501c2ad74d177a77b88eb66bfa8be7c18bd Added a comment.
4d7add037b4b38faba3392be988e0e9813daa8a7 This is the original version.

A new commit has been made in which the contents of foo.php appears as it was before the bad commit.

进行了新的提交，其中foo.php的内容与错误提交之前的foo.php一样。

Now let’s try this again, only this time you’ll revert your codebase to 9e877501c2ad74d177a77b88eb66bfa8be7c18bd.

现在，让我们再试一次，仅这次，您将代码库恢复为9e877501c2ad74d177a77b88eb66bfa8be7c18bd 。

sean@beerhaus:~/new_project$ git revert 9e877501c2ad74d177a77b88eb66bfa8be7c18bd

Again, the editor opens for you to specify a commit message. Once you have done so, show the log once more.

再次，编辑器打开，供您指定提交消息。 完成后，再次显示日志。

sean@beerhaus:~/new_project$ git log --pretty=oneline foo.php
522ef8c7b70b1dcb9c21ecb51f1f025323b18da2 Revert "Added a comment."
264208850a690ba1dc6de13c701390d395706830 Revert "Added a really bad version of the file."
d4cb9ddbcb72cccf61e8682ecc2485a9a7a57a29 Added a really bad version of the file.
9e877501c2ad74d177a77b88eb66bfa8be7c18bd Added a comment.
4d7add037b4b38faba3392be988e0e9813daa8a7 This is the original version.

分支与合并 (Branching and Merging)

Branching and merging are concepts common to many version control systems. The idea is that you have your main line of development, sometimes referred to as trunk or stable. This is where you want to keep all the source code in a working, releasable, stable state. You don’t want to inflict all sorts of experimental code on this main line, not because you want to discourage new ideas or experimentation, but because you want this line to be clean and reliable. There should be another line for experimentation purposes, and this is what branches are.

分支和合并是许多版本控制系统共有的概念。 这个想法是您拥有自己的主要发展路线，有时也称为主干或稳定路线。 您要在这里将所有源代码保持在可运行，可发布，稳定的状态。 您不想在这条主线上施加各种实验性代码，这不是因为您不希望阻止新的想法或实验，而是因为您希望这条线是干净可靠的。 应该有另一行用于实验目的，这就是分支。

使用分支 (Using Branches)

A branch is like a copy of your main, stable development line. You can do whatever you want in the confines of your own branch and it will not affect anything in the main line until you merge your branch’s code back into the main branch.

分支就像您的主要稳定开发线的副本。 您可以在自己的分支范围内进行任何操作，并且在将分支的代码合并回主分支之前，它不会影响主行中的任何内容。

In Git, you’ve already been using a branch since you first create the repository. This branch is called “master” and you’ve been using it the whole time. Don’t believe me? Run git branch and behold its output.

在Git中，自您首次创建存储库以来，您就一直在使用分支。 该分支称为“ master”，您一直在使用它。 不相信我吗 运行git branch并查看其输出。

sean@beerhaus:~/new_project$ git branch
* master

The asterisk points to the branch which you are currently working on.

星号指向您当前正在处理的分支。

In most cases, master serves as the stable or main development line I mentioned before, but it doesn’t have to. You can easily create your own branch named “stable” and designate that as the main branch instead. The easiest way to create a branch is with git branch <name>.

在大多数情况下，master是我之前提到的稳定或主要开发线，但并非必须如此。 您可以轻松创建自己的名为“稳定”的分支，并将其指定为主分支。 创建分支的最简单方法是使用git branch <name> 。

Let’s create a branch in the repository named “experimental”.

让我们在存储库中创建一个名为“ experimental”的分支。

sean@beerhaus:~/new_project$ git branch experimental
sean@beerhaus:~/new_project$ git branch
  experimental
* master

Notice the asterisk is still showing master as the active branch. You’ve only created the new branch; you’ve not yet switched to it. To switch to the new branch, use git checkout.

请注意，星号仍将master显示为活动分支。 您只创建了新分支； 您尚未切换到它。 要切换到新分支，请使用git checkout 。

sean@beerhaus:~/new_project$ git checkout experimental
Switched to branch 'experimental'
sean@beerhaus:~/new_project$ git branch
* experimental
  master

Alternatively, you could have used git checkout -b experiment to create the new branch and switch you to it all in one shot. I prefer to use this shortcut instead of the two command process myself.

或者，您可以使用git checkout -b experiment来创建新分支，并一次完成切换到所有分支。 我更喜欢使用此快捷方式，而不是自己使用两个命令进程。

Since you were using the master branch when you created the experimental branch, the experimental branch will be a direct copy of master at the time the branch was created.

由于创建实验分支时您使用的是master分支，因此该实验分支将在创建分支时成为master的直接副本。

Now open foo.php in your editor and add a comment so that it looks like this:

现在，在编辑器中打开foo.php并添加注释，使其看起来像这样：

<?php
// this is our original, pristine version
// comment from the experimental branch

Then commit the change.

然后提交更改。

sean@beerhaus:~/new_project$ git commit -am "Added branch comment."
[experimental 8632135] Added branch comment.
 1 files changed, 1 insertions(+), 0 deletions(-)

Once you’ve committed that change, switch back to the master branch.

提交更改后，请切换回master分支。

sean@beerhaus:~/new_project$ git checkout master
Switched to branch 'master'

Take a look at foo.php and you’ll notice the changes you made in your experimental branch are not present. This is because the two branches are two different working environments. The changes from one branch will not appear in another branch until they’ve been merged.

看一下foo.php ，您会发现在实验分支中所做的更改不存在。 这是因为两个分支是两个不同的工作环境。 在合并之前，一个分支中的更改不会出现在另一分支中。

合并分支 (Merging Branches)

The git merge command takes the form git merge <source>, where <source> is the branch that you are merging changes from. The branch in which you run the merge command is implied as the destination.

git merge命令采用git merge <source>的形式，其中<source>是您要合并更改的分支。 您将运行merge命令的分支隐含为目标。

So let’s bring your branches from the experimental branch into the master branch.

因此，让我们将您的分支从实验分支带入主分支。

sean@beerhaus:~/new_project$ git merge experimental
Updating 522ef8c..8632135
Fast-forward
 foo.php |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

When you look at foo.php this time you’ll see the changes that was made in the experimental branch.

这次查看foo.php时，您将看到在实验分支中所做的更改。

Now let’s do this in the other direction; while you are still in master, make a change to foo.php that you’ll merge into the experimental branch.

现在让我们朝另一个方向做； 当您仍在母版中时，对foo.php进行更改，以将其合并到实验分支中。

sean@beerhaus:~/new_project$ git commit -am "Added function to master."
[master cbe5cba] Added function to master.
 1 files changed, 4 insertions(+), 0 deletions(-)

Switch to your experimental branch and merge the changes from master.

切换到实验分支，并合并来自master的更改。

sean@beerhaus:~/new_project$ git checkout experimental
Switched to branch 'experimental'
sean@beerhaus:~/new_project$ git merge master
Updating 8632135..cbe5cba
Fast-forward
 foo.php |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

Take a look at foo.php and see the function you added in master is now in the experimental branch.

看看foo.php ，看看您在master中添加的功能现在在实验分支中。

处理合并冲突 (Handling Merge Conflicts)

Eventually you’ll encounter conflicts while merging. A merge conflict happens when you are merging changes from one branch to another and Git cannot complete the merge without human intervention. This happens when you’ve edited line 80 of a file in one branch, Fred edits line 80 of the same file in another branch, and then you try to merge Fred’s changes with your changes. Git knows that the same section of code has been changed, but it’s up to us humans to figure out which change should be kept.

最终，合并时会遇到冲突。 当您将更改从一个分支合并到另一个分支时，会发生合并冲突 ，而Git在没有人工干预的情况下无法完成合并。 当您在一个分支中编辑了文件的第80行，Fred在另一个分支中编辑了同一文件的第80行，然后尝试将Fred的更改与更改合并时，就会发生这种情况。 Git知道代码的同一部分已经更改，但是我们应该由人类来确定应该保留哪些更改。

You can create a merge conflict situation very easily to prove the point. Switch to your master branch with Git, and open foo.php in your editor.

您可以非常轻松地创建合并冲突情况以证明这一点。 使用Git切换到master分支，然后在编辑器中打开foo.php 。

sean@beerhaus:~/new_project$ git checkout master
Switched to branch 'master'

Add this function at line 9:

在第9行添加此功能：

function master() {
    print "This is the master branch.n";
}

Save the file and commit your changes.

保存文件并提交更改。

sean@beerhaus:~/new_project$ git commit -am "Added master function."
[master 4f97280] Added master function.
 1 files changed, 4 insertions(+), 0 deletions(-)

Switch back to the experimental branch.

切换回实验分支。

sean@beerhaus:~/new_project$ git checkout experimental
Switched to branch 'experimental'

Open foo.php again in your editor and add this function to line 9 as well:

在编辑器中再次打开foo.php并将此函数也添加到第9行：

function experimental() {
    print "This is the experimental branch.n";
}

Commit the changes.

提交更改。

sean@beerhaus:~/new_project$ git commit -am "Added experimental function."
[experimental c5358cc] Added experimental function.
 1 files changed, 4 insertions(+), 0 deletions(-)

Now while you’re still in the experimental branch, merge the changes from master. You’ve edited the same lines of the same file in both branches, so you can expect some kind of conflict.

现在，当您仍在实验分支中时，请合并master中的更改。 您已经在两个分支中编辑了同一文件的相同行，因此可能会发生某种冲突。

sean@beerhaus:~/new_project$ git merge master
Auto-merging foo.php
CONFLICT (content): Merge conflict in foo.php
Automatic merge failed; fix conflicts and then commit the result.

Now you have to open the file and manually work out the conflict. In foo.php you’ll see something like this:

现在，您必须打开文件并手动解决冲突。 在foo.php您将看到以下内容：

<<<<<<< HEAD
function experimental() {
    print "This is the experimental branch.n";
=======
function master() {
    print "This is the master branch.n";
>>>>>>> master
}

The first section starting with <<<<<<< HEAD and ending with ======= is your last commit (HEAD). The section from ======= to >>>>>>> master are the incoming changes from the master branch.

第一部分以<<<<<<< HEAD开头，以=======结尾是您的最后一次提交( HEAD )。 从=======到>>>>>>> master的部分是master分支的传入更改。

Let’s assume you’ve decided that you are going to keep the changes from master and throw away the experimental changes. All you have to do is delete the conflict symbols and the lines that came from experimental. That section of foo.php should now have just the master function.

假设您已经决定要保留主要变更，而放弃实验变更。 您所要做的就是删除冲突符号和实验产生的线条。 foo.php该部分现在应该只具有master函数。

<?php
// this is our original, pristine version
// comment from the experimental branch

function bar() {
    print "This is bar.n";
}

function master() {
    print "This is the master branch.n";
}

Once that’s done, save the file and commit the resolved conflict.

完成后，保存文件并提交已解决的冲突。

sean@beerhaus:~/new_project$ git commit -am "Fixed a merge conflict from master to experimental."
[experimental 3871a1d] Fixed a merge conflict from master to experimental.

This was just a simple example. In the real world of professional software development you can have 20 different developers all merging changes from their individual branches into the master. Each time that happens, you’ll want to merge the newest changes from master back to your individual branch. Conflicts will happen, and while Git is a great tool to have, it cannot fix all of your problems in a situation like this. Sometimes good old fashioned human communication is the best tool to avoid conflicts of this size.

这只是一个简单的例子。 在专业软件开发的现实世界中，您可以有20个不同的开发人员，他们将各自分支中的更改合并到主服务器中。 每次发生这种情况时，您都希望将最新的更改从master合并回您的单个分支。 冲突将会发生，尽管Git是一个很好的工具，但它无法在这种情况下解决所有问题。 有时，良好的老式人际交流是避免这种规模冲突的最佳工具。

摘要 (Summary)

And that is how it’s done. You’ve seen how to recover from any mistakes you make along the way, how to create branches so you can work in parallel with other developers on the same project or to just try out new ideas without jeopardizing the stability of your main line, and finally how to merge other people’s edits into your own branch. The three topics covered in this piece – reverting mistakes, branching, and merging – along with part one of this series has provided you with the know-how to start using Git to manage your projects. If you’ve never used version control software before, I hope I’ve convinced you to start, and if you are still using CVS of Subversion, maybe you can give Git a try.

这就是完成的方式。 您已经了解了如何从一路上犯的错误中恢复过来，如何创建分支，以便可以与同一项目中的其他开发人员并行工作，或者只是尝试新的想法而又不损害主线的稳定性，并且最后是如何将其他人的编辑合并到您自己的分支中。 本文中涉及的三个主题(还原错误，分支和合并)以及本系列的第一部分为您提供了开始使用Git管理项目的专业知识。 如果您以前从未使用过版本控制软件，那么我希望我已经说服您开始使用，并且如果您仍在使用Subversion的CVS，也许您可​​以尝试一下Git。

翻译自: https://www.sitepoint.com/introduction-to-git-2/

git 代理 git