以项目为例，从拉取代码到平时的开发使用
git的三个区域：
HEAD 指向最近一次commit里的所有snapshot(历史记录区)Index 缓存区域，只有Index区域里的东西才可以被commit(暂缓区)Working Directory 用户操作区域(工作区)变化过程如下：
常规的操作命令：
git clone 项目路径 //拉取代码 git add . //工作区全部文件提交到暂缓区 git commit -m "描述" //暂缓区文件提交到本地仓库 git pull //从远程仓库拉取代码 git push origin master //本地仓库提交到远程仓库master分支 git status //查看状态 git diff //查看上次修改的内容 git log //显示从最近到最远的提交日志 git log --pretty=oneline //显示在一行 git log --graph //命令可以看到分支合并图 git checkout -b dev //创建并切换到分支dev git checkout master //切换到master分支 git branch //查看当前分支 git branch -a //查看所有分支(包含远程仓库) git merge dev //合并分支（先切换到主支再合并） git branch -d dev //删除分支dev拉取远程仓库全部分支
克隆成功一个仓库后，有时没有克隆远程仓库的分支，需要手动执行
git branch -r | grep -v '\->' | while read remote; do git branch --track "${remote#origin/}" "$remote"; done git fetch --all git pull --alreset详解
reset实际上有3个步骤，根据不同的参数可以决定执行到哪个步骤(--soft, --mixed, --hard)。
改变HEAD所指向的commit(--soft)执行第1步，将Index区域更新为HEAD所指向的commit里包含的内容(--mixed)执行第1、2步，将Working Directory区域更新为HEAD所指向的commit里包含的内容(--hard)注意：
–mixed是默认参数，也就是说执行reset的时候不给就认为是--mixed。
下表说明了三种形式的git reset所产生的不同效果。
target代表想要将git指向到哪个commit
working index HEAD target working index HEAD ---------------------------------------------------- A B C D --soft A B D --mixed A D D --hard D D D --merge (disallowed) working index HEAD target working index HEAD ---------------------------------------------------- A B C C --soft A B C --mixed A C C --hard C C C --merge (disallowed)reset和revert的区别
在日常的开发中，总会出现这种情况，提交了一个新的版本，因为莫名其妙的bug，把项目搞瘫痪了。亦或是刚开发完的需求，客户变方案了。这些都需要我们进行回滚，reset和revert都可以实现，区别在于
reset：修改提交历史（重点：历史被改变了，由1=>2=>3=>4变成了1=>2=>3，4在历史中被移除了）
revert：提交历史中继续延伸（重点：创建新的历史，由1=>2=>3=>4变成了1=>2=>3=>4=>5，新提交的5根据4逆向生成）
这就好比开车经过分叉路口，你走了左边，但是发现路不对，应该是右边。。。
reset做的是时光倒流，倒流回你经过分岔路口的那个时间，而revert做的是原路返回，返回到分岔路口。
两种都达到了目的，区别在于reset可能会影响其他开发人员的提交历史，而revert不会。
推荐revert回滚！！！
cherry pick和merge的区别
两者都有合并代码的效果，区别在于
cherry pick：合并一条提交历史
merge：合并分支的全部历史
主要还是使用场景的不同，举个例子：
主分支master，新功能在dev分支上开发，要上线了需要把代码同步到主分支上，这种情况使用cherry pick最佳，因为主分支有最终的代码就够了，开发的中间过程commit对于master分支没有意义。
merge更多的使用在合并分支，合并到主分支后，当前分支不再进行开发，可以删除。
