现有项目 git_既然您不再担心GIT，以下是利用现有知识的方法

现有项目 git

The first part of this series looked at the inner workings of GIT and showed you how not to be afraid of working with Git.

本系列的第一部分介绍了GIT的内部工作原理，并向您展示了如何避免与Git一起工作。

Now that we understand how Git works, let’s get into the meaty stuff: how to leverage what we know in our projects.

现在，我们了解了Git的工作原理，让我们深入探讨一下：如何利用我们在项目中了解的知识。

合并 (Merge)

Merge merges your code.

合并合并您的代码。

Remember how we were following good Git practices, having branches for various features we were working on, and not everything on master? There will come a time when you are done with that feature, and will want to include that in your master. This is where merge comes in. You want to merge your branch into master.

还记得我们如何遵循良好的Git惯例，为我们正在开发的各种功能创建分支，而不是master所有功能吗？ 有一段时间您将完成该功能，并希望将其包括在master 。 这是merge地方。您要将分支合并到master。

There are 2 kinds of merges:

有两种合并：

快进合并 (Fast forward merge)

Coming back to our example from last time:

回到上一次的例子：

This is as simple as moving the label for master to the-ending. Git has no doubt about exactly what needs to be done — since our “tree” had one single linked list of nodes.

这很简单，只要移动标签master到the-ending 。 Git毫无疑问确切地需要做什么—因为我们的“树”只有一个链接的节点列表。

$ git branch
  master
* the-ending
$ git checkout master
Switched to branch 'master'
$ git merge the-ending
Updating a39b9fd..b300387
Fast-forward
 byeworld | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 byeworld

非快进合并 (Non-Fast Forward Merge)

This is the kind of merge where Git doesn’t know what to do. There are some changes on the base branch, and some more on the branch we want to merge, thus resulting in the scary merge conflicts!

这是Git不知道该怎么做的合并。 基本分支上有一些更改，我们要合并的分支上有更多更改，因此导致可怕的合并冲突 ！

Here’s the first thing to know about merge conflicts: If you don’t know what’s happening:

这是关于合并冲突的第一件事：如果您不知道发生了什么：

git merge --abort

This will bring you back to the original state, with no side effects. You just aborted the mess you were about to make.

这将使您回到原始状态，而没有副作用。 您只是中止了将要造成的混乱。

Let’s go step by step now into how to resolve merge conflicts.

现在让我们逐步解决如何解决合并冲突。

$ git checkout -b the-middle
Switched to a new branch 'the-middle'

In continuing our style, let’s learn via an example. I modify helloworld on branch the-middle.

在继续我们的风格时，让我们通过一个例子来学习。 我在the-middle分支上修改helloworld 。

$ git diff
diff --git a/helloworld b/helloworld
index a042389..e702052 100644
--- a/helloworld
+++ b/helloworld
@@ -1 +1,3 @@
 hello world!
+
+Middle World

Add and commit on the-middle.

在the-middle添加并提交。

Then, I switch to master and modify helloworld on master. I add the following:

然后，我切换到master并在master上修改helloworld 。 我添加以下内容：

$ git diff --cached
diff --git a/helloworld b/helloworld
index a042389..ac7a733 100644
--- a/helloworld
+++ b/helloworld
@@ -1 +1,3 @@
 hello world!
+
+Master World

Do you see why I had to do git diff --cached here? If not, ask me below!

你知道为什么我必须在这里做git diff --cached吗？ 如果没有，请在下面问我！

Now, it’s time to merge!

现在，该合并了！

$ git merge the-middle
Auto-merging helloworld
CONFLICT (content): Merge conflict in helloworld
Automatic merge failed; fix conflicts and then commit the result.

When a merge fails, here’s what git does: It modifies the file with the merge to show you exactly what it can’t decide about.

当merge失败时，这就是git的作用：它通过合并修改文件，以向您确切显示无法确定的内容。

$ cat helloworld hello world!

$ cat helloworld 
hello world!
<<<<<<< HEAD
Master World
=======
Middle World
>>>>>>> the-middle

Does this make sense? The <<<<< HEAD part is ours (the base branch) and the >>>>> the-middle part is theirs (the branch merging into the base branch).

这有意义吗？ <<<<< HEAD部分是我们的(基础分支)， >>>>> the-middle part是theirs (分支合并为基础分支)。

You can simply edit the file to remove the extra stuff added by git, and choose what should go into helloworld finally. There are some tools and editor integrations to make this easier, but I think knowing how it works underneath the hood gives you more confidence when you don’t have your favourite editor lying around.

您只需编辑文件即可删除git添加的多余内容，然后选择最终应放入helloworld 。 有一些工具和编辑器集成可简化此操作，但我认为，当您没有喜欢的编辑器时，了解它在幕后的工作方式将为您带来更多的信心。

$ git status
On branch master
You have unmerged paths.
  (fix conflicts and run "git commit")
  (use "git merge --abort" to abort the merge)
Unmerged paths:
  (use "git add <file>..." to mark resolution)
both modified:   helloworld

I decided to keep both bits.

我决定保留这两位。

$ cat helloworld 
hello world!
Master World
Middle World

And there you have it:

那里有：

$ git add helloworld 
$ git commit -m "resolve merge conflict"
[master c747e68] resolve merge conflict

遥控器 (Remotes)

Since one power of version source control is to save your code in case of disasters — remotes are here to help. A remote is an externally-hosted copy of your git repository. To be more accurate, a remote is an external repository (not necessarily of the same code you have). By external, it could be in a different folder on your system or in the cloud.

由于版本源代码控制的一种功能是在发生灾难时保存代码，因此可以使用远程帮助。 远程是git存储库的外部托管副本。 更准确地说，远程是外部存储库(不一定具有相同的代码)。 通过外部，它可以位于系统上或云中的其他文件夹中。

克隆 (Clone)

Clone clones the repository from remote into your current working directory. This is simply creating a copy of the .git/ folder, which gives us the entire history and the files needed to populate the working directory.

克隆将存储库从远程克隆到您当前的工作目录中。 这只是创建.git/文件夹的副本，它为我们提供了完整的历史记录以及填充工作目录所需的文件。

git clone <repository-url>

If you haven’t cloned, you probably don’t have a remote. You can create a remote like this:

如果尚未克隆，则可能没有遥控器。 您可以这样创建一个遥控器：

git remote add <name> <url>

推和拉 (Push and Pull)

Push and Pull are actions applied on the remote.

推和拉是应用于remote动作。

Push pushes your changes to the remote. So, we are sending the Index and corresponding Objects from the object-store!

推送将您的更改推送到遥控器。 因此，我们正在从对象存储中发送Index和相应的Objects ！

git push <name of remote> <name of branch>

Pull pulls the code from the remote. Exactly as before, we are copying the Index and corresponding Objects from the object-store!

拉拉动从远程的代码。 与以前完全一样，我们正在从对象存储中复制Index和相应的Objects ！

git pull origin master

origin is the default name of the remote. And since master is the default branch, you can see how the command devolves into the simple name we find everywhere: git pull origin master. Now you know better.

origin是遥控器的默认名称。 而且由于master是默认分支，因此您可以看到命令如何演变成我们在各处都能找到的简单名称： git pull origin master 。 现在您知道了。

重启 (Reset)

Reset resets your codebase to a previous version. Reset comes with 3 flags:

重置会将您的代码库重置为以前的版本。 重置带有3个标志：

--soft, --hard and --mixed.

--soft ， --hard和--mixed 。

The beauty of reset, is being able to change history. Say you make a mistake with a commit, and now your git log is all messed up with commits like:

reset的美，在于能够改变历史。 假设您在commit了一个错误，现在您的git log被诸如以下的提交弄得一团糟：

Bugfix

Bugfix

Final BugFix

Final BugFix

Final Final BugFix

Final Final BugFix

God why isn't this working last try bug fix

God why isn't this working last try bug fix

If you want to keep your master history clean, you want to clean up this commit log.

如果要保持master历史记录干净，则要清除此提交日志。

If you’re sending in a Pull Request where there’s no squashing, they’d expect a clean commit history too!

如果您在没有挤压的情况下发送“拉取请求”，他们也希望获得干净的提交历史！

That’s where reset comes in: You could reset all your commits and convert them into one single commit: got sh*t done!

这就是reset进入的地方：您可以reset所有提交并将它们转换为一个提交： got sh*t done!

(Please don’t use this as your commit message — follow the best practices!)

(请不要将其用作您的提交消息，请遵循最佳做法！)

Coming back to our example, here’s what I’ve done.

回到我们的例子，这就是我所做的。

$ git log
commit 959781ec78c970d4797c5e938ec154de44d0151b (HEAD -> master)
Author: Neil Kakkar
Date:   Mon Nov 5 07:32:55 2018 +0000
God why isn't this working last final BugFix
commit affa90c0db78999d22c326fdbd6c1d5057228822
Author: Neil Kakkar
Date:   Mon Nov 5 07:32:19 2018 +0000
Final Final BugFix
commit 2e9570cffc0a8206132d75c402d68351eda450bd
Author: Neil Kakkar
Date:   Mon Nov 5 07:31:49 2018 +0000
Final BugFix
commit 4560fc0ec6305d0b7bcfb4be1901438fd126d6d1
Author: Neil Kakkar
Date:   Mon Nov 5 07:31:21 2018 +0000
BugFix
commit c747e6891af419119fd817dc69a2e122084aedae
Merge: 3d01508 fb8b2fc
Author: Neil Kakkar
Date:   Tue Oct 23 07:44:09 2018 +0100
resolve merge conflict

Now that the bug is fixed, I want to clean up my history before I push to master. This would work well too — when, say, I realise later on that I introduced another bug and need to revert to the previous version. In this case, c747e689 doesn’t have the best commit message to understand this.

现在，该错误已修复，我想先清除自己的历史，然后再继续master 。 这也将很好地工作，例如，当我稍后意识到自己引入了另一个错误并需要恢复到先前的版本时。 在这种情况下， c747e689没有最好的提交消息来理解这一点。

$ git reset c747e6891af419119fd817dc69a2e122084aedae
$ git log
commit c747e6891af419119fd817dc69a2e122084aedae (HEAD -> master)
Merge: 3d01508 fb8b2fc
Author: Neil Kakkar
Date:   Tue Oct 23 07:44:09 2018 +0100
resolve merge conflict

There, all sorted?

在那里，所有排序？

$ git status
On branch master
Untracked files:
  (use "git add <file>..." to include in what will be committed)
      clean.txt
nothing added to commit but untracked files present (use "git add" to track)

clean.txt is the file I had committed for the bug fix. Now, all I have to do is:

clean.txt是我已提交的错误修复文件。 现在，我要做的就是：

$ git add clean.txt 
$ git commit -m "fix bug: Unable to clean folder"
[master d8487ca] fix bug: Unable to clean folder
 1 file changed, 4 insertions(+)
 create mode 100644 clean.txt
$ git log
commit d8487ca8b9acfa9666bdf2c6b7fa27b3971bd957 (HEAD -> master)
Author: Neil Kakkar
Date:   Mon Nov 5 07:41:41 2018 +0000
fix bug: Unable to clean folder
commit c747e6891af419119fd817dc69a2e122084aedae
Merge: 3d01508 fb8b2fc
Author: Neil Kakkar
Date:   Tue Oct 23 07:44:09 2018 +0100
resolve merge conflict

There, done and dusted. Can you guess now, using the clues from the log, the reset command syntax and your tech-sense to figure out how it works behind the scenes?

在那里，完成并撒粉。 您现在可以使用log ， reset命令语法和您的技术知识来推测出它在幕后如何工作的情况吗？

Reset cuts off the commit-tree at the specified commit. All labels for that branch — if ahead — are moved back to the specified commit. Do the existing files stay in the object store though? You know how to check that now, Ace.

Reset在指定的提交时切断提交树。 该分支的所有标签(如果在前面)将移回到指定的提交。 现有文件是否保留在对象存储中？ Ace，您现在知道如何检查。

The files are also removed from the staging area. Now this might be a problem if you have lots of untracked/modified files which you don’t want to add.

文件也将从暂存区中删除。 现在，如果您有许多不想添加的未跟踪/修改的文件，则可能会出现问题。

How do you do that?

你是怎样做的？

Can you pick up the clue I left in the beginning of this section?

您能否领会我在本节开始时留下的线索？

Behaviour flags!

行为标志！

--soft keeps all files staged.

--soft使所有文件暂存。

$ git reset --soft c747e6891af419119fd817dc69a2e122084aedae
$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)
new file:   clean.txt

--mixed is the default: Removes all files from staging area too.

--mixed是默认设置：也从临时区域中删除所有文件。

--hard is hard-core. Deletes files from the object store — and directory as well. Use with extreme caution. There goes my bug fix*. Gone.

--hard是核心。 从对象库和目录中删除文件。 使用时要格外小心。 我的错误修复*。 走了

$ git reset --hard c747e6891af419119fd817dc69a2e122084aedae
HEAD is now at c747e68 resolve merge conflict
$ git status
On branch master
nothing to commit, working tree clean

*Well, not completely. Git is amazing. Have you heard of meta-meta data? A redundancy log of what happened in the repository? Yes, of course git keeps it!

*嗯，不是完全。 Git很棒。 您听说过元数据吗？ 关于存储库中发生了什么的冗余日志？ 是的，git当然会保留它！

$ git reflog
c747e68 (HEAD -> master) HEAD@{0}: reset: moving to c747e6891af419119fd817dc69a2e122084aedae
efc6d21 HEAD@{1}: commit: soft reset
c747e68 (HEAD -> master) HEAD@{2}: reset: moving to c747e6891af419119fd817dc69a2e122084aedae
d8487ca HEAD@{3}: commit: fix bug: Unable to clean folder
c747e68 (HEAD -> master) HEAD@{4}: reset: moving to c747e6891af419119fd817dc69a2e122084aedae
959781e HEAD@{5}: commit: God why isn't this working last final BugFix
affa90c HEAD@{6}: commit: Final Final BugFix
2e9570c HEAD@{7}: commit: Final BugFix
4560fc0 HEAD@{8}: commit: BugFix
c747e68 (HEAD -> master) HEAD@{9}: commit (merge): resolve merge conflict
3d01508 HEAD@{10}: commit: add Master World
b300387 (the-ending) HEAD@{11}: checkout: moving from the-middle to master
fb8b2fc (the-middle) HEAD@{12}: commit: add Middle World
b300387 (the-ending) HEAD@{13}: checkout: moving from master to the-middle
b300387 (the-ending) HEAD@{14}: checkout: moving from the-middle to master
b300387 (the-ending) HEAD@{15}: checkout: moving from master to the-middle
b300387 (the-ending) HEAD@{16}: merge the-ending: Fast-forward
a39b9fd HEAD@{17}: checkout: moving from the-ending to master
b300387 (the-ending) HEAD@{18}: checkout: moving from master to the-ending
a39b9fd HEAD@{19}: checkout: moving from the-ending to master
b300387 (the-ending) HEAD@{20}: commit: add byeworld
a39b9fd HEAD@{21}: checkout: moving from master to the-ending
a39b9fd HEAD@{22}: commit (initial): Add helloworld

This is everything from the beginning of the example in the previous article. Does this mean I can recover things if I made an awful mistake?

这是上一篇文章示例开头的全部内容。 如果我犯了一个严重的错误，这是否意味着我可以康复？

$ git checkout d8487ca
Note: checking out 'd8487ca'.
You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.
If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:
git checkout -b <new-branch-name>
HEAD is now at d8487ca... fix bug: Unable to clean folder

$ ls
byeworld clean.txt  helloworld

There you have it.

你有它。

Congratulations, you’re a Git Ninja — Apprentice now.

恭喜，您是Git Ninja-现在是学徒。

Is there something more you’d like to know about? Something that confused you about Git? Let me know below! I’ll try explaining it the way I learnt it!

您还有其他想知道的事情吗？ 让您感到困惑的Git吗？ 让我在下面知道！ 我将尝试以学习的方式进行解释！

Enjoyed this? Don’t miss a post again — subscribe to my mailing list!

喜欢这个吗？ 不要再错过任何帖子-订阅我的邮件列表！

翻译自: https://www.freecodecamp.org/news/now-that-youre-not-afraid-of-git-anymore-here-s-how-to-leverage-what-you-know-11e710c7f37b/

现有项目 git