用git时，一直使用自己新建的git分支，不删除，然后提交merge之后又重复使用，会出现什么问题嘛

也倒不一定会有问题。但是并不建议这样使用git merge ，因为很容易产生分叉和新的commit

文章插图

文章插图
虽然这样操作非常简单就能合并代码，但是项目中都是合作开发，如果大家都这么操作，那么最后远程主分支记录结果就会变成

文章插图

再看看使用git rebase和git merge的对比图

文章插图

但是并不是说不能使用git merge，而是需要了解了二者的区别以及适用场景采用合适的方式。
推荐一个玩游戏学git的网站，非常有趣，玩完相信你会有一个新的认识。https://learngitbranching.js.org/
结论：没什么问题，但是失去了分支的意义。

前言git的分支，用来存储不同的开发进度，比如

合理地分配分支职能，会给仓库维护带来方便。

文章插图

举个栗子说空洞的名词，难以下咽，不如给个例子，说明起来方便。借用星云法师一个故事。

东寺僧人和西寺僧人出门，碰见了。
东寺僧人问：你要去哪里呀？
西寺僧人说：风吹到哪里，我就去哪里。
东寺僧人不知道该怎么接了。
晚上回去，问住持，住持说，你怎么不说：要是没有风，你到哪里呀？

第二天，又遇见。
东寺僧人问：你要去哪里呀？
西寺僧人说：脚走到哪里，我就去哪里。
东寺僧人一愣，又不会接了。
晚上回去，问住持。住持说，你怎么这么笨哟，为什么不问：脚要是不走，你去哪里呢？

第三天，又遇见。
东寺僧人问：师兄，要去哪里呀？
西寺僧人说：去买菜。

实际测试上一节扯远了，并非要说明高深的道理。星云大师教人开悟。

1 - 创建一个空仓库

git init

仓库与目录同在。不做裸仓库。

2 - 新建文本文件 poem

cat > poem <<eof
> Someday you will cry for me
> Like I cried for you.
> Someday you'll miss me
> Like I missed you.
> eof

在命令行内输入一些文本，使用eof作为开始和结束符。

3 - 查看状态

git status

文章插图

4 - 提交这个修改

git add poem

git commit -m "[add]:添加一首小诗"

文章插图

5 - 创建新分支

git checkout -b dev

6 - dev 做一些修改

echo "add by dev branch" >> poem

文章插图
7 - 提交修改

git add poem

git commit -m "[feat]:添加dev特性"

8 - 合并到master
合并之前，切换到主分支；比较两个分支差异；执行合并。

git ckeckout master

git diff --stat dev

git merge dev

文章插图

9 - 接下来怎么办
dev用完了，还要接着用吗？当然可以，不过，线上master代码运行过程中，发现了一个bug，要热修，还拉到dev分支上处理吗？
其实，像这种临时的任务，拉一个临时分支，用完删掉，更为整洁。强迫症必备。

10 - 新建 bug-fix 分支
首先拉取线上分支到本地新分支。

git fetch large master:bug-fix

git checkout bug-fix

11 - 做一些修改然后提交
在bug-fix分支上修改完毕，提交修改；切换到master分支，合并bug-fix的修改，然后提交到线上。

echo "Do more" >> poem

git add poem

git commit -m "[fix-bug]: 更多"

git checkout master

git diff --stat bug-fix

git merge bug-fix

git push large master

文章插图

12 - 删除分支
充分合并的分支，bug-fix分支完成了使命，我们转到dev上开发新功能。
合并这个最新修改的分支，然后删除bug-fix分支就好了。

git checkout dev

git diff --stat bug-fix

git merge bug-fix

git branch --delete bug-fix

文章插图

结语为了让题主对分支有更为立体的感觉，小助手用了12步，初步解释了分支的用法。希望可以帮助题主养成分支处理的好习惯，让代码仓库更为整洁优秀。

Happy coding :-)
【用git时，一直使用自己新建的git分支，不删除，然后提交merge之后又重复使用，会出现什么问题嘛】

【本文由 @程序员小助手发布，持续分享编程故事，欢迎关注】