git 入門教程之備忘錄[譯]

時間 2019-12-09

標籤 git 入門教程備忘錄欄目 Git 简体版

原文原文鏈接

備忘錄[譯]

建立 | Create

克隆一個已存在的倉庫 | Clone an existing repository

git clone git@github.com:snowdreams1006/snowdreams1006.github.io.git

建立一個新的本地倉庫 | Create a new local repository

git init

本地更改 | Local Changes

工做目錄中已更改文件 | Changed files in your working directory

git status

已追蹤文件的更改 | Changes to tracked files

git diff

添加當前所有更改到下次提交版本 | Add all current changes to next commit

git add .

添加文件中某些更改到下次提交版本 | Add some changes in to next commit

git add -p <file>

提交已追蹤文件的所有本地更改 | Commit all local changes in tracked files

git commit -a

提交上一次暫存區更改 | Commit previously staged changes

git commit

更改上次提交 | Change the last commit

沒有更改已發佈的提交 | Don't amend publishd commits!git

git commit --amend

提交歷史 | Commit history

顯示所有提交,以最新的開頭 | Show all commits,starting with newest

git log

顯示某個文件一段時間內的更改 | Show changes over time for a specific file

git log -p <file>

某文件是誰在何時更改了什麼內容 | Who changed what and when in

git blame <file>

分支和標籤 | Branches & Tags

列出所有已存在的分支 | List all existing branches

git branch -av

切換到 HEAD 分支 | Switch HEAD branch

git checkout <branch>

基於當前 HEAD 建立新分支 | Create a new branch based on your curent HEAD

git branch <new-branch>

基於遠程分支建立新的正在追蹤分支 | Create a new tracking branch based on a remote branch

git checkout --track <remote/branch>

刪除一個本地分支 | Delete a local branch

git branch -d <branch>

爲當前提交打上標籤 | Make the current commit with a tag

git tag <tag-name>

更新和發佈 | Update & Publish

列出當前所有已配置的遠程倉庫 | List all currently configured remotes

git remote -v

顯示遠程倉庫信息 | Show information about a remote

git remote show <remote>

添加的遠程倉庫 | Add new remote repository named

git remote add <shortname> <url>

下載來自遠程倉庫的全部更改可是不合併到 HEAD | Download all changes from but don't integrate into HEAD

git fetch <remote>

下載來自遠程倉庫指定分支的全部更改而且自動合併到 HEAD | Download changes and directly merge/integrate into HEAD

git pull <remote> <branch>

在遠程倉庫上發佈本地更改 | Publish local changes on a remote

git push <remote> <branch>

在遠程倉庫上刪除分支 | Delete a branch on the branch

git branch -dr <remote/branch>

發佈你的標籤 | Publish your tags

git push --tags

合併和變基 | MERGE & REBASE

合併指定分支到你的 HEAD | Merge into your current HEAD

git merge <branch>

變基到當前HEAD | Rebase your current HEAD onto

不要變基已發佈的提交 | Don't rebase published commits!github

git rebase <branch>

取消變基 | Abort a rebase

git rebase --abort

使用已配置的衝突工具去解決衝突 | Use your configured merge tool to solve conflicts

git mergetool

使用編輯器手工解決衝忽然後(解決以後)標記文件已解決衝突 | Use your editor to manually solve conflicts and (after resolving) mark file as resolved

git add <resolved-file>
git rm <resolved-file>

撤銷 | UNDO

丟棄工做區所有更改 | Discard all local changes in your working directory

git reset --hard HEAD

丟棄指定文件的本地更改 | Discard local changes in a specific file

git checkout HEAD <file>

抵消一個提交(經過產生一個新的相反的提交) | Revert a commit (by producing a new commit with contrary changes)

git revert <file>

重置當前 HEAD 指針到上一個提交...而後丟棄自那之後的所有更改 | Reset your HEAD pointer to a previous commit ... and discard all changes since then

git reset --hard <commit>

...而後做爲未緩存更改保存所有更改 | ... and preserve all changes as unstaged change

git reset <commit>

...而後保存未提交的本地更改 | ... and preserve all changes as unstaged change

git reset --keep <commit>

建議 | SUGGESTION

提交應該是相關更改的包裝,例如,修復兩個不一樣的 bug 應該產生兩個單獨的提交.
小的提交讓其餘開發者更容易理解這次更改,而且萬一出錯方便回滾.
在暫存區這類工具以及暫存部分文件的能力下,git 很容易建立細粒度的提交.緩存

A commit should be a wrapper for related changes,
For example,fixing two different bugs should produce two separete commits.
Small commits make it easier for other developers to understand the changes and roll them back if something went wrong.
With tools like the staging area and the ability to stage only parts of a file.
Git makes it easy to create very granular commits.服務器

常常提交 | COMMIT OFTEN

常常提交使得你的提交很小而且有助於僅提交相關更改.
此外,這樣容許你更頻繁地和其餘人分享你的代碼,對於每一個人來講更容器按期合併更改,避免了遭遇合並衝突.
,不多的大提交,不多分享它們.相反很難解決衝突.app

Commiting often keeps your commits small and again helps you commit only related changes.
Moreover,it allows you to share your code more frequently with others.
That way it's easier for everyone to integrate changes regularly and avoid having merge conflicts.Having few large commits and sharing them rarely.in contrast,makes it hard to solve conflicts.編輯器

不要提交未完成工做 | DON'T COMMIT HALF-DONE WORK

你應該僅提交已完成代碼,這並不意外着提交前你不得不完成一個完整的,很大的功能分支.偏偏相反,將功能分支劃分紅不少邏輯塊而且記得早一點,頻繁些提交.
若是僅僅是爲了下班前倉庫該有點什麼就不要提交,若是你嘗試提交僅僅是由於你須要一個乾淨的工做副本(檢出分支,拉取更改),考慮使用 git 的 stash 特性.ide

You should only commit code when it's completed.
This doesn't mean you have to complete a whole ,large feature before commiting.
Quite the contrary:split the feature's implementatiion into logical chunks and remember to commit early and often.
But don't commit just to have something in the repository before leaving the ofice at the end of the day.
If you're tempted to commit just because you need a clean working copy (to check out a branch,pull in changes ,etc.) consider using Git's feature instead. 工具

提交前測試代碼 | TEST CODE BEFORE YOU COMMIT

抵制自覺得已完成的提交.
直接測試來確保它真的已完成而且沒有反作用(顯而易見的).
當提交半成品到本地倉庫時要求你不得不自我諒解,讓你的代碼進過測試對發佈或者分享你的代碼也很重要.學習

Resist the temptation to commit something that you think is completed.
Test it thoroughly to make sure it really is completed and has no side effect (as far as one can tell).
While committing half-baked thing in your local repository only requires you to forgive yourself,having your code tested is even more important when it comes to publishing/sharing your code with others.測試

編寫代碼提交信息 | WRITE CODE COMMIT MESSAGE

對你的更改以簡短總結進行描述(達到50字符做爲準則).
以包括空白行做爲分割下述內容.
提交信息體應該提供下述問題的詳細答案:

這次更改的動機是什麼?
和上一個實現有什麼不一樣?

使用必要的如今時語態(更改,不是已更改,或者變動)和使用形如 git merge 命令生成的信息保持一致.

Begin your message with short summary of your changes(up to 50 characters as a guideline).
Separate it from the following body by including a blank line.
The body of your message should provide detailed answers to the following questions:

What was the motivation for the change?
How does it differ from the previous implementation?

Use the imperative ,present tense(change,not changed or changes) to be consistent with generated messages from commands like git merge.

版本控制不是一個備份系統 | VERSION CONTROL IS NOT A BACKUP SYSTEM

在遠程服務器存有文件的備份是版本控制系統的一個很好反作用.可是你不該該將VCS 視爲一個備份系統.
當作版本控制時,你應該注意語義化提交,而不是死記硬背文件.

Having your files backed up on a remote server is a nice side effect of having a version control system.
But you should not use your VCS like it was a backup system.
When doing version control,you should pay attention to committing semantically(see related changes) - you shouldn't just cram in files.

利用分支 | USE BRANCHES

分支是 git 最強大的特性之一,這不是偶然.
從第一天開始快速而簡單的分支就是一個核心需求.
分支是幫助你避免弄混不一樣開發線的完美工具.
在你的開發流程中應該普遍使用分支,像新功能,修復 bug,新想法...

Branching is one of Git's most powerful features-and this is not by accident:quick and easy branching was a central requirement from day one.
Branches are the perfect tool to help you avoid mixing up different lines of development.
You should use branches extensively in your development workflows:for new features,bug fixes,ideas...

認同工做流 | AGREE ON A WORKFLOW

Git 容許你從大量不一樣的工做流中選擇一個:長期運行的分支,主題分支,合併或變,基工做流...
具體選擇哪個取決於一系列因素:你的項目,你的整體開發和部署工做流和(多是最重要的)你和你的團隊的我的偏好.
不論你選擇哪個去工做,你須要確保準守一個你們都認同的工做流.

Git lets you pick from a lot of different workflows:long-running branches,topic branches,merge or rebase,git-flow...
Which one you choose depends on a couple of factors:your project,your overall development and deployment workflows and (maybe most importantly ) on your and your teammate's personal preferences.
However you choose to work,just make sure to agree on a common workflow that everyone follows.