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 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!

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

提交相关更改 | COMMIT RELATED CHANGES

提交应该是相关更改的包装,例如,修复两个不一样的 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

常常提交使得你的提交很小而且有助于仅提交相关更改.
此外,这样容许你更频繁地和其余人分享你的代码,对于每一个人来讲更容器按期合并更改,避免了遭遇合并冲突.
,不多的大提交,不多分享它们.相反很难解决冲突.

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 特性.

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.

帮助和文档 | HELP & DOCUMENTATION

命令行下获取 git 帮助

git help <command>

Git help on the command line

git help <command>

免费在线资源 | FREE ONELINE RESOURCES

• http://www.git-tower.com/learn
• http://rogerdudler.github.io/git-guide/
• http://www.git-scm.org/

本文版权归原做者全部，翻译仅用于学习。