1、从远程分支拉取代码
git pull <远程主机名> <远程分支名> : <本地分支名> 如果当前分支就是本地分支，那么冒号后面的就可以省略。如果当前分支与远程分支存在追踪关系，就可以省略远程分支名 git pull origin ；如果当前分支只有一个追踪分支，那么连远程主机名也可以省略 git pull 。 如果远程主机删除了某个分支，git pull 不会在拉取分支的时候删除对应的本地分支，为了防止其他人操作了远程主机导致git pull 不知不觉删除了本地分支，但是 git pull 加上参数 -p 就会在本地删除远程已经删除的分支。
git fetch <远程主机名> <远程分支名> 从远程获取最新版本到本地
git pull 与 git fetch 的区别：
git fetch <远程主机名> <分支名>从远程获取最新版本到本地但是不会自动merge ，需要手动去merge 。eg: git fetch origin master ; git log -p master ..origin/master比较本地的master分支和origin/master分支的差别 ; git merge origin/master 。在某些场合，git会自动在远程分支和本地分支之间建立一种追踪（tracking）关系。eg：在git clone的时候，所有本地分支默认与远程主机的同名分支建立追踪关系，也就是说本地的分支（例如：master）会自动追踪同名的远程分支（例如：origin/master）. git页允许手动建立追踪关系 eg： git branch --set-upstream master origin/test 本地master 分支与远程 test分支建立追踪关系
git pull <远程主机名> <分支名> 从远程获取分支并自动与本地分支merge 。
2.提交修改
git add . 添加当前修改的文件到暂存区
git add -u 自动追踪文件，包括手动删除的文件和状态为deleted的文件
git commit -m '提交说明' 提交本次的修改。
注！！可以用 git commit -a -m '提交说明' 命令替代 git add 和 git commit -m '提交说明' 两个命令。
git push <远程主机名> <本地分支名> : <远程分支名> 将当前的更新推送到远程的分支 。如果省略[远程分支名] 默认是将当前所在的本地分支的更新推送到与之有追踪关系的远程分支，如果该远程分支不存在，就会被新建。如果省略本地分支名，则表示删除指定的远程分支 git push origin :master ,这等同于推送一个空的分支到远程master分支。如果当前分支与远程分支之间存在追踪关系，则本地分支名和远程分支名都可以省略 git push origin 。如果当前分支只有一个追踪分支，那么主机名也可以省略 git push 。如果当前分支与多个主机存在追踪关系，那么可以使用参数 -u 选项设定一个默认的主机，这样就可以不加审核参数使用git push 。
不带参数的git push 默认只推送当前分支，这叫做simple方式，另外，还有matching 方式，会推送所有有对应的远程分支的本地分支。可以采用git config 修改这个设置。git config--global push.default matching 或者git config--global push.default simple
还有一种情况就是不管是否存在对应的远程分支，将本地所有的分支推送到远程主机 git push --all origin
git push --force origin 将当前分支强制推送到远程主机。使用--force选项，结果会导致远程主机上更新的版本被覆盖。
git push不会推送标签（tag），除非使用--tags选项。git push origin--tags
3. git status 查看文件的状态
4. git rm 文件名 从当前跟踪列表中删除文件，并完全删除。
5. git rm -cached 文件名 仅在暂存区删除，保留文件在当前的目录，不在跟踪。
6. git log 查看提交的历史
7. git commit --amend 修改最后一次提交的注释。
8. 假如已经使用git add . 将已经被修改过的a、b文件添加到暂存区，现在只想提交a文件，不想提交b文件。 git rebase HEAD b
9. 分支管理
git branch 分支名 创建分支
git branch -r 查看远程分支 git branch -a 查看所有分支
git checkout 分支名 切换到 分支
git pull = git fetch + git merge; git pull --rebase = git fetch + git rebase.
git rebase 与git merge 区别：
（1）log history 不同： rebase是干净的，log history 是线性的，但commit不是按照日期排序，而是local history 总在后面 。merge之后history变得比较复杂，但是commit按日期排序。
（2）如果对于同一个分支两个人都在改，那么合并的时候就不要用merge 最好用rebase，即，使用git pull --rebase 而不是 git pull。git merge会把你的commit 和另一个人的commit 重新合成一个庞大的commit 提交了，这个庞大的commit里有你和另一个人的commit的history，提交后就会有很多的commit。所以要用改用rebase。（如果两个分支都有commit，最好也用rebase）
（3）应用场景不同：
场景一：有一个A 分支，而你在A分支的基础上在本地创建了一个B分支，你在B分支做了两次commit ，但是你有些样式还需要调整，在这个时候而你的同事在A分支上也做了两次commit。但是你的同事现在在A分支上需要你在B分支上实现的功能，你需要将B分支合并到A分支上，然后继续在B分支上完善。这时候你就需要用rebase将B分支合并到A分支上，需要手动解决冲突，然后执行git rebase --continue继续合并。合并的结果是B分支依然存在。
场景二：继续场景一的内容，在此时，你在B分支上完善了上次没有完善好的内容，已经不需要再B分支上做什么了，现在就得将B分支合并到A分支上，B分支就可以作废了。这时候需要用merge 将B分支合并到A分支上，合并之后，如果有冲突，需要手动解决然后提交，合并的结果是B分支不存在了。