git 命令git 地址

by Sam Corcos

由Sam Corcos

这是我上周使用的所有Git命令及其作用。 (Here are all the Git commands I used last week, and what they do.)

Like most newbies, I started out searching StackOverflow for Git commands, then copy-pasting answers, without really understanding what they did.

像大多数新手一样，我开始在StackOverflow上搜索Git命令，然后复制粘贴答案，而不真正了解它们的作用。

I remember thinking, “Wouldn’t it be nice if there were a list of the most common Git commands along with an explanation as to why they are useful?”

我记得在想 “如果有最常用的Git命令列表以及它们为什么有用的解释，这会很好吗？”

Well, here I am years later to compile such a list, and lay out some best practices that even intermediate-advanced developers should find useful.

好吧，几年后，我在这里编译了这样一个列表，并列出了一些最佳实践，即使是中高级的开发人员也应该找到有用的。

To keep things practical, I’m basing this list off of the actual Git commands I used over the past week.

为了使事情变得实用，我以上周使用的实际Git命令为基础列出了该列表。

Almost every developer uses Git, and most likely GitHub. But the average developer probably only uses these three commands 99% of the time:

几乎每个开发人员都使用Git，最有可能使用GitHub。但是一般的开发人员可能仅在99％的时间中使用以下三个命令：

git add --allgit commit -am "<message>"git push origin master

That’s all well and good when you’re working on a one-person team, a hackathon, or a throw-away app, but when stability and maintenance start to become a priority, cleaning up commits, sticking to a branching strategy, and writing coherent commit messages becomes important.

当您在一个人团队，黑客马拉松或一次性应用中工作时，这一切都很好，但是当稳定和维护开始成为首要任务时，清理提交，坚持分支策略并编写一致的提交消息变得很重要。

I’ll start with the list of commonly used commands to make it easier for newbies to understand what is possible with Git, then move into the more advanced functionality and best practices.

我将从常用命令列表开始，以使新手更容易理解Git的功能，然后进入更高级的功能和最佳实践。

常用命令 (Regularly used commands)

To initialize Git in a repository (repo), you just need to type the following command. If you don’t initialize Git, you cannot run any other Git commands within that repo.

要在存储库(仓库)中初始化Git，只需输入以下命令。如果不初始化Git，则无法在该存储库中运行任何其他Git命令。

git init

If you’re using GitHub and you’re pushing code to a GitHub repo that’s stored online, you’re using a remote repo. The default name (also known as an alias) for that remote repo is origin. If you’ve copied a project from Github, it already has an origin. You can view that origin with the command git remote -v, which will list the URL of the remote repo.

如果您使用的是GitHub，并且要将代码推送到在线存储的GitHub存储库中，那么您使用的是远程存储库。该远程仓库的默认名称(也称为别名)为origin 。如果您从Github复制了一个项目，则该项目已经有一个origin 。您可以使用命令git remote -v查看该来源，该命令将列出远程仓库的URL。

If you initialized your own Git repo and want to associate it with a GitHub repo, you’ll have to create one on GitHub, copy the URL provided, and use the command git remote add origin <URL>, with the URL provided by GitHub replacing “<URL>”. From there, you can add, commit, and push to your remote repo.

如果您初始化了自己的Git存储库并将其与GitHub存储库相关联，则必须在GitHub上创建一个Git存储库，复制提供的URL，然后使用git remote add origin <U RL>命令，以及GitHub替换“ <URL>”。从那里，您可以添加，提交并推送到您的远程仓库。

The last one is used when you need to change the remote repository. Let’s say you copied a repo from someone else and want to change the remote repository from the original owner’s to your own GitHub account. Follow the same process as git remote add origin, except use set-url instead to change the remote repo.

最后一个用于需要更改远程存储库的情况。假设您从其他人那里复制了一个存储库，并且想要将远程存储库从原始所有者的更改为您自己的GitHub帐户。遵循与git remote add origin相同的过程，除了使用set-url来更改远程仓库。

git remote -vgit remote add origin <url>git remote set-url origin <url>

The most common way to copy a repo is to use git clone, followed by the URL of the repo.

复制存储库最常见的方法是使用git clone，然后是存储库的URL。

Keep in mind that the remote repository will be linked to the account from which you cloned the repo. So if you cloned a repo that belongs to someone else, you will not be able to push to GitHub until you change the origin using the commands above.

请记住，远程存储库将链接到克隆存储库的帐户。因此，如果您克隆了属于其他人的存储库，那么您将无法将其推送到GitHub，除非您使用上述命令更改了源。

git clone <url>

You’ll quickly find yourself using branches. If you don’t understand what branches are, there are other tutorials that are much more in-depth, and you should read those before proceeding (here’s one).

您会很快发现自己使用分支机构。如果您不了解什么是分支，那么还有其他一些教程会更加深入，您应该在继续之前阅读这些教程( 这是 )。

The command git branch lists all branches on your local machine. If you want to create a new branch, you can use git branch <name>, with &lt;name> representing the name of the branch, such as “master”.

命令git branch列出了本地计算机上的所有分支。如果要创建新分支，则可以使用git branch <na me>， 其中＆ lt; name>代表分支的名称，例如“ master”。

The git checkout <name> command switches to an existing branch. You can also use the git checkout -b <name> command to create a new branch and immediately switch to it. Most people use this instead of separate branch and checkout commands.

git checkout <na me>命令切换到现有分支。您还可以使用git checkout -b＆ lt; name>命令来创建一个新分支，并立即切换到该分支。大多数人使用此命令而不是单独的分支和签出命令。

git branchgit branch <name>git checkout <name>git checkout -b <name>

If you’ve made a bunch of changes to a branch, let’s call it “develop”, and you want to merge that branch back into your master branch, you use the git merge <branch> command. You’ll want to checkout the master branch, then run git merge develop to merge develop into the master branch.

如果您对分支进行了很多更改，我们将其称为“开发”，并且想要将该分支合并回主分支，请使用git merge <bran ch>命令。你会娃NT以CH eckout主分支中，n运行git合并d evelop合并发展成为主分支。

git merge <branch>

If you’re working with multiple people, you’ll find yourself in a position where a repo was updated on GitHub, but you don’t have the changes locally. If that’s the case, you can use git pull origin <branch> to pull the most recent changes from that remote branch.

如果您与多个人一起工作，您会发现自己在GitHub上更新了一个仓库的位置，但是本地没有这些更改。在这种情况下，可以使用git pull origin <bran ch>从该远程分支中提取最新更改。

git pull origin <branch>

If you’re curious to see what files have been changed and what’s being tracked, you can use git status. If you want to see how much each file has been changed, you can use git diff to see the number of lines changed in each file.

如果您想知道哪些文件已更改以及正在跟踪什么，可以使用git status 。如果要查看每个文件已更改了多少 ，可以使用git diff查看每个文件中更改的行数。

git statusgit diff --stat

高级命令和最佳做法 (Advanced commands and best practices)

Soon you reach a point where you want your commits to look nice and stay consistent. You might also have to fiddle around with your commit history to make your commits easier to comprehend or to revert an accidental breaking change.

很快，您就可以使提交看起来不错并保持一致。您可能还必须弄乱自己的提交历史记录，以使您的提交更易于理解或还原意外的重大更改。

The git log command lets you see the commit history. You’ll want to use this to see the history of your commits.

git log命令可让您查看提交历史记录。您将要使用它来查看提交的历史记录。

Your commits will come with messages and a hash, which is random series of numbers and letters. An example hash might look like this: c3d882aa1aa4e3d5f18b3890132670fbeac912f7

您的提交将带有消息和哈希，哈希是由数字和字母组成的随机序列。示例哈希可能看起来像这样： c3d882aa1aa4e3d5f18b3890132670fbeac912f7

git log

Let’s say you pushed something that broke your app. Rather than fix it and push something new, you’d rather just go back one commit and try again.

假设您推送了一些破坏您应用程序的内容。与其修复并推送新内容，不如回退一次提交然后重试。

If you want to go back in time and checkout your app from a previous commit, you can do this directly by using the hash as the branch name. This will detach your app from the current version (because you’re editing a historical record, rather than the current version).

如果您想回到过去并从上一次提交中签出您的应用程序，则可以直接使用哈希作为分支名称来执行此操作。这会将您的应用程序与当前版本分离(因为您正在编辑历史记录，而不是当前版本)。

git checkout c3d88eaa1aa4e4d5f

Then, if you make changes from that historical branch and you want to push again, you’d have to do a force push.

然后，如果您从该历史分支进行了更改并且想要再次推送，则必须进行强制推送。

Caution: Force pushing is dangerous and should only be done if you absolutely must. It will overwrite the history of your app and you will lose whatever came after.

小心：用力推动是危险的，只有在绝对必要时才应这样做。它将覆盖您的应用程序的历史记录，您将失去所有后续内容。

git push -f origin master

Other times it’s just not practical to keep everything in one commit. Perhaps you want to save your progress before trying something potentially risky, or perhaps you made a mistake and want to spare yourself the embarrassment of having an error in your version history. For that, we have git rebase.

在其他时候，将所有内容保持在一次提交中是不切实际的。也许您想在尝试可能有风险的操作之前保存进度，或者您犯了一个错误，并且想避免在版本历史记录中出现错误的尴尬。为此，我们有git rebase 。

Let’s say you have 4 commits in your local history (not pushed to GitHub) in which you’ve gone back and forth. Your commits look sloppy and indecisive. You can use rebase to combine all of those commits into a single, concise commit.

假设您在本地历史记录中有4次提交(未推送到GitHub)，在这些提交中来回走了。您的提交看起来很草率，犹豫不决。您可以使用rebase将所有这些提交合并为一个简洁的提交。

git rebase -i HEAD~4

The above command will open up your computer’s default editor (which is Vim unless you’ve set it to something else), with several options for how you can change your commits. It will look something like the code below:

上面的命令将打开计算机的默认编辑器(除非已将Vim设置为其他名称，否则将为Vim)，其中包含用于更改提交的几种选项。它看起来像下面的代码：

pick 130deo9 oldest commit messagepick 4209fei second oldest commit messagepick 4390gne third oldest commit messagepick bmo0dne newest commit message

In order to combine these, we need to change the “pick” option to “fixup” (as the documentation below the code says) to meld the commits and discard the commit messages. Note that in vim, you need to press “a” or “i” to be able to edit the text, and to save and exit, you need to type the escape key followed by “shift + z + z”. Don’t ask me why, it just is.

为了将这些结合起来，我们需要将“ pick”选项更改为“ fixup”(如代码下面的文档所述)，以合并提交并丢弃提交消息。请注意，在vim，你需要按“ 一 ”或“ 我 ”才能够编辑文本，保存并退出，则需要键入转义键，然后按“Shift + Z + Z”。 不要问我为什么，就是这样。

pick 130deo9 oldest commit messagefixup 4209fei second oldest commit messagefixup 4390gne third oldest commit messagefixup bmo0dne newest commit message

This will merge all of your commits into the commit with the message “oldest commit message”.

这会将您所有的提交合并到带有“最早提交消息”消息的提交中。

The next step is to rename your commit message. This is entirely a matter of opinion, but so long as you follow a consistent pattern, anything you do is fine. I recommend using the commit guidelines put out by Google for Angular.js.

下一步是重命名您的提交消息。这完全是一个见解，但是只要您遵循一致的模式，您所做的任何事情都可以。我建议使用Google针对Angular.js提出的提交准则。

In order to change the commit message, use the amend flag.

为了更改提交消息，请使用amend标志。

git commit --amend

This will also open vim, and the text editing and saving rules are the same as above. To give an example of a good commit message, here’s one following the rules from the guideline:

这也将打开vim，并且文本编辑和保存规则与上述相同。为了给出良好的提交消息的示例，以下是遵循准则的规则之一：

feat: add stripe checkout button to payments page

- add stripe checkout button- write tests for checkout

One advantage to keeping with the types listed in the guideline is that it makes writing change logs easier. You can also include information in the footer (again, specified in the guideline) that references issues.

与指南中列出的类型保持一致的一个优点是，它使编写更改日志更加容易。您还可以在页脚 (同样，在指南中指定)中包含引用问题的信息。

Note: you should avoid rebasing and squashing your commits if you are collaborating on a project, and have code pushed to GitHub. If you start changing version history under people’s noses, you could end up making everyone’s lives more difficult with bugs that are difficult to track.

注意：如果您在一个项目上进行协作，并且代码已推送到GitHub，则应避免重新提交和压缩提交。如果您开始在人们的眼皮底下更改版本历史记录，最终可能会因难以跟踪的错误而使每个人的生活更加困难。

There are an almost endless number of possible commands with Git, but these commands are probably the only ones you’ll need to know for your first few years of programming.

Git几乎有无数种可能的命令，但是这些命令可能是您在编程的头几年中唯一需要知道的命令。

Sam Corcos is the lead developer and co-founder of Sightline Maps, the most intuitive platform for 3D printing topographical maps, as well as LearnPhoenix.io, an intermediate-advanced tutorial site for building scalable production apps with Phoenix and React.

Sam Corcos是Sightline Maps (用于3D打印地形图的最直观的平台)以及LearnPhoenix.io (用于使用Phoenix和React构建可扩展的生产应用程序的中级高级教程网站)的首席开发人员和共同创始人。