0

I'm confused about how I should update a feature branch against a development branch. I have an old feature branch which was created from development as follows

development       A--B--C--F--G--H--I
                         \
feature                   D--E


I would like to get to the following point, where the feature branch is shown at the end of the git history. I can then merge into development and be happy.

development       A--B--C--F--G--H--I
                                     \
feature                               D--E

When I do git rebase development I get the following, and merge conflicts when I try to merge into master. So I'm not really sure how I should move commit D(feature branch) to be attached to commit I(development branch)

development       A--B--C--F--G--H--I
                         \
feature                   D--E--F--G--H--I

jack west
  • 569
  • 1
  • 4
  • 14

2 Answers2

2

Make sure your local copy of the development branch is up to date by running the following command :

git checkout development
git pull

Switch back to your feature branch using the following command :

git checkout feature-branch

Perform the rebase using the following command :

git rebase development

Once all conflicts have been resolved, use the following command to update the feature branch with the changes from the development branch:

git add .
git rebase --continue

merge the feature branch into the development branch:

git checkout development
git merge feature-branch
j6t
  • 9,150
  • 1
  • 15
  • 35
Mohamedm97
  • 36
  • 2
1

I would strongly recommend that you NEVER run rebase with anything less that two arguments (I don't). That way there is much less chance of errors.

For the scenario you describe the command to achive what you want (rebase feature on top of development) then the command to run is

git rebase development feature   # E.g. rebase feature on top of development

This command is independent on which branch that is the current branch (i.e. zero chanche of making a mistake because the current branch was something other than what you assumed), and it is also very explicit and descriptive.


Another benefit is that if you wanted to rebase something other than the tip of a branch, then the syntax is exactly the same, you only change the commit.

Let's say commit I updates a dependency/framework or something else that you do not want to update to yet but you want to take in all the other commits, e.g. you want to have

development       A--B--C--F--G--H--I
                                  \
feature                            D--E

Then the rebase command is simply

git rebase commit_H feature

Notice that this "special" case now becomes non-special because you consistently always run rebase with two arguments.


If I were the git maintainer I would seriously consider deprecating specifying just one argument to rebase. I think it is really bad.

hlovdal
  • 26,565
  • 10
  • 94
  • 165