实际开发项目使用到的分支:
main：生产环境，也就是你们在网上可以下载到的版本，是经过了很多轮测试得到的稳定版本。
release： 开发内部发版，也就是测试环境。
dev：所有的feature都要从dev上checkout。
feature：每个需求新创建的分支。
下面介绍一下一个新需求过来的git操作流程：
1.从dev分支上checkout -b new-feature，进行开发
2.开发完后，经过自测没问题了，准备发版
3.merge到release分支上进行发版，并打tag
4.有bug就直接在release上进行修改，改完再次发版，打tag，直到测试人员验证完毕
5.这时可以将release分支合并到dev上，也可以删除掉feature分支了，并等待通知是否将此功能上线（发布正式版本，也就是在正式服务器上运行），如果上线，那就merge到main（master）分支，当然了有可能需要将ip改为生产服务器的地址，并打上一个official tag。
6.如果上线后，发现有bug，如果此时main分支已经又合并上新功能B了，但是这个临时的版本又不想包含B的功能，那么可以切换到上次的official tag，checkout -b一个hotfix分支进行bug修复，hotfix分支要进行保留，不能删除。测试没问题就可以发版了，最后可以合并到main上。
一般的项目这套流程应该就足够了。所有的发版tag都会集中到release，main，hotfix分支上，所有的需求都会从dev上拉取，这样能保证代码是完整可用的，是经过每次release合并过来的
指令及其含义
- git checkout -b xxx：git checkout xxx是指切换到xxx（用local区的xxx替换disk区文件），-b意味着branch，即创建新分支，这条指令合起来意思是创建并切换到xxx。
- git diff：查看暂存区与disk区文件的差异。
- git add xxx：将xxx文件添加到暂存区。
- git commit：将暂存区内容添加到local区的当前分支中。
- git push ：将local区的LocalBranchName分支推送到RemoteHostName主机的同名分支。（若加-f表示无视本地与远程分支的差异强行push）
- git pull ：同上，不过改成从远程主机下载远程分支并与本地同名分支合并。
- git rebase xxx：假设当前分支与xxx分支存在共同部分common，该指令用xxx分支包括common在内的整体替换当前分支的common部分（原先xxx分支内容为common->diversityA，当前分支内容为common->diversityB，执行完该指令后当前分支内容为common->diversityA->diversityB）。
- git branch -D xxx：不加-D表示创建新local分支xxx，加-D表示强制删除local分支xxx。
工作流一：
- git clone remote// 到本地
- git checkout -b feature 切换至新分支feature
（相当于复制了remote的仓库到本地的feature分支上 - 修改或者添加本地代码（部署在硬盘的源文件上）
- git diff 查看自己对代码做出的改变
- git add 上传更新后的代码至暂存区
- git commit 可以将暂存区里更新后的代码更新到本地git
- git push origin feature将本地的feature分支上传至github上的git
如果在写自己的代码过程中发现远端GitHub上master分支代码出现改变
- git checkout master切换回master分支
- git pull origin master将远端修改过的代码再更新到本地
- git checkout feature回到feature分支
- git rebase master把我的修改先都放在一边，然后把master最新的修改拿过来，接着在这个最新修改的基础之上，再把我的commit尝试弄回去，中途可能会出现rebase conflict手动选择保留哪段代码，就相当于我们在最新的master分支上做了修改 ，这也是使用rebase而不是使用merge的好处
- git push -f origin xxx 把rebase后并且更新过的代码再push到远端github上，由于做了rebase所以需要加上-f ，-f表示强行，强行push
- 把更新的代码合并到远程master分支里面，pull request的意思是request项目的主人把我这个新的分支的改变给pull到这个项目里去。原项目主人采用pull request 中的 squash and merge 合并所有不同的commit
远端完成更新后
- github删除个人远程分支feature
- 本地切换到主分支git checkout master && git branch -d feature删除本地的git分支
- git pull origin master 再把远端的最新代码拉至本地，这时我们的本地仓库就又和远程一样了。
工作流二：
远程仓库有两个master和test分支
- git clone remote克隆仓库
- git checkout -b feature切换分支，没有就会新创建并切换
- 编写代码并提交本地仓库
- 推送到远程test分支
- git checkout -b test origin/test意思是切换一个分支，如果分支不存在就会创建并切换到test分支，后面origin/test是指从远程test克隆下来，并与本地test分支建立联系，这时，文件里没有新编写的代码。
- 切换到feature分支使用git log查看提交历史记录，记录以前提交的哈希值
- 切换到test分支，使用git cherry-pick 哈希值，这时代码就同步过来了，可以再次使用git log查看。
- git push到远程test分支
- 同步到远程master分支，如果此时远程master分支有更新，需要切换到master分支使用git pull保证本地master分支是最新的，然后使用git cherry-pick 哈希值，这时代码就同步过来了，可以再次使用git log查看，再push到远程分支。
工作流三： git pull
- 本地修改代码，远程也更新代码，产生冲突
- 使用git pull后需要手动merge
- git add .
- git commit -m “合并冲突”
- git push
- git log --graph
缺点：提交记录出现分叉，出现很多奇怪的提交记录。
工作流四： git pull --rebase优化提交记录
现象：提交记录出现分叉，出现很多奇怪的提交记录。
业务场景：
在本地分支完成了我功能的开发，现在需要合并到test 分支上，于是我的目标是在test 分支上执行git cherry-pick操作将我的代码检出到test上，因为我要避免有人更新过test分支,所以我在此之前先执行了一下git pull ，出现了一个Merge的vi窗口(过去我一直没注意， 直接就wq出去
.了)，其实这个就是导火索! vi窗口如下:
原因
git pull 其实是一个组合操作，其会执行git fetch + git merge (过去其实完全不知道) ， 因为
有git merge的存在，所以最后的提交记录看起来就会很乱。
解决方案
使用git pull --rebase 来进行合并本地和远程分支。既可以完美解决这个问题!
git pull --rebase 也是一个组合操作， 其会执行git fetch + git rebase ，我们知道git rebase 就
是解决凌乱记录的一个大杀器，所以可以完美的解决!
- 本地修改代码，远程也更新代码，产生冲突
- 使用git pull --rebase origin test需要手动处理冲突
current change变为了远程，意味着更新版本是以远程为基础的大的提交，不会是含有本地每次小的提交。 - git add .
- git rebase --continue
- wq即可
- git push
- git log --graph
这样操作之后我们的提交记录就是非常干净的一条链路了!
补充：
git log --graph
更加清晰的结构查看log记录。
