0

I've a couple of repo's that contain a master and dev branch. Master represents releases while dev represents the current buildable version. There are also a number of other branches for features which are deleted after merging to dev.

I've recently changed to using the pull request workflow, before that, I performed squashed merges. Some repos are new and have always used the pull request workflow, however, one of the older repos (and most important) used the squashed merge. The revision graph looks like this

enter image description here

At this point, all changes have been committed and pull requests used to merge the changes. Ignoring customs and collections I'd expect a revision graph like this:

enter image description here

My questions are:

  • Is there anything wrong with the first revision graph?

  • How could I get the graph to be more like the second?

Pankwood
  • 1,799
  • 5
  • 24
  • 43
markpirvine
  • 1,485
  • 1
  • 23
  • 54
  • A branch never points to another branch. A branch only points to a commit as in your first figure. – Rickard Körkkö Dec 13 '19 at 17:59
  • I thought upstream IS origin – Khalil Khalaf Dec 13 '19 at 20:09
  • This is a forked repo - upstream is the original, origin is my fork – markpirvine Dec 13 '19 at 20:10
  • @RickardKörkkö, I realise that branches only reference commits - so in both revision graphs everything is pointing to the same commit. I’m just curious why the layout is different? – markpirvine Dec 13 '19 at 20:13
  • Given that branches only point to commits, the second one would be lying. Why would you expect or want a lying layout? – 8bittree Dec 13 '19 at 20:43
  • @8bittree, I understand your point. My understanding is that both diagrams say the same thing, however the second one is neater - as in dev points to the same commit as master - just don’t understand why the layout is different – markpirvine Dec 13 '19 at 20:48
  • But they don't say the same thing. In the former, a change to which commit master points to would have no effect on dev. In the latter, it looks like changes to master would also change dev. – 8bittree Dec 13 '19 at 20:51

1 Answers1

1

Git actually does have symbolic references, in which one reference contains the name of another reference, rather than its value.

Until relatively recently, these mostly didn't work,1 except for the specific case of HEAD. The main HEAD is normally a symbolic reference to some other branch name. The git checkout command, or the new git switch in Git 2.23 and newer, manages this symbolic reference for you.

Meanwhile, reach remote, such as origin can have a symbolic HEAD, e.g., origin/HEAD -> origin/master. Your Git sets these up based on the results it gets when it asks the Git at the URL—the origin Git in this case—what branch its HEAD named. If their HEAD was a symbolic reference to their master, your origin/HEAD should be a symbolic reference to your origin/master.

But apart from these cases, each reference just holds a raw hash ID. The best2 way to draw this is to draw the reference holding the hash ID, or pointing to the Git object selected by that hash ID. Only symbolic references should be drawn as pointing to another reference.

1Try creating symbolic branch sym containing just-created branch name br:

git branch br
git symbolic-ref refs/heads/sym refs/heads/br

List the branches with git branch to make sure it worked. Now ask Git to delete branch sym:

git branch -d sym

Old versions of Git would delete branch br! If your Git deleted sym, you have a Git in which these symbolic refs work better.

2Best is, of course, a matter of opinion, but since I'm writing this answer, I get to use my opinion. :-)

torek
  • 448,244
  • 59
  • 642
  • 775