4 ms·

A look how branches work in Git

41 points by nsoonhui 6y ago

arxanas 6y ago
The article talks about how branches are used for experimentation, but my opinion is that branches are actually often too heavyweight in Git – they're not convenient to use for local prototyping. I made the branchless workflow to improve on this use-case: https://github.com/arxanas/git-branchless https://github.com/arxanas/git-branchless
- neolog 6y ago
  What does it do?
  - arxanas 6y ago
    It supports a workflow where you make commits without having to associate them with branches. It's similar to the Mercurial workflows used at Google/Facebook.
    - neolog 6y ago
      I mean mechanically, what is it actually doing
      - arxanas 6y ago
        I'm not sure specifically what you're asking about, but you can see details about the architecture here: https://github.com/arxanas/git-branchless/wiki/Architecture https://github.com/arxanas/git-branchless/wiki/Architecture
- dfabulich 6y ago
  I watched your demo video and I don't see any advantages over using named branches, and you describe no specific advantages in your README. You just didn't give your branch a name, and referred to commits by ID. Fine, I guess, but are names so bad that you're gonna adopt a non-standard git workflow? `git undo` is cool. There have been a number of fun variations on it over the years, and yours seems fine, but it's usually a leaky abstraction. I expect that yours is, too, but that's just because git itself is a leaky abstraction; it's just really hard to build a strong foundation on sand. https://github.com/mapmeld/gitjk https://github.com/mapmeld/gitjk https://github.com/tj/git-extras/blob/master/man/git-undo.md https://github.com/tj/git-extras/blob/master/man/git-undo.md https://github.com/janekr/git-undo https://github.com/janekr/git-undo
  - arxanas 6y ago
    > I watched your demo video and I don't see any advantages over using named branches, and you describe no specific advantages in your README. It's hard to motivate a workflow change, especially since this one adds no fundamentally new capabilities to Git. In the same way, the git-flow workflow offers no new capabilities, but some people still find it useful. As per the README, I find that it reduces the friction for dealing with these use-cases, compared to a branch-based workflow: * Switching between work tasks. * Separating minor cleanups/refactorings into their own commits, for ease of reviewability. * Extensively rewriting local history before submitting code for review. * Performing speculative work which may not be ultimately committed. * Working on top of work that you or a collaborator produced, which is not yet checked in. * Losing track of git stashes you made previously. Of course, you can do all this with branches too, and many people will prefer branches for these tasks. You have to be the kind of person who performs extensive "surgery" on your Git history. > but are names so bad that you're gonna adopt a non-standard git workflow? There's no interoperability problems between using this workflow and collaborating with others. In the worst case, you can always make a branch if you need to. > `git undo` is cool. There have been a number of fun variations on it over the years, and yours seems fine, but it's usually a leaky abstraction. I expect that yours is, too, but that's just because git itself is a leaky abstraction; it's just really hard to build a strong foundation on sand. The particular feature that this `git undo` provides that others don't is that it can undo bad rebases/amends/merges/etc. (without having to resort to the reflog). This seems to be an area that many beginner to intermediate Git users struggle with.
tomphoolery 6y ago
I think the moment that Git really clicked for me was realizing the following 3 tenets: 1. Commits are a SHA that points to a given state of the codebase _and_ its parent. The latter part is very important for the next 2 tenets... 2. Branches are just named commits but you can commit more stuff on top of them to change the position of the named commit. 3. Tags are just branches that don't have that additional mutability. At the end of the day, branching and tagging is just about naming things. Because Git's higher-level primitive is a commit, and a commit knows who its parent is, all of this stuff can "just work" without much effort or overhead. Now some advanced Git folks will probably comment that this is an over-simplified understanding of how this software works, but keep in mind this is intended for people who have never used Git or indeed a version control system of any kind in their lives. You need to have a basic understanding of its concepts before you can get into the nitty-gritty between the "plumbing" and "porcelain".
- chociej 6y ago
  I don't think it's oversimplified at all. The concepts are pretty simple, just rarely explained nicely.
- smusamashah 6y ago
  More simply, its a linked list where we add on tail instead of head.
smusamashah 6y ago
This article looks a bit like what I had written long time ago. https://xosh.org/explain-git-in-simple-words/ https://xosh.org/explain-git-in-simple-words/
bobbydreamer 6y ago
My full understanding of Git, I have dumped it here in my site. https://bobbydreamer.com/44-git-theory-1 https://bobbydreamer.com/44-git-theory-1 Git Internals are really fascinating. Simple concept, wonderfully done. Git is a gem.

41 points by nsoonhui 6y ago

The article talks about how branches are used for experimentation, but my opinion is that branches are actually often too heavyweight in Git – they're not convenient to use for local prototyping. I made the branchless workflow to improve on this use-case: https://github.com/arxanas/git-branchless https://github.com/arxanas/git-branchless

neolog 6y ago
What does it do?
- arxanas 6y ago
  It supports a workflow where you make commits without having to associate them with branches. It's similar to the Mercurial workflows used at Google/Facebook.
  - neolog 6y ago
    I mean mechanically, what is it actually doing
    - arxanas 6y ago
      I'm not sure specifically what you're asking about, but you can see details about the architecture here: https://github.com/arxanas/git-branchless/wiki/Architecture https://github.com/arxanas/git-branchless/wiki/Architecture
dfabulich 6y ago
I watched your demo video and I don't see any advantages over using named branches, and you describe no specific advantages in your README. You just didn't give your branch a name, and referred to commits by ID. Fine, I guess, but are names so bad that you're gonna adopt a non-standard git workflow? `git undo` is cool. There have been a number of fun variations on it over the years, and yours seems fine, but it's usually a leaky abstraction. I expect that yours is, too, but that's just because git itself is a leaky abstraction; it's just really hard to build a strong foundation on sand. https://github.com/mapmeld/gitjk https://github.com/mapmeld/gitjk https://github.com/tj/git-extras/blob/master/man/git-undo.md https://github.com/tj/git-extras/blob/master/man/git-undo.md https://github.com/janekr/git-undo https://github.com/janekr/git-undo
- arxanas 6y ago
  > I watched your demo video and I don't see any advantages over using named branches, and you describe no specific advantages in your README. It's hard to motivate a workflow change, especially since this one adds no fundamentally new capabilities to Git. In the same way, the git-flow workflow offers no new capabilities, but some people still find it useful. As per the README, I find that it reduces the friction for dealing with these use-cases, compared to a branch-based workflow: * Switching between work tasks. * Separating minor cleanups/refactorings into their own commits, for ease of reviewability. * Extensively rewriting local history before submitting code for review. * Performing speculative work which may not be ultimately committed. * Working on top of work that you or a collaborator produced, which is not yet checked in. * Losing track of git stashes you made previously. Of course, you can do all this with branches too, and many people will prefer branches for these tasks. You have to be the kind of person who performs extensive "surgery" on your Git history. > but are names so bad that you're gonna adopt a non-standard git workflow? There's no interoperability problems between using this workflow and collaborating with others. In the worst case, you can always make a branch if you need to. > `git undo` is cool. There have been a number of fun variations on it over the years, and yours seems fine, but it's usually a leaky abstraction. I expect that yours is, too, but that's just because git itself is a leaky abstraction; it's just really hard to build a strong foundation on sand. The particular feature that this `git undo` provides that others don't is that it can undo bad rebases/amends/merges/etc. (without having to resort to the reflog). This seems to be an area that many beginner to intermediate Git users struggle with.

tomphoolery 6y ago

I think the moment that Git really clicked for me was realizing the following 3 tenets: 1. Commits are a SHA that points to a given state of the codebase _and_ its parent. The latter part is very important for the next 2 tenets... 2. Branches are just named commits but you can commit more stuff on top of them to change the position of the named commit. 3. Tags are just branches that don't have that additional mutability. At the end of the day, branching and tagging is just about naming things. Because Git's higher-level primitive is a commit, and a commit knows who its parent is, all of this stuff can "just work" without much effort or overhead. Now some advanced Git folks will probably comment that this is an over-simplified understanding of how this software works, but keep in mind this is intended for people who have never used Git or indeed a version control system of any kind in their lives. You need to have a basic understanding of its concepts before you can get into the nitty-gritty between the "plumbing" and "porcelain".

chociej 6y ago
I don't think it's oversimplified at all. The concepts are pretty simple, just rarely explained nicely.
smusamashah 6y ago
More simply, its a linked list where we add on tail instead of head.

smusamashah 6y ago

This article looks a bit like what I had written long time ago. https://xosh.org/explain-git-in-simple-words/ https://xosh.org/explain-git-in-simple-words/

bobbydreamer 6y ago

My full understanding of Git, I have dumped it here in my site. https://bobbydreamer.com/44-git-theory-1 https://bobbydreamer.com/44-git-theory-1 Git Internals are really fascinating. Simple concept, wonderfully done. Git is a gem.