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構建可擴展的生產應用程序的中級高級教程網站)的首席開發人員和共同創始人。