CODEWITHSUNDEEP
gitgithubbranchrebasepull-request
user1658543
user1658543

Reputation:

Rebase pulled branch which has not been merged by repo owner

I have forked a projekt on Github. I have set up my local version of my fork to update from the original repo by adding it as upstream.

Now i created a feature branch, made changes and pulled to the origin repo. As the changes are huge, the pull has not (yet) been accepted by the repo owner.

Meanwhile i updated my master branch from the original repo´s master doing git pull upstream master a few times, so my feature branch is out of sync with the master branch.

I need them to be synced, because i need to generate documents from both branches and compare them.

What i know (im not a git pro) is that i would first locally commit my stashed changes in my feature branch and then, also locally, rebase my branch against the master (or how this is called in git lingua).

But i read that rebasing will create chaos in other peoples repos.

So how do i do this? Should i close my PR, do the rebasing on a new branch and pull that again? I would like if i could prevent this, because i dont want to pollute the original repo.

Upvotes: 2

Views: 45

Answers (1)

Romain Valeri
Romain Valeri

Reputation: 22057

In many git workflows, you can distinguish between feature branches and "stable" branches.

Take this example (arbitrary workflow, could be different than yours, but just to make the point about stable/feature branches) and consider its history :

     -----------------D <<< feature-bar
    /                  \
---A------------E-------H---J <<< master
    \          / \         /
     B--------C   F---G---I <<< feature-foo

master is a stable branch, it's permanent and reflects the current state of the application. In some workflows, you have more stable branches, one for staging, one for development, one for stable production state, and so on.

Feature branches, in the other hand, are volatile and disposable. Each one is created for a specific need (typically, a bug fix, a new feature), and is deleted when it's finally merged into its stable destination. (In the schema above, feature-bar and feature-foo, but we can also guess that there was a branch pointing to C at some point, which has been deleted after the E merge.)

When a developer works alone on their feature branch, if it's not yet merged, whatever they do on their branch stays on it and that part of history can be changed, by a rebase or any other operation, without ill effects on anyone else.

Of course, rebasing a stable branch would be a big no-no in most cases, because all the other developers share this part of the repo history and would have to resolve potentially nasty conflicts.

I used merges here in my schema and explanation, but a workflow using rebase would also make the same distinction between stable/feature branches.

If you work alone on a feature branch, then create a PR, and then realize you have to rebase it, no trouble, the PR will update itself after you've pushed the new history of the branch, and nothing will be messed in the destination branch's history.

What can be a lot more problematic is to rebase stable branches, shared with others, because it would cause conflicting histories, which, yes, can be nasty to resolve.

The article you linked is very interesting, I agree with the main point, however beware that it can be misleading when you discover git and try to use it efficiently. These are rather advanced considerations, which could be inducing "cargo-cult" practices if followed without a clear understanding. Rebase is a useful tool, don't throw it away.

Upvotes: 1

Related Questions