<story><title>Git Branches: Intuition and Reality</title><url>https://jvns.ca/blog/2023/11/23/branches-intuition-reality/</url></story><parent_chain><item><author>jansan</author><text>This was the most useful piece of information that I have ever read about Git.&lt;p&gt;But what happens if you merge branch A into beanch B? A and B will both contain the commits of A, but in B there may be commits of B between the commits that were merged. Do the same commits of A then have different parents depending on which branch they are on?</text></item><item><author>riperoni</author><text>While the explanation is right in some sense, it misses a few points.&lt;p&gt;Branches are pointers to a commit and that pointer is refreshed when a new commit is created. One could say they are a wandering tag (without explaining a tag for now).&lt;p&gt;The actual chain of commits that represent what we see as branch comes from the commits themselves. Those commits point back to their parent commit.&lt;p&gt;And then one can see why no branch has any special meaning: It is a chain of related commits with a named entrypoint. Once you delete a branch (i.e. the named wandering pointer to a commit), you cannot identify a branch as such anymore. It is just a chain of related commits without a named label now. And nothing besides the name distinguished the branch from other commit chains before.&lt;p&gt;The master&amp;#x2F;dev&amp;#x2F;release branches are then a convention to keep an updated commit pointer on the chain of commits containing changes of interest.</text></item></parent_chain><comment><author>tharkun__</author><text>I keep repeating this every time someone talks about git and finds something weird or doesn&amp;#x27;t get branches, so I&amp;#x27;m really glad your parent mentioned it as well and I know there&amp;#x27;s someone else out there that &amp;quot;gets&amp;quot; that:&lt;p&gt;&lt;pre&gt;&lt;code&gt;    In git it&amp;#x27;s all just labels&amp;#x2F;pointers
&lt;/code&gt;&lt;/pre&gt;
It&amp;#x27;s not useful at all to think about branches as the user sees them as &amp;quot;things&amp;quot; of their own. Branches don&amp;#x27;t &amp;quot;have&amp;quot; anything. Branches in that sense are just convenient labels.&lt;p&gt;Of course actual &amp;quot;branches&amp;quot; in the commit tree exist whether you label them or not. Until `git` does a garbage collection and gets rid of anything that doesn&amp;#x27;t have a pointer ultimately leading to it - something that a human would understand aka branch&amp;#x2F;tag. And that&amp;#x27;s why we call these labels &amp;quot;branches&amp;quot; as well but it&amp;#x27;s actually one word for two things here. The actual tree branch and the label that&amp;#x27;s called branch.&lt;p&gt;And a branch and a tag are basically the same exact thing underneath, just a file in the `.git` directory somewhere that contains a commit hash. All the meaning and differentiation of branch or tag is just in the human brain and how we and our tools treat them. Such as if you look at a particular commit in your tool of choice, it will tell you which branch it&amp;#x27;s part of. To create a branch you can literally just create a thousand randomly named files in the right part of the `.git` directory containing the same commit hash and suddenly this commit &amp;quot;is on all those branches&amp;quot;. That&amp;#x27;s what git does and why creating a branch in git is so super fast.</text></comment>
<story><title>Git Branches: Intuition and Reality</title><url>https://jvns.ca/blog/2023/11/23/branches-intuition-reality/</url></story><parent_chain><item><author>jansan</author><text>This was the most useful piece of information that I have ever read about Git.&lt;p&gt;But what happens if you merge branch A into beanch B? A and B will both contain the commits of A, but in B there may be commits of B between the commits that were merged. Do the same commits of A then have different parents depending on which branch they are on?</text></item><item><author>riperoni</author><text>While the explanation is right in some sense, it misses a few points.&lt;p&gt;Branches are pointers to a commit and that pointer is refreshed when a new commit is created. One could say they are a wandering tag (without explaining a tag for now).&lt;p&gt;The actual chain of commits that represent what we see as branch comes from the commits themselves. Those commits point back to their parent commit.&lt;p&gt;And then one can see why no branch has any special meaning: It is a chain of related commits with a named entrypoint. Once you delete a branch (i.e. the named wandering pointer to a commit), you cannot identify a branch as such anymore. It is just a chain of related commits without a named label now. And nothing besides the name distinguished the branch from other commit chains before.&lt;p&gt;The master&amp;#x2F;dev&amp;#x2F;release branches are then a convention to keep an updated commit pointer on the chain of commits containing changes of interest.</text></item></parent_chain><comment><author>seba_dos1</author><text>&amp;gt; Do the same commits of A then have different parents depending on which branch they are on?&lt;p&gt;Absolutely not. Commits are immutable (representing whole repo state, &lt;i&gt;not&lt;/i&gt; a diff), and branches are just (mutable) pointers to them.&lt;p&gt;As the sibling already noted, a merge commit is just a regular commit. It simply points to multiple parents, &amp;quot;merging&amp;quot; them. Aside of the whole machinery to resolve conflicts etc. that&amp;#x27;s pretty much all there is to it.&lt;p&gt;When your graph topology allows it, you can also merge branches without generating a new commit (so called &amp;quot;fast forward&amp;quot; merges) - such a merge does nothing but rewrites the branch pointer. You can also create merge commits that point to more parents than two (&amp;quot;octopus&amp;quot; merges). Reconciling the commits&amp;#x27; content can get quite complicated in such cases, but from the repo graph perspective it&amp;#x27;s nothing special.</text></comment>