git add .
git add -p <file>
git commit -a
没有更改已发布的提交 | Don't amend publishd commits!
git commit --amend
git log -p <file>
git blame <file>
git branch -av
git checkout <branch>
git branch <new-branch>
git checkout --track <remote/branch>
git branch -d <branch>
git tag <tag-name>
git remote -v
git remote show <remote>
git remote add <shortname> <url>
git fetch <remote>
git pull <remote> <branch>
git push <remote> <branch>
git branch -dr <remote/branch>
git push --tags
git merge <branch>
不要变基已发布的提交 | Don't rebase published commits!
git rebase <branch>
git rebase --abort
git add <resolved-file>
git rm <resolved-file>
git reset --hard HEAD
git checkout HEAD <file>
git revert <file>
git reset --hard <commit>
git reset <commit>
git reset --keep <commit>
提交应该是相关更改的包装,例如,修复两个不同的 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.
经常提交使得你的提交很小并且有助于仅提交相关更改. 此外,这样允许你更频繁地和其他人分享你的代码,对于每个人来说更容器定期合并更改,避免了遭遇合并冲突. ,很少的大提交,很少分享它们.相反很难解决冲突.
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.
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.
抵制自以为已完成的提交. 直接测试来确保它真的已完成并且没有副作用(显而易见的). 当提交半成品到本地仓库时要求你不得不自我谅解,让你的代码进过测试对发布或者分享你的代码也很重要.
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.
对你的更改以简短总结进行描述(达到50字符作为准则). 以包括空白行作为分割下述内容. 提交信息体应该提供下述问题的详细答案:
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(
changes) to be consistent with generated messages from commands like git merge.
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
VCSlike 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.
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...
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.
git help <command>
Git help on the command line
git help <command>