git准备了您可能每天需要的命令的git速查表

软件 (SOFTWARE)

I use Git every single day.

我每天都使用Git。

So do most software developers.

大多数软件开发人员也是如此。

Honestly, Linus Torvalds’ little side project almost feels like a miracle.

老实说，莱纳斯·托瓦尔兹(Linus Torvalds)的小侧面项目几乎感觉像是一个奇迹。

However, the tool is so powerful and extensive that it’s easy to get lost in all the possible commands it has.

但是，该工具是如此强大和广泛，以至于很容易在其所有可能的命令中迷失方向。

Hence, based on my own experience, here’s a compilation of answers to common questions about “how do you do X with Git” that I’ve encountered on a regular basis. Some of us may even use these solutions on a daily basis.

因此，根据我自己的经验，下面是一些我经常遇到的关于“如何使用Git进行X运算”的常见问题的解答。 我们中有些人甚至可能每天使用这些解决方案。

Indeed, many of the commands addressed here will be rather simple, and often well-known by the majority of developers.

确实，这里解决的许多命令将非常简单，并且通常为大多数开发人员所熟知。

However, I thought this could be beneficial as a one-stop-shop place for remembering that one command you forgot, as well as providing a good foundation for beginners.

但是，我认为这对于记住一处您遗忘的命令可能是一个一站式服务的场所，并且为初学者提供了良好的基础。

If instead you’d prefer to go over a practical deep dive of Git, you can check out this article.

相反，如果您希望对Git进行深入的实际研究，可以查看本文 。

Git速查表🗒 (The Git Cheatsheet 🗒)

在不提交更改的情况下存储更改 (S️toring changes without committing them)

This is a simple one, just run:

这是一个简单的示例，只需运行：

git stash

git stash

Then, to bring back these stored changes, making sure you’re on the same branch, you can run:

然后，要恢复这些存储的更改，并确保您位于同一分支上，可以运行：

git stash apply

git stash apply

摆脱所有未提交的更改 (Getting rid of all uncommitted changes)

Sometimes you want to try something and it just doesn’t work out. To get rid of all changes you made since the last commit, just run:

有时您想尝试一些方法，但效果不佳。 要摆脱自上一次提交以来所做的所有更改，只需运行：

git checkout -- .

git checkout -- .

To only erase changes from specific files or directories, . can be substituted by a list of files and/or directories you wish to erase changes from.

要仅清除特定文件或目录中的更改，请. 可以替换为您希望从中删除更改的文件和/或目录的列表。

将fork与主仓库同步 (Syncing your fork with the main repo)

When you fork a project, it’s important that you keep your fork up-to-date to avoid complicated merge conflicts when you make a pull request, or simply to make sure you have all the new features and security patches.

分支项目时，请务必保持最新状态，以避免在发出请求时出现复杂的合并冲突，或者只是确保具有所有新功能和安全补丁。

As such, here’s how you sync your fork:

因此，这是同步叉子的方法：

1. Add a remote repository

   添加一个远程仓库

Get the address of the upstream (main) repo from where you forked the project. Then run the following, substituting the URL:

从分支的位置获取上游(主)存储库的地址。 然后运行以下命令，替换URL：

git remote add upstream <upstream_repo_url>

You can check that this worked by running git remote -v .

您可以通过运行git remote -v来检查是否有效。

2. Sync the fork with the upstream repo

2.将fork与上游仓库同步

To sync the fork, fetch the upstream repo:

要同步派生，请获取上游存储库：

git fetch upstream

Then, on the branch you wish to sync with (generally master), run:

然后，在您要与之同步的分支上(通常是master )，运行：

git merge upstream/master

Or git rebase upstream/master depending on your strategy of choice.

或git rebase upstream/master根据您选择的策略对git rebase upstream/master进行基准调整。

删除最后的X次提交 (Erase the last X commits)

Made some commits that you ended up needing to revert? You can do so in two ways:

做出一些您最终需要还原的提交？ 您可以通过两种方式进行操作：

git reset HEAD~2 # undo the commits but keep the changesgit reset --hard HEAD~2 # undo the commits and discard changes

With the second option, it will be as if the commits never happened.

使用第二个选项，就好像提交从未发生过。

You should replace the 2 with the number of commits you wish to go back from the latest commit (HEAD).

您应该将2替换为您希望从最新提交(HEAD)返回的提交数。

将各种提交压缩为一个(无需重新设置！) (Squash various commits into one (without rebase!))

If you want to get rid of all your "fix typo" commits and join them all together into one, you can do so with:

如果您想摆脱所有的"fix typo"提交，并将它们全部合并为一个，则可以使用以下方法：

git reset --soft HEAD~2 && git commit -m "your message"

Remember to replace the 2 with the number of commits you want to squash counting from the HEAD.

请记住将2替换为您要从HEAD计数的提交次数。

在上一次提交时签出项目的状态 (Checkout the state of the project at a past commit)

To go back in time and see the state of your project at a given commit in the past, first run git log to see the commit history and select the commit you wish to go back to.

要返回过去查看过去一次给定提交的项目状态，请首先运行git log查看提交历史记录，然后选择要返回的提交。

Then, copy its hash and simply run git checkout <commit_hash> . This will leave you in “detached head” mode. To go back, just checkout the branch by name.

然后，复制其哈希并仅运行git checkout <commit_hash> 。 这将使您处于“分离头”模式。 要返回，只需按名称checkout出分支即可。

忽略已经添加到Git的文件 (Ignoring a file you already added to Git)

We’ve all been there — adding or committing something we shouldn’t have. To remove the file from Git tracking while keeping it in the system, just do:

我们到过那里-添加或提交我们不应该拥有的东西。 要将文件从Git跟踪中删除并保留在系统中，只需执行以下操作：

git reset <file> && echo <file> >> .gitignore

提交后添加到提交中 (Adding to a commit after committing)

If you want to change your commit message, or add a new file to it, you can use git ammend .

如果要更改提交消息或向其中添加新文件，可以使用git ammend 。

To change the message, use:

要更改消息，请使用：

git commit --amend -m "<new_message>"

And to add a new file to the last commit:

并向上一次提交添加新文件：

git add <file> && git commit --amend

Note that this “saves you the trouble of creating a new commit”, but in fact does create a new commit under the hood. Hence, you should only be doing this if you haven’t pushed the changes to the remote repo yet.

请注意，这“省去了创建新提交的麻烦”，但实际上确实在后台创建了新提交。 因此，只有在尚未将更改推送到远程存储库时，才应该这样做。

从Git删除文件并修剪其整个历史记录 (Removing a file from Git and pruning its entire history)

If you ever push sensitive data to a remote repository (e.g. on GitHub), you’ll not only need to remove the file from Git tracking, but also delete its entire history.

如果您曾经将敏感数据推送到远程存储库(例如，在GitHub上)，则不仅需要从Git跟踪中删除文件，还需要删除其整个历史记录。

You should also not use that data anymore if at all possible, such as in the case of API keys, passwords, etc.

如果可能的话，也不要再使用该数据，例如在使用API​​密钥，密码等的情况下。

The process for doing so isn’t the simplest, but GitHub has written a full-page tutorial about it, so I thought I should just link it here instead.

这样做的过程并不是最简单的，但是GitHub已经编写了一个全页的教程，因此我认为我应该在这里链接它。

“Removing sensitive data from a repository — GitHub”.

“从存储库中删除敏感数据-GitHub” 。

记录合并冲突解决方案 (Record merge conflict resolutions)

To avoid having to resolve the same exact merge conflicts multiple times, you can enable a Git cache of merge conflict resolution. This will store how a merge conflict was resolved and automatically resolve the same conflict if it comes up again:

为了避免多次解决相同的确切合并冲突，可以启用合并冲突解决方案的Git缓存。 这将存储合并冲突的解决方式，如果再次出现，将自动解决相同的冲突：

git config --global rerere.enabled true

Read more about this on the Git Docs.

在Git Docs上了解有关此内容的更多信息。

错误分支上的提交 (Commits made on the wrong branch)

If you made a commit on the wrong branch, you should be able to use our knowledge about erasing commits to solve the problem, like so:

如果您在错误的分支上进行了提交，则应该能够使用我们有关删除提交的知识来解决问题，例如：

git branch <new_branch> && git reset HEAD~2 --hard 

This will create a new branch and delete the specified number of commits from the current branch where you wrongly added the commits.

这将创建一个新分支，并从您错误地添加了提交的当前分支中删除指定数量的提交。

If you actually want these commits on an existing branch rather than a new one, then you can do:

如果您实际上希望这些提交在现有分支上而不是在新分支上进行，则可以执行以下操作：

git checkout <desired_branch> && git merge <branch_with_commits>
git checkout 

And yet, if merging is not an option, you can use git cherry-pick , like so:

但是，如果不能合并，则可以使用git cherry-pick ，如下所示：

git checkout <desired_branch>
git cherry-pick <branch_with_commits> <branch_with_commits>~2
git checkout 

更改分支名称 (Changing a branch name)

To change the name of a branch, use git branch -m . You can either change the name of the current branch:

要更改分支的名称，请使用git branch -m 。 您可以更改当前分支的名称：

git branch -m <new_name>

Or change the name of any branch:

或更改任何分支的名称：

git branch -m <old_name> <new_name>

查找带有错误的提交 (Finding the commit with a bug)

If you run into an issue that you know is unrelated to your commit, you’ll need to determine what commit in the past introduced this problem. This is common with tests, for example, when they aren’t passing due to a test completely unrelated to your work.

如果您遇到与提交无关的问题，则需要确定过去哪种提交导致了此问题。 这在测试中很常见，例如，由于测试与您的工作完全无关而无法通过时。

In this case, to find the “bad” commit, you can use git bisect .

在这种情况下，要查找“错误”的提交，可以使用git bisect 。

The way it works is as follows:

它的工作方式如下：

1. Start the process

   开始过程

git bisect start

2. Mark the current commit as “bad”

2.将当前提交标记为“不良”

git bisect bad

3. Mark a commit in the past as “good”

3.将过去的提交标记为“良好”

Find a commit in the past, using git log for example, where things were as intended (i.e. good). Then, run:

例如，使用git log查找过去的提交，如预期的那样(即良好)。 然后，运行：

git bisect good <commit_hash>

4. Get bisecting!

4.平分秋色！

You should now get a message like this:

您现在应该收到以下消息：

Bisecting: 2 revisions left to test after this (roughly 3 steps)

The numbers, hash, and branch name will naturally be different for you.

数字，哈希和分支名称自然会与您不同。

Here, what Git is doing is going through your commits one by one, until you find the one which is broken. You don’t need to run git checkout as that’s being handled for you.

在这里，Git正在做的事情是一步一步地完成提交，直到找到被破坏的提交为止。 您不需要运行git checkout因为这已为您处理。

At every commit, you should then check if things are OK. If they aren’t, mark the commit as bad with git bisect bad . If they are, mark it as good with git bisect good .

在每次提交时，都应检查一切是否正常。 如果不是，请使用git bisect bad将提交标记为git bisect bad 。 如果是，则使用git bisect good将其标记为git bisect good 。

Once you mark a commit as good, Git will take you to the first “bad” commit (i.e. the last one you marked as bad) so you can properly investigate the error. Once you’re done, just go back to the HEAD of the branch by checking the branch out ( git checkout <branch> ) and fix the issues.

将提交标记为良好后，Git会将您带入第一个“不良”提交(即，您标记为不良的最后一个)，以便您可以正确地调查错误。 完成后，只需通过签出分支( git checkout <branch> )返回分支的HEAD并解决问题。

This is it from me today. Git is an awesome tool and I hope this cheatsheet helps you with some of the problems you may encounter along the way.

今天是我给的。 Git是一个很棒的工具，我希望这个备忘单可以帮助您解决一路上可能遇到的一些问题。

It definitely does not cover everything you need to know, but it’s a good start.

它绝对不会涵盖您需要了解的所有内容，但这是一个好的开始。

Thanks for reading and let me know about your favorite Git commands in response to this article.

感谢您的阅读，并在回复本文时让我知道您最喜欢的Git命令。

翻译自: https://medium.com/swlh/git-ready-a-git-cheatsheet-of-commands-you-might-need-daily-8f4bfb7b79cf