开发时怎么用好 Git 分支? - Color的回答 - 知乎
https://www.zhihu.com/question/21995370/answer/19975870

假如远程只有一个master

本地分支可以不同步到远程仓库，我们可以在本地dev开发，然后merge到master，使用master同步代码

假如远程有自己的分支 推远程master的同时推远程dev 这样的意义是什么？

git checkout dev # 切换到dev分支进行开发

开发代码之后，我们有两个选择

第一个：如果功能开发完成了，可以合并主分支

git checkout master # 切换到主分支

git merge dev # 把dev分支的更改和master合并

git push # 提交主分支代码远程

git checkout dev # 切换到dev远程分支

git push # 提交dev分支到远程

第二个：如果功能没有完成，可以直接推送

git push # 提交到dev远程分支

注意：在分支切换之前最好先commit全部的改变，除非你真的知道自己在做什么

还有一篇文章 写的不错 关于merge和rebase配合使用

https://zhuanlan.zhihu.com/p/34197548

例如现有上游分支 master，基于 master 分支拉出来一个开发分支 dev，在 dev 上开发了一段时间后要把 master 分支提交的新内容更新到 dev 分支，此时切换到 dev 分支，使用 git rebase master

等 dev 分支开发完成了之后，要合并到上游分支 master 上的时候，切换到 master 分支，使用 git merge dev

rebase类型操作
git checkout B1
git pull origin B1 –rebase
git rebase master
git push origin B1 –force

vs我以前的merge操作 (这里为什么要merge两次 先master into B1 再B1 into master 其实我不懂 这个问题似乎得到了解答 )
git checkout B1
git pull origin B1
git merge master
git push origin B1

上面两个之后都要
git checkotu master
git merge B1

Git push 时如何避免出现 “Merge branch ‘master’ of …”

https://www.cnblogs.com/Sinte-Beuve/p/9195018.html

A-B-C(master)
       \
          D(origin/master)

我当前拉取的远端版本为 B，此时修改了代码，并在本地仓库 commit 一次，但并未 push 到远端仓库。
另一位开发者在 B 的基础上，同样 commit 了一次并 push 到远端仓库。那么这个时候，我再 push 自己的代码就会发生错误，如下。
To github.com:maoqyhz/usegit.git
! [rejected] master -> master (fetch first)
error: failed to push some refs to ‘git@github.com:maoqyhz/usegit.git’
hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing
hint: to the same ref. You may want to first integrate the remote changes
hint: (e.g., ‘git pull …’) before pushing again.

这个时候我们会选择，先 pull，再 push。Ok，push 成功，但是此时我们查看 log 就会发现除了我们自己提交的那条日志之外，会多出一条 “Merge branch ‘master’ of …”。
在进行 pull 操作的同时，其实就是 fetch+merge 的一个过程。我们从 remote 分支中拉取新的更新，然后再合并到本地分支中去。

如果 remote 分支超前于本地分支，并且本地分支没有任何 commit 的，直接从 remote 进行 pull 操作，默认会采用 fast-forward 模式，这种模式下，并不会产生合并节点
如果想之前那样，本地先 commit 后再去 pull，那么此时，remote 分支和本地会分支会出现分叉，这个时候使用 pull 操作拉取更新时，就会进行分支合并，产生合并节点和 log 信息。
为了去除自动生成的 log 信息 可以git pull –rebase
从 remote 分支拉取更新到本地时，使用 rebase。
当完成 bug 修复或新功能时，使用 merge 将子分支合并到主分支。

跳转到的地方

reddit上面一个讨论 https://www.reddit.com/r/git/comments/j38kb1/what_does_it_mean_to_merge_master_into_feature/

这是您的情况：您有一个commit一些内容的branch。同时，别人的更改更改已合并到 master。

下面内容二选一

将 master 合并到您的功能分支

或者

变基

然后再把功能分支合并到master (下图为第三步选择merge的效果)

上面的内容似乎并没有真正回答问题，于是我继续搜索，又看到了reddit上一篇帖子。感觉比上面的更贴近我想要的答案。
https://www.reddit.com/r/git/comments/3qpvzk/question_why_would_you_merge_master_into_a_branch/

本质上我们在讨论下面两种步骤的区别

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
在branch解决冲突
git commit -m 'final feature commit'   # SHA: X1
# git pull, git fetch/merge
git merge master
git commit -m 'resolve merge conflicts'  # SHA: Y1
git checkout master
git merge feature  # SHA: M1 (merge commit)
git branch -d feature

在master解决冲突
git commit -m 'final feature commit'  # SHA: X2
git checkout master
# git pull, git fetch/merge
git merge feature  # SHA: M2 (merge commit)
git commit -m 'resolve merge conflicts'  # SHA: Y2
git branch -d feature

文就在于你想在哪里解决冲突,在branch还是在master? 在master解决冲突，命令会更少。如果实在branch解决，会使得回滚更加方便。第一种只需要revert M1才能恢复之前的master。 第二种需要revert M2 and Y2. 尽管不是每个项目都需要第一种，还是建议养成这个习惯。

还有一点意义在于：长时间开发个人分支，时不时合并master into个人可以紧跟实事，减少最终大合并的工作量。