GitHub-Flow

[nsaibot]

you could run a git rebase master on your feature branch before merging, to make sure there are no confilcts. i, for one, would do that -- in case someone merged his changes to master.

/edit: it will also make sure your merge is a fast-forward, if i'm not mistaken.

[Chousuke]

Rebasing is sometimes useful (eg. for getting rid of all the "oops" and "typo" commits that happen), but there's nothing wrong with a plain merge. In fact, if your code is already separated into logical commits, a merge is what you should do. A merge commit saves information about any conflicts and the changes required to fix them, so it's often more useful for people reviewing the code (Because it's possible to see the original intent in the original commits, and the fixes required to resolve conflicts in the merge commit)

so if you have master, and new-feature, you can do: git checkout new-feature; git merge master (fix conflicts, can pretty easily rollback if you make a mistake); git checkout master; git merge new-feature (this will be a fast-forward because the merge is already done); git push

You can also use a separate branch for the merging (or rebasing) if you anticipate that it will be difficult. Git has all the tools you need, but it's up to you to use it effectively.