求 SourceTree 合并代码正确的方法？

[tanteng]

团队开发，比如分支在group/dashen/service上，我创建一个分支到personal/tuntun/service，然后我在自己的分支上改动了几个文件，然后：

1.提交修改
2.切换到dashen/service分支，拉取最新代码
3.右键我的分支合并到当前代码
4.然后在当前分支（dashen下）再推送，但是往往不行，需要再提交，"Merge..."，这个时候再推送就ok了。

也有说第3步应该是右键选“将当前修改变基到当前分支”，但还是需要重新提交，Merge一下代码提交成功后，才能推送。

但是有人说这种方式不好，说我的提交都是“Merge...”，正常的合并代码的方式是怎样的？

[Jeremial]

我觉得这种方式没有什么不好.
你切换到dashen/service分支, 先拉取代码, 这种方法是对的, 而且应该是被鼓励的.

我不太喜欢使用rebase方法, 应该就是LZ说的那种"将当前修改变基到当前分支". 虽然这种方式,能够让这个分支的commit记录保持线性, 但是这样也丢失了这个分支的一些信息. 比如这个分支从哪个commit分出来的, 在哪个commit合并回去的.

我现在遵循是git-flow中使用的那种方法. 将特性分支合并到develop时, 使用 `git merge --no-ff` 选项, 即使这个分支被删除了, 这个分支的一些信息也能明了的看到.

[msg7086]

smartgit的git flow大法

[20150517]

没看懂,不过我公司master上都是我提交的大merge,里面大部分是别的的文件,是不是不太好?

[li24361]

额，一般先拉取更新，拉取不了就提交再拉取，再合并，在提交推送

[Felldeadbird]

我都是拉取，合并，推送。我都是命令行完成的。软件切换太慢了。

[fontartist]

一般都命令行做合并动作。

[julyclyde]

rebase是在自己分分支上做的吧，相当于 无痕把大神的代码merge过来
如果在大神分支上做，就应该是merge了，因为rebase会改变历史，而你push不进去历史，只能pull request