目录
git所有分支之间彼此互不干扰，各自完成各自的工作和内容，可以在分支使用后合并到总分支上，安全、便捷、不影响其他分支工作。
?一、git提交代码
- ?①
同步远程仓库代码：git pull
提交代码第1步：git pull 同步远程仓库代码到本地
git add / git?commit代码之前首先git pull，需先从服务器上面拉取代码，以防覆盖别人代码；如果有冲突，先备份自己的代码，git checkout下远程库里最新的的代码，将自己的代码合并进去，然后再提交代码。
命令：git pull
?出现Already up-to-date代表本地代码已经更新到和远程仓库一致了。
②
查看当前状态：git?status
提交代码第2步：git status ?查看当前状态
当你忘记修改了哪些文件的时候可以使用 git status ?来查看当前状态，红色的字体显示的就是你修改的文件。
?③
提交代码到本地git缓存区：git add
提交代码第3步：git add . ?或者 git add xxx
命令：git add 文件名1 文件名2 ...
情形一：如果你git status 查看了当前状态发现都是你修改过的文件，都要提交，那么你可以直接使用 git add . ?就可以把你的内容全部添加到本地git缓存区中
情形二：如果你git status 查看了当前状态发现有部分文件你不想提交，那么就使用git add xxx(上图中的红色文字的文件链接) ?就可以提交部分文件到本地git缓存区。
④?
推送代码到本地git库：git commit
提交代码第4步：git commit -m "提交代码" ? 推送修改到本地git库中
命令：git commit 文件名 -m "提交代码备注"
⑤?
提交本地代码到远程仓库：git push
提交代码第5步：git push <远程主机名> <远程分支名> ?把当前提交到git本地仓库的代码推送到远程主机的某个远程分之上。
命令：git push
代码提交合并成功！（最后一行的c7531bd..d6d07d5就是代码的版本号）
?
二、git merge 和 rebase的区别
merge
现在假设我们有一个主分支 master 及一个开发分支 deve，仓库历史就像这样：
现在如果在 master 分支上 git merge deve：Git 会自动根据两个分支的共同祖先即 e381a81 这个 commit 和两个分支的最新提交即 8ab7cff 和 696398a 进行一个三方合并，然后将合并中修改的内容生成一个新的 commit，即下图的 78941cb
rebase
rebase 是什么情况呢？还是一个初始的仓库历史图：
如果是在 master 分支上 git rebase deve：Git 会从两个分支的共同祖先 3311ba0 开始提取 master 分支（当前所在分支）上的修改，即 85841be、a016f64 与 e53ec51，再将 master 分支指向 deve 的最新提交（目标分支）即 35b6708 处，然后将刚刚提取的修改依次应用到这个最新提交后面。操作会舍弃 master 分支上提取的 commit，同时不会像 merge 一样生成一个合并修改内容的 commit，相当于把 master 分支（当前所在分支）上的修改在 deve 分支（目标分支）上原样复制了一遍,操作完成后的版本历史就像这样：
?
可以看见 master 分支从 deve 分支最新提交 35b6708 开始依次提交了自己的三个 commit（由于是提取修改后重新依次提交，故 commit 的 hash 码与上面的85841be、a016f64、e53ec51 不同）
三、代码review的方法和步骤
主要使用的是代码串讲的方法
介绍：代码串讲也是很好的一种REVIEW的方式，这个弥补了一部分没有文档资料的困难，由写代码的人进行介绍，将业务逻辑和代码运行讲给REVIEW代码的人，这样REVIEW代码的人就可以直接现场提出问题和质疑，和写代码的人员直接沟通，效率是比较高效的，一般的做法是写代码的人召集REVIEW的人员进行开会来集中讲解代码，然后进行问题讨论，会后分析修改代码。
?