4 ms·

I find rebasing can get so insane that most of the times, when I'm ready to submit a pull/merge request to master, I create a whole new branch from master, cher

I find rebasing can get so insane that most of the times, when I'm ready to submit a pull/merge request to master, I create a whole new branch from master, cherry-pick all my commits in order, rebase -i and squash them if I need to, and then push the branch/create a PR/MR. I find this looks a lot cleaner in tools like Gitlab/Bitbucket as well.

philsnow 8y ago
Sounds like you're duplicating work? "git rebase -i master" does pretty much that: starting from master, cherry picks all the commits (in order by default but because you're doing -i you can reorder them, likewise you can omit or amend) and then changes the ref of the branch you were working on to point at the resulting tip commit. I don't think you need to explicitly check out a new branch and then cherry pick.
- kazinator 8y ago
  I.e. you already have not only a "whole new branch from master" but two of them: a remote tracking branch origin/master, and a local master related to it. You don't need a third one.
spockz 8y ago
Is there a way so you can rebase and push without breaking everyone who already pulled your repo? I have this issue continuously when using rebase on branches that have gitlab or github merge/pull requests. I need to create a different branch all of the time.
- ereyes01 8y ago
  You can always define a new branch pointing to your new rebased ref and push/PR that to avoid having to force-push and messing everyone up.
- cesarb 8y ago
  You aren't supposed to rewrite history (which is what rebase does) on which other people are basing work. If people have merge/pull requests on your branch, then people are basing work on your branch, and you shouldn't rewrite it. The best approach (which is what git.git itself uses) is to do the work on a separate branch, which is rebased often; once it's moved to the master branch, it's "frozen" and won't be rebased anymore. All pull requests are based on the master branch, so aren't affected by the constant rebases on the development branch. (Actually, all the work is done on topic branches, what's often rebased/rewritten is a sequence of merges of these topic branches into the master branch.)
  - spockz 8y ago
    That is what I meant. Master is stable, I have my feature or bug fix branch which I already want to show. Nobody is forking from this branch but if the pulled the branch before it will break after my rebase.
- kazinator 8y ago
  Point people to a stable repository that doesn't have non-fastforward changes. Do your history rewrites between your local development repo(s) and a "staging" repo that outsiders do not know about. Only push good changes from "staging" to the public repo. (By "good" I don't mean bug-free code written from an irreproachably perfect design, but simply changes that are not so bad that the best way to fix them is to steamroll their history and rework them entirely.) You can give people access to the staging repo, but then they have to acknowledge that they are willing to deal with some occasional chaos.

philsnow 8y ago

Sounds like you're duplicating work? "git rebase -i master" does pretty much that: starting from master, cherry picks all the commits (in order by default but because you're doing -i you can reorder them, likewise you can omit or amend) and then changes the ref of the branch you were working on to point at the resulting tip commit. I don't think you need to explicitly check out a new branch and then cherry pick.

kazinator 8y ago
I.e. you already have not only a "whole new branch from master" but two of them: a remote tracking branch origin/master, and a local master related to it. You don't need a third one.

spockz 8y ago

Is there a way so you can rebase and push without breaking everyone who already pulled your repo? I have this issue continuously when using rebase on branches that have gitlab or github merge/pull requests. I need to create a different branch all of the time.

ereyes01 8y ago
You can always define a new branch pointing to your new rebased ref and push/PR that to avoid having to force-push and messing everyone up.
cesarb 8y ago
You aren't supposed to rewrite history (which is what rebase does) on which other people are basing work. If people have merge/pull requests on your branch, then people are basing work on your branch, and you shouldn't rewrite it. The best approach (which is what git.git itself uses) is to do the work on a separate branch, which is rebased often; once it's moved to the master branch, it's "frozen" and won't be rebased anymore. All pull requests are based on the master branch, so aren't affected by the constant rebases on the development branch. (Actually, all the work is done on topic branches, what's often rebased/rewritten is a sequence of merges of these topic branches into the master branch.)
- spockz 8y ago
  That is what I meant. Master is stable, I have my feature or bug fix branch which I already want to show. Nobody is forking from this branch but if the pulled the branch before it will break after my rebase.
kazinator 8y ago
Point people to a stable repository that doesn't have non-fastforward changes. Do your history rewrites between your local development repo(s) and a "staging" repo that outsiders do not know about. Only push good changes from "staging" to the public repo. (By "good" I don't mean bug-free code written from an irreproachably perfect design, but simply changes that are not so bad that the best way to fix them is to steamroll their history and rework them entirely.) You can give people access to the staging repo, but then they have to acknowledge that they are willing to deal with some occasional chaos.