How I Use Git Worktrees
matklad.github.io
There are a bunch of posts on the internet about using git worktree command. As far as I can tell, most of them are primarily about using worktrees as a replacement of, or a supplement to git branches. Instead of switching branches, you just change directories. This is also how I originally had used worktrees, but that didn't stick, and I abandoned them. But recently worktrees grew on me, though my new use-case is unlike branching.
  • nous@programming.devEnglish
    4·
    4 months ago

    I have started using work trees recently as well, but have a different flow to the author and everyone else. I typically use two work trees, one on main that I do all my work on. That is work and create commits directly on the main branch.

    But then to push I have another clean work tree that I use to create and switch branches on then use that to create working sets of changes by cherry-picking from master into different branches to push and create PRS from. And never edit files on this work tree so that I never have to stash anything.

    Then just git pull --rebase=interactive origin/master to remove merged commits from master as they get merged upstream. This let’s me build on pending PRs or switch to other tasks at will and just sort them into separate PRs as required.

    I like this as when working on a feature I often find a refactoring I need to do, so can isolate that refactoring and create a PR with only that change while continuing to work on the feature on top of the PR.

    Or have some temp debugging stuff locally that I want to use across changes that will end up in different PRs without having to copy paste them between branches.

  • sgt_hulka@lemmy.sdf.org
    3·
    4 months ago

    I guess I don’t understand this feature. Is there an advantage in using worktrees rather than multiple clones? Is it mainly for IDE integration?

    • lobut@lemmy.ca
      6·
      4 months ago

      I use worktrees and I wondered the same question, so far here’s what I like:

      git worktrees list can show all the worktrees, you have for this same repo (not crazy value, I know)

      git fetch applies to all your worktrees

      git stash / apply can work across worktrees, so I can stash in one and apply it to another

      You’re limited to a specific branch per worktree and many don’t like that but I typically work from a detached HEAD anyways.

      • nous@programming.devEnglish
        3·
        4 months ago

        And cherry-pick commits done on different work trees without syncing them first. Or rebase or mergeworkk done on one work tree with others. Or check commit logs or diff them.

    • zygo_histo_morpheus@programming.dev
      4·
      4 months ago

      The different worktrees share the same .git state. The article has an example where the author uses one tree for writing code and one for fuzzing it. If they used multiple clones they’d have to push from the writing directory and pull from the fuzzing directory to get new commits to fuzz but with worktrees this state synchronization between different git directories happens automatically.

    • magic_lobster_party@kbin.run
      21·
      4 months ago

      multiple clones

      Why would you do this to yourself?

      The benefit is that you have everything collected in one place. You can jump between any of your local branches, and there’s no confusion about which state the branches are in.

      If you have multiple clones, then there’s the risk that you’ve forgotten to sync main in all your different clones.

      Then there’s also the problem that all the generated binaries will be out of sync. You still have 5 copies of each binary.

  • count_dongulus@lemmy.world
    2·
    4 months ago

    I commit and squash before pushing the branch if I have to change what I’m working on. Keeps the changes on remote so I don’t lose progress. Not like a PR is open if the work I isn’t ready anyway.

  • Kissaki@programming.devEnglish
    2·
    4 months ago

    They wrote they’re using . as placeholder commit messages.

    I use f for such [f]ollowup/[f]ixup commits, and a for [a]dditional code/components/changesets. Both keys are trivial to enter. When cleaning it up after, f commits are typically squashed into previous ones, and a commits get a description and/or serve as a base for squashing.

    I can see . working well as well, but having a more obvious character (with vertical height/substance) seems preferable.