4

On Github I have:

  • the master branch, let's say github_master_branch

  • and a personal (remote) branch, let's say it github_personal_branch

    1. In the past I cloned from github

    2. I checked out github_personal_branch (using Pycharm) and created a local branch, with the same name (but let's say it's local_personal_branch)

    3. From the local_personal_branch I push to the github_personal_branch

Now, on github_personal_branch, I have commits behind and in front of github_master_branch.

I want to get the changes from github_master_branch to my local_personal_branch, fix the conflicts and then push it to the github_personal_branch.

  1. I tried to rebase, but instead I got a lot of commits, all the ones the github_master_branch was ahead, instead of moving header.

  2. I also tried the rebase option in Pycharm, multiple combinations, but I don't understand very well the onto, from fields logic.

  3. I tried a second manual rebase, but besides master I got very old code, that was available some time ago on the local_personal_branch.

alfunx
  • 3,080
  • 1
  • 12
  • 23
user3541631
  • 3,686
  • 8
  • 48
  • 115
  • 1
    Please provide more information about state of both branches. What is your goal? Which code do you want to have on your branch after you are done? – Rozart Oct 02 '19 at 10:14
  • You need to pull changes from github_master_branch to local_personal_branch, fix issues (merge issues), and push force to github_personal_branch. Rebase requires force push anyway, btw it's not a good way neither to force push, neither to rebase. Try to avoid such situations in the future. – Dmitrii Oct 06 '19 at 06:50
  • @user I have edited my answer. – VonC Oct 06 '19 at 16:35

3 Answers3

4

To rebase in Pycharm, you need to make sure you are first on the right branch:

  • checkout local_personal_branch
  • fetch to update origin
  • rebase onto refs/remotes/origin/github_master_branch (onto field), as described here

https://blog.jetbrains.com/ruby/files/2010/12/rebase.png

Rebase requires force push anyway, btw it's not a good way neither to force push, neither to rebase.

I would argue that, in this case, it is: a "local_personal_branch" is personal (to you): you can rebase it and force push it as many time as you want, since you are the only one working on it.

The idea of a rebase is making a future pull request trivial to accept, because your local_personal_branch commits will have been rebased on top of the latest of origin/github_master_branch, which means accepting such a PR would result in a simple fast-forward merge: no conflicts.

Plus, as mentioned here, merging master into a feature branch is not considered as a best practice: you (generally) merge to master, not from it.
See "rebase vs. merge".

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
3

While I am quite experimented with CLI rebase, I never grasp how to use the rebase option of IntelliJ ^^

From what I understand you have the following setup:

     github/master
          v
A-B-C---D-E
     \
      \-F-G
          ^
       personal,
    github/personal

You should have a master branch (local master) somewhere too. If you are not sure of this setup, please provide us the output of the following command:

git log --oneline --decorate --graph local_personal_branch github_personal_branch master github_master_branch

What you want is to rebase you personal branch onto master to get the following graph:

       github/master
            v
A-B-C---D---E---F'---G'
                     ^
                  personal
               github/personal

So the command is:

git rebase --onto github/master C personal
git push --force

To explain it:

  • you want the commits between the commit C and the personal to be put onto the current github/master branch.
  • you push the new personal branch to github. As a rebase does not create a linear history (some previous commits of personal (F, G) are lost and replaced by new "identical" commits (F' and G')) you need to force the push.

For information, your remote repository is probably called origin and not github (see the output of git remote -v) and so you should replace reference to github by origin in the previous commit. The C letter must be replaced by the hash number of the last common commit between master and personal.

Kind.

AlexisBRENON
  • 2,921
  • 2
  • 18
  • 30
  • No need for `--onto` in this case: a simple `git rebase github/master` would be enough to move `personal` on top of `github/master`. – VonC Oct 10 '19 at 09:20
  • @VonC Yes, the `--onto` is redundant in this simple case, like the `C` reference. A simple `git rebase origin/master` would do the job, but being more verbose allow to better grasp what `rebase` do: from where to where, onto what – AlexisBRENON Oct 10 '19 at 11:50
0

Instead of rebasing, use merge, as follows:

  1. Merge the up-to-date (remote) github_master_branch into your local_personal_branch. (By remote I mean the status of that branch on remote; you may want to update your local master first and merge that, but make sure you are using the up to date version)

  2. Fix any conflicts between master and your branch (on local local_personal_branch)

  3. Push local_personal_branch to github_personal_branch.

Now the diff between personal_branch and master should be only the changes made on the personal_branch. This will make it easier to merge it into master later.

Marit
  • 2,399
  • 18
  • 27