Git工作流

实际开发项目使用到的分支:

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。

工作流一：

1. git clone remote// 到本地
2. git checkout -b feature 切换至新分支feature
   （相当于复制了remote的仓库到本地的feature分支上
3. 修改或者添加本地代码（部署在硬盘的源文件上）
4. git diff 查看自己对代码做出的改变
5. git add 上传更新后的代码至暂存区
6. git commit 可以将暂存区里更新后的代码更新到本地git
7. git push origin feature将本地的feature分支上传至github上的git

如果在写自己的代码过程中发现远端GitHub上master分支代码出现改变

1. git checkout master切换回master分支
2. git pull origin master将远端修改过的代码再更新到本地
3. git checkout feature回到feature分支
4. git rebase master把我的修改先都放在一边，然后把master最新的修改拿过来，接着在这个最新修改的基础之上，再把我的commit尝试弄回去，中途可能会出现rebase conflict手动选择保留哪段代码，就相当于我们在最新的master分支上做了修改 ，这也是使用rebase而不是使用merge的好处
5. git push -f origin xxx 把rebase后并且更新过的代码再push到远端github上，由于做了rebase所以需要加上-f ，-f表示强行，强行push
6. 把更新的代码合并到远程master分支里面，pull request的意思是request项目的主人把我这个新的分支的改变给pull到这个项目里去。原项目主人采用pull request 中的 squash and merge 合并所有不同的commit

远端完成更新后

1. github删除个人远程分支feature
2. 本地切换到主分支git checkout master && git branch -d feature删除本地的git分支
3. git pull origin master 再把远端的最新代码拉至本地，这时我们的本地仓库就又和远程一样了。

工作流二：

远程仓库有两个master和test分支

1. git clone remote克隆仓库
2. git checkout -b feature切换分支，没有就会新创建并切换
3. 编写代码并提交本地仓库
4. 推送到远程test分支
5. git checkout -b test origin/test意思是切换一个分支，如果分支不存在就会创建并切换到test分支，后面origin/test是指从远程test克隆下来，并与本地test分支建立联系，这时，文件里没有新编写的代码。
6. 切换到feature分支使用git log查看提交历史记录，记录以前提交的哈希值
7. 切换到test分支，使用git cherry-pick 哈希值，这时代码就同步过来了，可以再次使用git log查看。
8. git push到远程test分支
9. 同步到远程master分支，如果此时远程master分支有更新，需要切换到master分支使用git pull保证本地master分支是最新的，然后使用git cherry-pick 哈希值，这时代码就同步过来了，可以再次使用git log查看，再push到远程分支。

工作流三： git pull

1. 本地修改代码，远程也更新代码，产生冲突
2. 使用git pull后需要手动merge
3. git add .
4. git commit -m “合并冲突”
5. git push
6. 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 就
是解决凌乱记录的一个大杀器，所以可以完美的解决!

1. 本地修改代码，远程也更新代码，产生冲突
2. 使用git pull --rebase origin test需要手动处理冲突
   
   current change变为了远程，意味着更新版本是以远程为基础的大的提交，不会是含有本地每次小的提交。
3. git add .
4. git rebase --continue
5. wq即可
6. git push
7. git log --graph
   
   这样操作之后我们的提交记录就是非常干净的一条链路了!
   
   补充：

git log --graph

更加清晰的结构查看log记录。