9

Assume I have a master branch with some commits I want to keep for later documentation and reference but remove them from the master (because I want the master to be on the same state as the upstream repo).

My approach now is, to

  1. Create a new branch from current master state
  2. Reset (--hard) the master to a state which is present in the upstream repo as well

Now, my question is:

  • What happens to the new branch when removing the reference commit from the master?
  • Or am I completely wrong in the understanding of how branches are referenced.

Often branches are shown in the following way, where (to my understanding) D is the basis of the new branch.

A - B - C - D    (master)
             \
                 (new branch)

Is the branch "rebased" automatically or how would you call it? Would it then look like this?

A - B         (master)
     \
      C - D   (new branch)

Last and maybe most general question:

  • Is my approach of keeping the state in a new branch and reset --hard the master branch the right way to achieve my goal of getting my fork back to the upstream state (commit B) without having my commits (C and D) merged?
Romain Valeri
  • 19,645
  • 3
  • 36
  • 61
freiheitsnetz
  • 193
  • 6
  • commits are immutable. You will usually see `A-B-C-D` change to `A-B-C'-D'` after a rebase to reflect the fact that although commits `C` and `C'` introduce the same changes in the source tree, they are different commits. – William Pursell Mar 07 '19 at 18:34

3 Answers3

7

Nothing will "happen" to the branch, since a branch in git is just a lightweight, movable, disposable pointer. Commits are the real thing.

Yes, the overall plan is good, make a new branch to keep the most recent commits, reset master to where it should (I guess origin/master), and this ref on your C,D commits will allow them to stay permanently.

Without creating the branch, they would ultimately be garbage collected, even if they'd stay in the reflog for a while.

And also no, your C and D commits won't be merged into your upstream master if you follow your announced course of action. Go for it.

Romain Valeri
  • 19,645
  • 3
  • 36
  • 61
5

What happens to the new branch when removing the reference commit from the master?

Nothing.

Your question seems based on a misunderstanding of what a branch is. A branch is a type of ref - different from other refs only in that git has a few conventions about where branches point and how they move. A ref is a pointer to a commit[1].

When you reset master, you're just changing the pointer that is the master ref so that it stops pointing at D and starts pointing at B. That doesn't affect the pointer that is the new branch ref in any way.

Commits C and D still exist and are also unaffected by resetting master. It's just that master is no longer pointing to a place from which they can be "reached" (whereas before D could be reached because it's what master pointed to, and C could be reached via Ds parent pointer).

But new branch still points at D, so it can still reach C and D.

So new branch isn't rebased or anything. Rebasing is rewriting and replacing commits because you want to make the same changes they made, relative to a different starting point. That isn't happening here. It's commits that are rebased, and often when rebasing commits a ref goes along for the ride; but when we say 'rebase a branch' that's kind of a shorthand for 'rebase some commits currently reachable from the branch, and then move the branch to point at the new commits'. But here we don't need any of that; we still have our original commits.

The other side of 'a branch is just a pointer' - commits are not "part of" any branch. They exist independent of any branches that might reference them (though git gc will eventually try to dispose of them if it thinks nobody knows how to find them anymore). The commit a branch points to, and the commits that can be reached from there via parent pointers, are said to make up the branch's history... but that's as far as the relationship goes.

So to reiterate and summarize - resetting master only moves a pointer. It doesn't change the commits and doesn't affect other branches.

[1] Some refs can occasionally point to something other than a commit, but that's not too important to this discussion; tl;dr - a branch is a pointer to a commit and nothing more

Mark Adelsberger
  • 42,148
  • 4
  • 35
  • 52
1

Commit chains stay alive while something is pointing to them or else until they are wiped by git gc, and your pre/post reset topology diagram is correct.

bobah
  • 18,364
  • 2
  • 37
  • 70