Git工作流

骑猪看日落 2023-10-15 10:56 54阅读 0赞

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

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。

### 工作流一： ###

![在这里插入图片描述][83d1403fe2044f8cb21f22e6e4f476a4.png]

1.  git clone remote// 到本地
2.  git checkout -b feature 切换至新分支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 feature把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  
    ![在这里插入图片描述][549b3f4b6f434b23a453f5de781bba37.png]

#### 缺点：提交记录出现分叉，出现很多奇怪的提交记录。 ####

### 工作流四： git pull --rebase优化提交记录 ###

#### 现象：提交记录出现分叉，出现很多奇怪的提交记录。 ####

#### 业务场景： ####

在本地分支完成了我功能的开发，现在需要合并到test 分支上，于是我的目标是在test 分支上执行git cherry-pick操作将我的代码检出到test上，因为我要避免有人更新过test分支,所以我在此之前先执行了一下git pull ，出现了一个Merge的vi窗口(过去我一直没注意， 直接就wq出去  
.了)，其实这个就是导火索! vi窗口如下:  
![60595fa74d764a1895191e4207e55233.png][]

#### 原因 ####

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需要手动处理冲突  
    ![在这里插入图片描述][6b63853a088d4d27aac54153b5cb7f00.png]  
    current change变为了远程，意味着更新版本是以远程为基础的大的提交，不会是含有本地每次小的提交。
3.  git add .
4.  git rebase --continue
5.  wq即可
6.  git push
7.  git log --graph  
    ![在这里插入图片描述][d850f1d2924c4a2aa75441951f453567.png]  
    这样操作之后我们的提交记录就是非常干净的一条链路了!  
    ![在这里插入图片描述][415ad7f5ca7f4890a4385e316673f4bc.png]  
    补充：

git log --graph

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

[83d1403fe2044f8cb21f22e6e4f476a4.png]: https://img-blog.csdnimg.cn/83d1403fe2044f8cb21f22e6e4f476a4.png
[549b3f4b6f434b23a453f5de781bba37.png]: https://img-blog.csdnimg.cn/549b3f4b6f434b23a453f5de781bba37.png
[60595fa74d764a1895191e4207e55233.png]: https://img-blog.csdnimg.cn/60595fa74d764a1895191e4207e55233.png
[6b63853a088d4d27aac54153b5cb7f00.png]: https://img-blog.csdnimg.cn/6b63853a088d4d27aac54153b5cb7f00.png
[d850f1d2924c4a2aa75441951f453567.png]: https://img-blog.csdnimg.cn/d850f1d2924c4a2aa75441951f453567.png
[415ad7f5ca7f4890a4385e316673f4bc.png]: https://img-blog.csdnimg.cn/415ad7f5ca7f4890a4385e316673f4bc.png