0

I have a scenario where I have a git branch (b) based off of develop.

I then made changes to branch (b) and pushed it to remote (b).

Some other developer made a PR and had their code merged into develop.

I then pull the changes from remote/develop and rebased my local branch (b) onto develop.

I then make more changes to my local branch (b)

When I commit and push my changes, I get a rejected error:

[! [rejected]        feature/b-> feature/b (non-fast-forward)
error: failed to push some refs to 'gitlab'
hint: Updates were rejected because the tip of your current branch is behind]

What I normally tend to do is to do a --force push.

But I'm wondering if this is the right approach.

Gino Mempin
  • 25,369
  • 29
  • 96
  • 135
Bondo Kalombo
  • 31
  • 3

2 Answers2

3

Your push was rejected because your local copy of your branch has a different history than the remote copy, because you rebased. Considering that you rebased intentionally, and that you want the remote version to get those changes, using force is entirely appropriate if you’re confident that nobody else is also working from the remote copy of your branch.

The best way to ensure that you’re not changing a branch that someone else is to make your own fork of the repo and push your changes to a branch in your fork; when you’re ready, you then make a pull request back to the develop branch in the “shared” repo. If each developer on your team has their own fork of each project’s repository, and if you all understand that personal forks of a repo are meant for tracking your own work in progress, there’s no real danger of creating a problem for someone else.

An alternative would be to push your rebased branch to some new remote branch, leaving the un-rebased one alone. There’s little point in that if you know you’re the only person using the branch, though.

Caleb
  • 124,013
  • 19
  • 183
  • 272
-1

Once you have made b "public" by pushing it to the remote (where anyone else might pull it), you can't effectively rebase your local branch any more.

Instead, you should have merged the updated develop into b, which does not rewrite history. Having done this, you can reliably push additional changes from your local b to the remote b, and others will simply see that you have resolved any differences between b and develop by merging, rather than seeing an unexpected change in where b branched off develop in the first place.

chepner
  • 497,756
  • 71
  • 530
  • 681
  • 2
    You’re not wrong, but you’re assuming that any branch on a remote repo is fair game for anyone else to use, and depending on the team that may or may not be valid. – Caleb Dec 03 '22 at 18:31
  • True, but unless there are per-branch access controls enabled by something outside Git itself, I think you have to assume that the branch could be used by someone else. (Whether they are "supposed" to or not.) – chepner Dec 03 '22 at 20:19
  • 2
    So what's the worst thing that could happen? You force push an update to a branch that nobody else is meant to be using, and the interloper then has to rebase. Nobody's computer is going to explode if you rewrite the history of a branch that you never intended to share. Obviously, much depends on the context, but there are at least some contexts where rebasing and force pushing are not just acceptable, they're standard operating procedure, and there's nothing wrong with that. – Caleb Dec 04 '22 at 07:42
  • 1
    I'm with @Caleb here, but this very discussion makes me think this question is fundamentally opinion based... – joanis Dec 05 '22 at 02:53
  • It depends on your team's workflow, but I'm of the opinion that if you have a shared repository, you have to assume others might look at any branch you put there. Force-pushing creates the opportunity for a problem that doesn't need to exist. If you want to push local branches somewhere else as a back up (or if you develop on multiple machines and want a single private source-of-truth for your own work, a fork might be more appropriate). – chepner Dec 05 '22 at 13:37
  • @chepner Agree 100% that it really depends on your team's workflow, and it'd be nice if the OP had provided a little more context for their question so that we don't have to guess what their situation is. That said, the things you might do to avoid force-pushing (like merging, or not pushing a branch with work in progress) create their own problems, so deciding whether or not to force push means deciding which problem you most want to avoid. – Caleb Dec 05 '22 at 21:59