0

my project uses a (remote) master branch and plenty of (remote) feature branches. I usually start my work either on an existing (remote) feature branch or I create one.

The real work is done locally of course, therefore I use git pull/push to keep the remote feature branch in sync with my local work whenever necessary. Merging back to master is done via so called "pull requests" which appears to be a feature added by "bitbucket". I did not do that yet.

Now my issue: I want the changes recently added on master to become visible on my feature branch, but I want to keep my stuff on top, both on remote and local feature branch.

As far as I understand the git way I would

  • rebase remote master onto my remote feature branch
  • sync my remote/local feature branch as usual

and that should be it.

But how do I rebase remote branches onto each other ?

Of course I could e.g.

  • checkout/pull/clone master to a local master branch,
  • do the rebase onto the feature branch locally and
  • push those changes to the remote feature branch.

But that does not "feel right".

Side comment: I am afraid the collegues in the projects do it 'their way' and do not think about it anyway. Whenever conflicts show up somebody will fix them.

Any suggestions about rebasing remote branches ? Or am I missing something else ?

LeGEC
  • 46,477
  • 5
  • 57
  • 104
stacky67
  • 66
  • 5
  • 4
    Rebasing, like most Git operations, is inherently a local operation. Your first approach is the way to go. – Tim Biegeleisen Aug 24 '22 at 08:33
  • 1
    There's not really any such thing as a "remote branch". There are remote-tracking *names*, but those are names for commits in your repository. There are *branch names*, but those are names for commits in your repository. There are branches, but those are things in your repository. Rebasing is about copying commits, so you must obtain those commits, then copy them. You can then send the copied commits to some other Git repository and have that other Git repository remember those commits using a branch name in that Git repository. – torek Aug 24 '22 at 19:45
  • hello experts, thanks for the clarification. I now better understand the git perspective on software revision control etc. Maybe I should point my issue towards bitbucket, because it seems to offer already some standard procedures implicitly involving multiple git commands on the remote side, e.g. merging branches etc. – stacky67 Aug 25 '22 at 10:36
  • I am still thinking about this explanation ... You are writing: there's not really any such thing as a "remote branch". That sounds a little philosophical. Would You as well state: there's not really any such thing as a "local branch" ? To my understanding the only difference is that the "remote" one isn't local, whether it "exists" at all or not ;) => question: why do 'transaction-like' operations like 'rebase' exist on two local branches, on the combination of local and remote branches (pull --rebase) but not on two remote branches (located on the same repo or not) ? – stacky67 Aug 25 '22 at 12:13
  • `git pull --rebase` is simply `git fetch` (download commits to your local computer) followed by `git rebase` (create new copies of same of your local commits and then forget about the old ones). If you want to upload commits to a server, `git push` has to be used. A word of warning though: do not rebase master (or any other shared branch). – knittl Oct 20 '22 at 11:59

0 Answers0