常用命令速查：
git init //初始化本地git环境
git clone XXX//克隆一份代码到本地仓库
git pull //把远程库的代码更新到工作台
git pull –rebase origin master //强制把远程库的代码跟新到当前分支上面
git fetch //把远程库的代码更新到本地库
git add . //把本地的修改加到stage中
git commit -m ‘comments here’ //把stage中的修改提交到本地库
git push //把本地库的修改提交到远程库中
git branch -r/-a //查看远程分支/全部分支
git checkout master/branch //切换到某个分支
git checkout -b test //新建test分支
git checkout -d test //删除test分支
git merge master //假设当前在test分支上面，把master分支上的修改同步到test分支上
git merge tool //调用merge工具
git stash //把未完成的修改缓存到栈容器中
git stash list //查看所有的缓存
git stash pop //恢复本地分支到缓存状态
git blame someFile //查看某个文件的每一行的修改记录（）谁在什么时候修改的）
git status //查看当前分支有哪些修改
git log //查看当前分支上面的日志信息
git diff //查看当前没有add的内容
git diff –cache //查看已经add但是没有commit的内容
git diff HEAD //上面两个内容的合并
git reset –hard HEAD //撤销本地修改
echo $HOME //查看git config的HOME路径
export $HOME=/c/gitconfig //配置git config的HOME路径
团队协作git操作流程：
克隆一个全新的项目，完成新功能并且提交：
git clone XXX //克隆代码库
git checkout -b test //新建分支
modify some files //完成修改
git add . //把修改加入stage中
git commit -m ” //提交修改到test分支
review代码
git checkout master //切换到master分支
git pull //更新代码
git checkout test //切换到test分支
git meger master //把master分支的代码merge到test分支
git push origin 分支名//把test分支的代码push到远程库
目前正在test分支上面开发某个功能，但是没有完成。突然一个紧急的bug需要处理
git add .
git stash
git checkout bugFixBranch
git pull –rebase origin master
fix the bug
git add .
git commit -m ”
git push
git checkout test
git stash pop
continue new feature’s development
这里有个更详细的： Git常用命令，很全很详细讲解的也不错
一些小提示：
COMMIT RELATED CHANGES
A commit should be a wrapper for related changes. For example, fixing two different bugs should produce two separate 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
Committing 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
You should only commit code when it‘s completed. This doesn‘t mean you have to complete a whole, large feature before committing. Quite the contrary: split the feature‘s implementation into logical chunks and remember to commit early and often. But don‘t commit just to have something in
the repository before leaving the office 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 «Stash» 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 effects (as far as one can tell).While committing half-baked things in your local repository only requires you to forgive yourself, having your code tested is even more important when it comes to pushing/sharing your code with others.
WRITE GOOD COMMIT MESSAGES
Begin your message with a 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
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
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. ranches 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 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 teammates‘ personal preferences. owever you choose to work, just make sure to agree on a common workflow that everyone follows.
HELP & DOCUMENTATION
Get help on the command line
$ git help
FREE ONLINE RESOURCES
http://www.git-tower.com/learn
http://rogerdudler.github.io/git-guide/
http://www.git-scm.org/
