Worktrees: Git's best kept secret (and why you should use them) | Tom Ups
www.tomups.com
Tom Ups blog
  • Piatro@programming.devEnglish
    4·
    2 days ago

    Glad it’s there for people who need it. I’ve been fine with branching and stashing for 10+ years and my working directories have never been so dirty that I needed an entirely new copy of the project to do a hotfix.

  • KissYagni@programming.dev
    3·
    2 days ago

    I never really understood the advantage of worktree over having just several clone of the repos on different folders.

    Can someone explain me ? I should have missed smth.

    • Kissaki@programming.devEnglish
      4·
      2 days ago

      Worktrees share the data stored in the .git folder. This saves storage (particularly on larger repos, and if you don’t fetch/clone only partial history), and could allow some other workflows or safeguards (backing up just one instead of multiple, centralized local state instead of spread across different workspaces). It also means it could share repo-local git settings - like remotes, local not checked-in ignores, etc. (I assume).

      • nous@programming.devEnglish
        4·
        2 days ago

        It also lets you checkout, cherry-pick, rebase or merge work on other branches without needing to sync between the local clones.

  • nous@programming.devEnglish
    6·
    3 days ago

    Worktrees are great. Although I use them is a different way. I only use them to allow me to rebase or cherry pick onto branches, which require a working tree to do, without ever leaving my main branch. Basically I use them as more powerful branches then full worktrees.

    Instead I just do all my work in the main branch/worktrees. When I have something I want to push to a pr I commit just that change to main. Then create a branch and work tree (I store them in .git/wt/<branch name>). Then cherry pick the commits onto that branch and push that creating a pr from it. Then go back to working on main again on top of the changes I have done. Once the pr gets merged I do a pull --rebase which drops the commits from main.

    This means I don’t need to switch directories ever and let’s me work on a feature, then do a refactor (or minor bug fix), commit and push the refactor in isolation while continuing to work on the feature on top of the refactor.

  • August27th@lemmy.ca
    2·
    3 days ago

    Oh my god, I’ve thinking about why git doesn’t operate this way for ages, but it already has for a decade. This is going to change my life. Thank you for posting this.