Git使用感悟

前言

分支介绍

我们现在开发的分支一般是这样的(基于上面那张图片的):
master:上线用的
dev:开发用的
featature_xxx:开发用的
test:测试用的
hotfix:修复bug的

一般是这样子的:

公共分支:
master、dev、test,一般是不会这些分支上开发的,都是由别的分支合并到这些分支上

私有分支:
feature_xxx,hotfix_xxx,这些分支一般是由某个人或某几个人一起开发一个功能点

feature_xxx从dev分支分出来
feature_xxx合并到test去测试
feature_xxx合并到devdev合并到master
master打tag上线

hotfix分支从master分支分出来
hotfix分支合并到test去测试
hotfix分支合并到master
master打tag上线
hotfix分支合并到dev

常用指令

git branch 查看当前的分支
git checkout xxx 切换到xxx分支
git checkout -b xxx 基于当前分支创建分支xxx,并切换到xxx分支
git status 查看文件处于什么状态
git add xxx 放到暂存区,等待被commit
git commit -m "xxx" commit操作,等待被push
git push 将本地分支推向远程分支
git pull 远程分支同步到本地分支
git merge xxx 将xxx分支合并到当前分支
git log --oneline --graph 查看提交历史记录

关于 git merge

  1. 第一种情况

feature_a是从dev分支分出来的,如果将feature_a合并到dev分支中,并且dev分支没有任何更改的情况下,使用merge命令的话,dev的头指针只是移动了一下,如下图所示


  1. 第二种情况

如果dev分支做了改动的话,那么会新建一个commit的点,如下图所示


git merge 指令会根据不同的情况自动执行
git merge --no-ff 会强行采用第二种方案,也就是总会新建一个commit点

关于 git rebase

rebase也是合并操作,与merge不同的是,rebase 命令将另一分支上的所有修改都移至当前分支上

下面是分支情况,我们现在要把dev分支合并到feature_a上

如果采用merge的话,会产生下图效果

如果采用rebase的话,会产生下图效果,它把dev修改的commit都移动到feature_a的前面了

关于git pull

git pull 的操作是git fetch & git merge
git pull --rebase 的 操作是 git fetch & git rebase

最佳实践

git merge --no-ff:私有分支往公共分支合并的时候,比如feature_xxx往dev或test上合并的时候,产生新的commit,代表着有合并的记录
git rebase:feature_xxx需要和dev同步时,合并dev的时候,因为feature_xxx最终会合并到dev,如果采用merge的话,会有好多新的commit
git pull --rebase:使用这个命令进行git pull,不会产生新的commit

思考

不确定:当两个feature_xxx合并的时候,应该用git merge还是git rebase呢?小伙伴有什么想法可以留言一下哈

参考

git book
记一次常规的gitflow工作流 - frank
Git-Rebase-黄金法则问题 - frank

原文地址:https://www.cnblogs.com/eaglelihh/p/13586614.html