Home/ Questions/Q 7684323
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-31T19:00:00+00:00

So I usually create a feature branch in git, work on it, then merge

  • 0

So I usually create a feature branch in git, work on it, then merge with the master (trunk) branch.

I created a feature branch which I didn’t end up merging into master.

Now the master branch has progressed over the weeks/months, and I now want to work on that feature branch again, but I want to update it with whatever is in the master branch.

The feature branch is all new files so there should be any merge conflicts.

How would I go about doing this?

Note: I want this code to remain on a branch, in case I don’t want to merge it again as it is a major change.

If you could explain the theory behind it also so I can understand that would be great.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Checkout your feature branch, and either merge master into the feature branch (git merge master), or rebase the feature branch on top of master (git rebase master).

    Which one you choose depends on what you want your history to look like.

    If you merge, your old commits will continue to exist in their original state on top of the old version of master, with a new merge commit containing your changes and the new version of master. Some people like this because it accurately reflects the original history, and because it creates fewer conflicts than a rebase. However, this sort of practice can create a confusing history with a lot of merge commits. The ‘git bisect’ command also works poorly with histories that have a lot of merges.

    If you rebase, you will have a series of commits on top of your new master revision, and you will lose your original commits. This creates a straightforward, linear history. You can also use ‘git rebase -i’ to clean up your commits before publishing or adding them to master (should you choose to do that). Because conflicts must be resolved for each of your commits, instead of just once for a merge commit, rebasing generates more conflicts.

    I prefer to rebase code that I haven’t published yet, and only merge when I really need the history to show development that happens in two places in parallel (such as a project that I have forked and modified, without intending to send my changes upstream; I will then merge in changes from upstream from time to time).

    • 0