1

Example I need a previous feature/1 in branch feature/2.

Lil' bit below is some of a way how to get feature/1.

Is there a difference for history when I use git checkout -b or git rebase?

Because we get feature/1 and all commits anyway?

P.S. both features were created from master

// 1 way

HEAD -> feature/1
git checkout -b feature/2

// 2 way

HEAD -> master
git checkout -b feature/2
git rebase feature/1
HackerMF
  • 475
  • 7
  • 18
  • Assuming that `feature/1` is branched off of `master`, your two sequences of commands give the same result. It is only that the `rebase` version is a roundabout way to do what the `checkout` version achieves. – j6t Sep 15 '21 at 05:41
  • Thnx, I think so too, but someone tells me when I use rebase this way I rewrite history. I think he doesn't understand how works rebase – HackerMF Sep 15 '21 at 05:45
  • 2
    You should not ignore those comments in general. It is just that in *this* case where all commits on `master` are **also** in `feature/1` that no history is rewritten. – j6t Sep 15 '21 at 05:49
  • Does this answer your question? [Rebase feature branch onto another feature branch](https://stackoverflow.com/questions/14893399/rebase-feature-branch-onto-another-feature-branch) – Joe Sep 15 '21 at 05:56
  • not really, I meant comparison between git checkout -b feature/2 and git rebase feature/1. Do they the same or not? I think they are the same and @j6t thinks as well – HackerMF Sep 15 '21 at 06:03

1 Answers1

1

Fundamentally, git checkout -b and git rebase do two entirely different things:

  • git checkout -b (or git switch -c) creates a new branch name (and makes this the current branch, with all that this entails—in some cases that's trivial and in others it is not).
  • git rebase copies some set of commits, and then moves an existing branch name. The set may be empty, in which case the branch name move happens as if with git reset --hard, except that Git makes sure the the index and working tree are "clean" first. (There is some complication that can occur here with autostash though.)

This means that it makes little sense to compare them.

Once we know, however, that a branch name simply holds the hash ID of some particular commit, we can see that in some specific cases, no commits are copied and therefore git rebase acts much more like git reset --hard. So even though git reset --hard and git rebase also do very different things, we can compare these two, in some very special cases.

To this, we can add the fact that git checkout -B—note that the B option here is in uppercase, not lowercase—can act like git reset --hard. So now we do have some situations in which the two can be compared. But this is for -B, not for -b.

Finally, we can note that if our git rebase is only going to do the "move the branch" step (the equivalent of git reset --hard), and we already have the branch name pointing to the place we'd like it to move to, then the entire git rebase operation itself is a no-op.

In your case, you've decided not to replace just a git checkout -b with git rebase, but rather to replace a two-command sequence:

  1. git checkout name1
  2. git checkout -b name2

with a different two-command sequence:

  1. git checkout -b name2
  2. git rebase name1

When the second command acts like git reset --hard name1 only, these two sequences produce the same end result. But there's a single command that would produce the right end result, which is probably the one you should use:

  1. git checkout -b name2 name1

This is short and sweet and does what you want all in one step.

torek
  • 448,244
  • 59
  • 642
  • 775