11 ms·

Git Worktrees and GitButler

104 points by chmaynard 3y ago

Jenk 3y ago
I am struggling to appreciate how this is _not_ a completely flawed workflow. Are many teams doing this? What is the workflow like that benefits from this? What's the "shit not _that_ branch":commit ratio?
- corytheboyd 3y ago
  Personally this sounds completely reasonable to me (especially with lazygit) > You can stash everything, create a new branch, switch to it, fix the bug, commit and push it, then switch back to what you were working on. Also comfortable with fixing the bug on my current branch, leaving it there to validate as I complete the other stuff, then later pull commits out to new branches to create atomic PRs. Assuming the bug can wait that is, otherwise yep off to a new branch, and no amount of git magic prevents an interruption from being disruptive. I know worktrees are a thing but I feel like the branching model is enough complexity to both be useful and remember. No problem if people want to use a more complex workflow with a GUI, this is for them, not for me.
- dogleash 3y ago
  What part exactly? The worktrees? If you're just talking worktrees, the benefit is what it says on the tin, multiple parallel working directories. They're a nice to have, not world-changing or anything. The example in the article is contrived to sell a separate kind of workflow tool in the product he's building. I don't use worktrees like that. My use case is heretical software development, but sometimes I work with projects that take a long time to build. And even longer to test. Worktrees let me minimize the amount of rebuilding when switching branches, or kick off a full test run and go work in another branch.
- neandrake 3y ago
  We’re not yet using git, but we have one repository with multiple branches, one for each released version (on-prem software, not a service run). We are in regular active development of ~3 branches at a time. Most developers dealing with this will have multiple clones checked out rather than switch branches in the same clone. The reason for doing so is we often make significant project structural changes in each release, and the act of switching branches updating thousands of files and lots of structural changes often causes most IDEs to combust. Pointing the IDE to a different cloned workspace works much more smoothly. After switching to git I anticipate it will include our own guides for using worktrees for such a purpose.
- numbsafari 3y ago
  Another way to look at this, is that a working copy is a projection of the state of a repository at a particular commit. If you are working on or with a tool that utilizes the repository contents to drive it, then you can expose multiple instances or versions of the tool from those projections, while leveraging a shared content cache and upstream configuration. For example, let's say you are working on a static site (this is just an example). You can have a web server running that is serving the main worktree from https://mysite.local/ https://mysite.local/, and any worktrees from https://mysite.local/~[worktree]/ https://mysite.local/~[worktree]/. Then, if you want to make a particular branch available for someone to review in their browser to provide feedback, you can direct them to the worktree URL while you continue doing other work either in your main branch, or on other branches altogether.
renewiltord 3y ago
I use worktrees very rarely. For instance, if I'm trying to figure out some very hard to reproduce bug that disappeared between one revision and another and I need to examine the code. I can't just bisect if the feature set or interfaces are different so I need both versions of the code. Sometimes I cherry-pick around to restore some similarity. But for this two-patch flow, I'm just going to use two branches.
- frfl 3y ago
  Being able to explore code from another revision in your regular editor side by side with your other branch (two editor instances) is a big plus of worktrees. Maybe it wouldn't work if you use some heavyweight editor like Visual Studio or Eclipse or if your project is massive and IDE intelligence features take up a lot of RAM, but for lightweight editors, small-medium projects it works great. I personally use it all the time on longer lived projects. Stashing/unstashing is fine, but I like really like the flexibility of just being able to switch over to another branch to fix something, review a PR, or anything else with zero mental overhead of keeping track of stashed work.
  - renewiltord 3y ago
    I used to use it myself. Not too much of problem. I just didn't use it enough to warrant use. Was quite straightforward to just switch up. But I shall try it again and see.
  - chatmasta 3y ago
    The thing that annoys me about worktrees is that you can't have two checked out to the same commit at the same time [0], which can be inconvenient when I forget about one that I had open a few days ago. This also breaks the feeling of isolation, since the issue doesn't exist if I do a fresh `git clone` to another directory, so it begs the question of what fragility is present in worktrees that isn't in a fresh clone. In other words, I wouldn't feel safe doing weird Git operations in a worktree, so why use one in the first place? If I want a true throwaway repo, I'll just re-clone in another directory (and make sure to remove the remote, to be extra safe in case I accidentally push). Also, git worktree requires me to make a new directory anyway! So why would I not just put a fresh clone in there? To save a few megabytes of the .git index? [0] https://stackoverflow.com/a/39668520 https://stackoverflow.com/a/39668520
coldtea 3y ago
>Let's take an example. Let's say you are working on a feature. Your boss interrupts you (, bosses, right?) and says "we need this bug fixed". Or maybe you just notice the bug as you're working. Whatever it is, you need to switch contexts while in the middle of something. Now you have a few options. - You can fix the bug and commit it into your feature branch and try to get them both deployed together. - You can stash everything, create a new branch, switch to it, fix the bug, commit and push it, then switch back to what you were working on. - You could locally clone the repository to a new directory and work on the other branch there, then push it back into the main one and then push from there back upstream. -- What? Why couldn't you, like, create another branch off of main, switch to that, and fix the bug there, then resume working on your feature branch? Then when one of the two (bugfix or feature branch) is merged into main, you rebase main into the other.
- deleted 3y ago
  [deleted]
- corytheboyd 3y ago
  Completely agreed, this is pretty basic git that I would expect experienced developers to have down. This isn’t even a UI vs CLI argument, it’s the same idea in either case. I’ll keep an open mind, but if you’re going to shake up a workflow as solid and well understood as git, you better have a damn good offering.
- Huggernaut 3y ago
  I don't particularly care either way but how is that meaningfully different from option 2? You need to do something with your WIP in either case before switching to the new branch.
  - coldtea 3y ago
    Well, stashing is ok for short term context switch, but it's not that organized or neat. You're supposed to be working in a feature branch when your were given the bug to fix. Would you not have commited (or, worse, pushed) anything to it already? Most times you already have, so it's not like stashing your latest changes and getting to the latest state of the feature branch is neutral. Plus, what big benefit would stashing have, since you'll still need to create a separate bugfix branch to create the bugfix PR off anyway? If you get to context switch while you were working on my-feature-branch, you still need to create my-bugfix-branch and push the fix from that, no? Besides nobody guarantees you ahead of time that the bug will just be solved fast and they get to return to working on the feature pronto. So a bugfix branch makes more sense than a stash, which is more of a short term thing. Just making a bugfix branch is neater.
thisisthenewme 3y ago
I've started using worktrees recently and I have nothing but praise for it. It's especially useful to me because I work on multiple features and want to reduce friction from context switching. I basically have a structure like `/worktrees/<project>/<worktree>`. I use it alongside direnv and have my .envrc in the top-level project. That essentially allows me to set up project-specific environments for all of my worktrees. This works neatly with emacs projectile mode and lets me switch between different projects/features seamlessly. My head feels a lot lighter not having to worry about my git branch state, stashing changes, and all that jazz. I think it's a great tool to have in your repertoire and to use depending on your needs.
- lathiat 3y ago
  I do that to but for the many stable branches of OpenStack/Ceph/etc that I’m working on at once (working on the distro/backporting side often back porting patches 3-8 releases). It’s great.
- CuriousCosmic 3y ago
  this is what I do as well but my structure is `~/git/<project>/<worktree>` for the worktrees and a bare git repo is stored in `~/git/<project>/.git`. The workflow I do is 1. git clone https://path.to/repo.git https://path.to/repo.git 2. mv repo/.git repo.git && rm -rf ./repo && mkdir repo && mv repo.git repo/.git && cd repo 3. git config --bool core.bare true Now you can just create worktrees in the root of the git repo. This has the advantage that the `~/git/<project>` directory is still understood as root of the git repo and the worktrees are never checked out inside the working tree directory.
  - vaibhavsagar 3y ago
    Why not `git clone --bare`?
    - v7engine 3y ago
      I've tried this and it seems to be working fine. git clone --bare https://path.to/repo.git https://path.to/repo.git mv repo.git .git now we can create worktrees in the same folder.
avgcorrection 3y ago
The first big thread on GitButler (recent) left me scratching my head. All the material with jargon like “virtual branches” just left me confused. It was like jumping into a how-to on why choose a Ferrari without first understanding what a car is. This clears things up nicely. I mostly use worktrees for very separate things. Like: long-running build, way old or way new versions of the app. Then it doesn’t make sense to mix-and-match virtual branches. So when I want to build the app for deployment I don’t want to worry about whatever other changes getting in the way. Git worktrees doesn’t solve the same problem as what GitButler does. Worktrees is a streamlined way of the manual separate-clone workflow for the same repository. (Technically they are all distinct repositories once you clone them but ya know.) I do have use for separate-from-branch files. Like notes to myself and test scripts that aren’t going into the branch. Crucially these files have nothing to do with the main work: the files themselves are not involved, so there can never be merge conflicts. This GitButler workflow makes sense for things that (1) won’t cause merge conflicts and (2) which won’t step on each others’ toes. The example about a translation and code change is nice. Doing a translation at the same time as a code change is not likely to “break the build”.
- ratrocket 3y ago
  For reference & context, I believe (I hope!) this is the "first big thread on GitButler": https://news.ycombinator.com/item?id=39356042 https://news.ycombinator.com/item?id=39356042
  - avgcorrection 3y ago
    https://news.ycombinator.com/item?id=39357068 https://news.ycombinator.com/item?id=39357068 The submitter unhelpfully didn’t mention the name in the title.
zamalek 3y ago
Worktrees have been a massive savior for me when using Rider (which is all that I use them for). Previously, switching branches would cause the cache to become out-of-date; which would be fine if amending it didn't break 80% of the time (causing spurious code issues etc.). It works just fine with Sublime Merge, so long as you add the worktree as the repo - not the bare repo. I do wish there was better integration.
- MissTake 3y ago
  Is there now native control for Worktrees with Rider (or any of the JB Tools for that matter)? I tried Worktrees a couple of years ago but not having any integration with them with Rider led me to walk away.
  - zamalek 3y ago
    I'm not sure unfortunately. I vastly prefer directory-centric SCM over project-centric.
timetraveller26 3y ago
> Then we go to our GitButler UI and we see that an anonymous virtual branch has been automatically created, because it saw new changes. We can just drag one of the files into a new virtual branch lane, then commit and push both at the same time. This is where he lost me, do I now need an UI to use git? ridiculous
- scubbo 3y ago
  > do I now need an UI to use git You and I don't - but, judging by what I've seen from coworkers, we are in the minority.
uses 3y ago
Worktrees are pretty great but I don't understand why I can't have the same branch checked out on two worktrees? I get why committing to a branch checked out elsewhere might be bad, but in that case, just prevent me from committing, like "you can't commit because the branch is checked out elsewhere - maybe create a new branch".
- renewiltord 3y ago
  In general, `git` seems to fight changing checked out code. You can't push refs to a repo on a checked out branch, for example.
- CuriousCosmic 3y ago
  You can absolutely check it out in multiple places. You get a warning because the behavior is unintuitive. If you want to force it to do it anyways you just use -f/--force. When you check out a branch, the expectation is that the working tree is in sync with the current head commit. If you check out the same branch in multiple places, then if you commit on worktree a, worktree b won't say that it's still on the old commit, it'll just say that the diff between the current head and the contents of worktree b's working directory are a bunch of uncommitted changes. That's why it's unintuitive. This is clearly not the intended behavior for most users when they want to check out the same branch in multiple places. They want to check out a given commit that happens to be the head of the current branch in multiple places. To do that you use --detach so that the worktree head points to the commit rather than the branch itself.
rvdginste 3y ago
For a lot of projects, I have 2 worktrees, where one is for my own work on the project, and the other one is for reviewing other people's code. That means that I can easily do a review (I like having the code open in my IDE during a review), without having to stash my own work.
cycomanic 3y ago
I didn't know about worktrees, sounds a lot like bazaar used to do branches which I always considered much more convenient than gits way. I think I start using it straight away. Cheers Jochen
v7engine 3y ago
I've recently read about worktrees and currently trying to incorporate it in my work routine. For NodeJS applications, it seems we need to create a soft link to point to the node_modules folder in "main" worktree in all worktrees. Otherwise we need to do a npm install in each of the worktree, and knowing how big the node_modules folder can be, a lot of disk space and time is wasted.

104 points by chmaynard 3y ago

Jenk 3y ago

I am struggling to appreciate how this is _not_ a completely flawed workflow. Are many teams doing this? What is the workflow like that benefits from this? What's the "shit not _that_ branch":commit ratio?

corytheboyd 3y ago
Personally this sounds completely reasonable to me (especially with lazygit) > You can stash everything, create a new branch, switch to it, fix the bug, commit and push it, then switch back to what you were working on. Also comfortable with fixing the bug on my current branch, leaving it there to validate as I complete the other stuff, then later pull commits out to new branches to create atomic PRs. Assuming the bug can wait that is, otherwise yep off to a new branch, and no amount of git magic prevents an interruption from being disruptive. I know worktrees are a thing but I feel like the branching model is enough complexity to both be useful and remember. No problem if people want to use a more complex workflow with a GUI, this is for them, not for me.
dogleash 3y ago
What part exactly? The worktrees? If you're just talking worktrees, the benefit is what it says on the tin, multiple parallel working directories. They're a nice to have, not world-changing or anything. The example in the article is contrived to sell a separate kind of workflow tool in the product he's building. I don't use worktrees like that. My use case is heretical software development, but sometimes I work with projects that take a long time to build. And even longer to test. Worktrees let me minimize the amount of rebuilding when switching branches, or kick off a full test run and go work in another branch.
neandrake 3y ago
We’re not yet using git, but we have one repository with multiple branches, one for each released version (on-prem software, not a service run). We are in regular active development of ~3 branches at a time. Most developers dealing with this will have multiple clones checked out rather than switch branches in the same clone. The reason for doing so is we often make significant project structural changes in each release, and the act of switching branches updating thousands of files and lots of structural changes often causes most IDEs to combust. Pointing the IDE to a different cloned workspace works much more smoothly. After switching to git I anticipate it will include our own guides for using worktrees for such a purpose.
numbsafari 3y ago
Another way to look at this, is that a working copy is a projection of the state of a repository at a particular commit. If you are working on or with a tool that utilizes the repository contents to drive it, then you can expose multiple instances or versions of the tool from those projections, while leveraging a shared content cache and upstream configuration. For example, let's say you are working on a static site (this is just an example). You can have a web server running that is serving the main worktree from https://mysite.local/ https://mysite.local/, and any worktrees from https://mysite.local/~[worktree]/ https://mysite.local/~[worktree]/. Then, if you want to make a particular branch available for someone to review in their browser to provide feedback, you can direct them to the worktree URL while you continue doing other work either in your main branch, or on other branches altogether.

renewiltord 3y ago

I use worktrees very rarely. For instance, if I'm trying to figure out some very hard to reproduce bug that disappeared between one revision and another and I need to examine the code. I can't just bisect if the feature set or interfaces are different so I need both versions of the code. Sometimes I cherry-pick around to restore some similarity. But for this two-patch flow, I'm just going to use two branches.

frfl 3y ago
Being able to explore code from another revision in your regular editor side by side with your other branch (two editor instances) is a big plus of worktrees. Maybe it wouldn't work if you use some heavyweight editor like Visual Studio or Eclipse or if your project is massive and IDE intelligence features take up a lot of RAM, but for lightweight editors, small-medium projects it works great. I personally use it all the time on longer lived projects. Stashing/unstashing is fine, but I like really like the flexibility of just being able to switch over to another branch to fix something, review a PR, or anything else with zero mental overhead of keeping track of stashed work.
- renewiltord 3y ago
  I used to use it myself. Not too much of problem. I just didn't use it enough to warrant use. Was quite straightforward to just switch up. But I shall try it again and see.
- chatmasta 3y ago
  The thing that annoys me about worktrees is that you can't have two checked out to the same commit at the same time [0], which can be inconvenient when I forget about one that I had open a few days ago. This also breaks the feeling of isolation, since the issue doesn't exist if I do a fresh `git clone` to another directory, so it begs the question of what fragility is present in worktrees that isn't in a fresh clone. In other words, I wouldn't feel safe doing weird Git operations in a worktree, so why use one in the first place? If I want a true throwaway repo, I'll just re-clone in another directory (and make sure to remove the remote, to be extra safe in case I accidentally push). Also, git worktree requires me to make a new directory anyway! So why would I not just put a fresh clone in there? To save a few megabytes of the .git index? [0] https://stackoverflow.com/a/39668520 https://stackoverflow.com/a/39668520

coldtea 3y ago

>Let's take an example. Let's say you are working on a feature. Your boss interrupts you (, bosses, right?) and says "we need this bug fixed". Or maybe you just notice the bug as you're working. Whatever it is, you need to switch contexts while in the middle of something. Now you have a few options. - You can fix the bug and commit it into your feature branch and try to get them both deployed together. - You can stash everything, create a new branch, switch to it, fix the bug, commit and push it, then switch back to what you were working on. - You could locally clone the repository to a new directory and work on the other branch there, then push it back into the main one and then push from there back upstream. -- What? Why couldn't you, like, create another branch off of main, switch to that, and fix the bug there, then resume working on your feature branch? Then when one of the two (bugfix or feature branch) is merged into main, you rebase main into the other.

deleted 3y ago
[deleted]
corytheboyd 3y ago
Completely agreed, this is pretty basic git that I would expect experienced developers to have down. This isn’t even a UI vs CLI argument, it’s the same idea in either case. I’ll keep an open mind, but if you’re going to shake up a workflow as solid and well understood as git, you better have a damn good offering.
Huggernaut 3y ago
I don't particularly care either way but how is that meaningfully different from option 2? You need to do something with your WIP in either case before switching to the new branch.
- coldtea 3y ago
  Well, stashing is ok for short term context switch, but it's not that organized or neat. You're supposed to be working in a feature branch when your were given the bug to fix. Would you not have commited (or, worse, pushed) anything to it already? Most times you already have, so it's not like stashing your latest changes and getting to the latest state of the feature branch is neutral. Plus, what big benefit would stashing have, since you'll still need to create a separate bugfix branch to create the bugfix PR off anyway? If you get to context switch while you were working on my-feature-branch, you still need to create my-bugfix-branch and push the fix from that, no? Besides nobody guarantees you ahead of time that the bug will just be solved fast and they get to return to working on the feature pronto. So a bugfix branch makes more sense than a stash, which is more of a short term thing. Just making a bugfix branch is neater.

thisisthenewme 3y ago

I've started using worktrees recently and I have nothing but praise for it. It's especially useful to me because I work on multiple features and want to reduce friction from context switching. I basically have a structure like `/worktrees/<project>/<worktree>`. I use it alongside direnv and have my .envrc in the top-level project. That essentially allows me to set up project-specific environments for all of my worktrees. This works neatly with emacs projectile mode and lets me switch between different projects/features seamlessly. My head feels a lot lighter not having to worry about my git branch state, stashing changes, and all that jazz. I think it's a great tool to have in your repertoire and to use depending on your needs.

lathiat 3y ago
I do that to but for the many stable branches of OpenStack/Ceph/etc that I’m working on at once (working on the distro/backporting side often back porting patches 3-8 releases). It’s great.
CuriousCosmic 3y ago
this is what I do as well but my structure is `~/git/<project>/<worktree>` for the worktrees and a bare git repo is stored in `~/git/<project>/.git`. The workflow I do is 1. git clone https://path.to/repo.git https://path.to/repo.git 2. mv repo/.git repo.git && rm -rf ./repo && mkdir repo && mv repo.git repo/.git && cd repo 3. git config --bool core.bare true Now you can just create worktrees in the root of the git repo. This has the advantage that the `~/git/<project>` directory is still understood as root of the git repo and the worktrees are never checked out inside the working tree directory.
- vaibhavsagar 3y ago
  Why not `git clone --bare`?
  - v7engine 3y ago
    I've tried this and it seems to be working fine. git clone --bare https://path.to/repo.git https://path.to/repo.git mv repo.git .git now we can create worktrees in the same folder.

avgcorrection 3y ago

The first big thread on GitButler (recent) left me scratching my head. All the material with jargon like “virtual branches” just left me confused. It was like jumping into a how-to on why choose a Ferrari without first understanding what a car is. This clears things up nicely. I mostly use worktrees for very separate things. Like: long-running build, way old or way new versions of the app. Then it doesn’t make sense to mix-and-match virtual branches. So when I want to build the app for deployment I don’t want to worry about whatever other changes getting in the way. Git worktrees doesn’t solve the same problem as what GitButler does. Worktrees is a streamlined way of the manual separate-clone workflow for the same repository. (Technically they are all distinct repositories once you clone them but ya know.) I do have use for separate-from-branch files. Like notes to myself and test scripts that aren’t going into the branch. Crucially these files have nothing to do with the main work: the files themselves are not involved, so there can never be merge conflicts. This GitButler workflow makes sense for things that (1) won’t cause merge conflicts and (2) which won’t step on each others’ toes. The example about a translation and code change is nice. Doing a translation at the same time as a code change is not likely to “break the build”.

ratrocket 3y ago
For reference & context, I believe (I hope!) this is the "first big thread on GitButler": https://news.ycombinator.com/item?id=39356042 https://news.ycombinator.com/item?id=39356042
- avgcorrection 3y ago
  https://news.ycombinator.com/item?id=39357068 https://news.ycombinator.com/item?id=39357068 The submitter unhelpfully didn’t mention the name in the title.

zamalek 3y ago

Worktrees have been a massive savior for me when using Rider (which is all that I use them for). Previously, switching branches would cause the cache to become out-of-date; which would be fine if amending it didn't break 80% of the time (causing spurious code issues etc.). It works just fine with Sublime Merge, so long as you add the worktree as the repo - not the bare repo. I do wish there was better integration.

MissTake 3y ago
Is there now native control for Worktrees with Rider (or any of the JB Tools for that matter)? I tried Worktrees a couple of years ago but not having any integration with them with Rider led me to walk away.
- zamalek 3y ago
  I'm not sure unfortunately. I vastly prefer directory-centric SCM over project-centric.

timetraveller26 3y ago

> Then we go to our GitButler UI and we see that an anonymous virtual branch has been automatically created, because it saw new changes. We can just drag one of the files into a new virtual branch lane, then commit and push both at the same time. This is where he lost me, do I now need an UI to use git? ridiculous

scubbo 3y ago
> do I now need an UI to use git You and I don't - but, judging by what I've seen from coworkers, we are in the minority.

uses 3y ago

Worktrees are pretty great but I don't understand why I can't have the same branch checked out on two worktrees? I get why committing to a branch checked out elsewhere might be bad, but in that case, just prevent me from committing, like "you can't commit because the branch is checked out elsewhere - maybe create a new branch".

renewiltord 3y ago
In general, `git` seems to fight changing checked out code. You can't push refs to a repo on a checked out branch, for example.
CuriousCosmic 3y ago
You can absolutely check it out in multiple places. You get a warning because the behavior is unintuitive. If you want to force it to do it anyways you just use -f/--force. When you check out a branch, the expectation is that the working tree is in sync with the current head commit. If you check out the same branch in multiple places, then if you commit on worktree a, worktree b won't say that it's still on the old commit, it'll just say that the diff between the current head and the contents of worktree b's working directory are a bunch of uncommitted changes. That's why it's unintuitive. This is clearly not the intended behavior for most users when they want to check out the same branch in multiple places. They want to check out a given commit that happens to be the head of the current branch in multiple places. To do that you use --detach so that the worktree head points to the commit rather than the branch itself.

rvdginste 3y ago

For a lot of projects, I have 2 worktrees, where one is for my own work on the project, and the other one is for reviewing other people's code. That means that I can easily do a review (I like having the code open in my IDE during a review), without having to stash my own work.

cycomanic 3y ago

I didn't know about worktrees, sounds a lot like bazaar used to do branches which I always considered much more convenient than gits way. I think I start using it straight away. Cheers Jochen

v7engine 3y ago

I've recently read about worktrees and currently trying to incorporate it in my work routine. For NodeJS applications, it seems we need to create a soft link to point to the node_modules folder in "main" worktree in all worktrees. Otherwise we need to do a npm install in each of the worktree, and knowing how big the node_modules folder can be, a lot of disk space and time is wasted.