3

I just started working with a pull and fork model. I keep sync my fork and create a new branch when I have to fix something or for a new feature.

I'd like to know what to do when I have to face the following situation:

Let's suppose that I start creating a new feature

enter image description here

When I finish my new feature and before creating a pull request with this new branch, I find that my fork is 1 commit behind master, so I sync my fork and I get this:

enter image description here

Now my question is what I should do before sending the pull request? I think I should merge C4 into F2 but not sure if this is the correct approach or I should use rebase instead.

Thanks

Improve this question

1 Answer 1

Reset to default
3

This is very much a matter of convention. GitFlow, for example, advocates creating merge commits whenever some work is needed in another branch. Some people, myself included, find that this results in a very messy history, and instead rebase the current branch on top of the branch we want to merge into (typically master). One trade-off is that to rebase you have to rewrite history, which will be messy if more than one person is working on the same branch.

Improve this answer
1
  • Rebasing a feature branch is usually not considered a problem – the pull request can still be merged with an explicit merge commit, and features ought to be so small that the branch isn't shared by multiple people. Not rebasing would be problematic if the pull request would have any conflicts with the master branch that need resolving first.
    – amon
    Nov 3, 2018 at 15:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.