this post was submitted on 08 Aug 2025
57 points (96.7% liked)

Git

3689 readers
1 users here now

Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency.

Resources

Rules

  1. Follow programming.dev rules
  2. Be excellent to each other, no hostility towards users for any reason
  3. No spam of tools/companies/advertisements. It’s OK to post your own stuff part of the time, but the primary use of the community should not be self-promotion.

Git Logo by Jason Long is licensed under the Creative Commons Attribution 3.0 Unported License.

founded 2 years ago
MODERATORS
top 8 comments
sorted by: hot top controversial new old
[–] Piatro@programming.dev 4 points 4 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 points 4 days ago (1 children)

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.dev 4 points 4 days ago* (last edited 4 days ago) (1 children)

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.dev 3 points 4 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.dev 6 points 5 days ago (1 children)

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/). 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 points 5 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.

[–] beeng@discuss.tchncs.de 2 points 5 days ago

VSCode just added support too fyi