Grab the git cheatsheet once it's released here: philomatics.com/git-cheatsheet (Might still take a bit though, of course I underestimated how much work it would be lol)
@Thorou
Ай бұрын
my workflow has come to include many temporary commits that get rearranged/squashed/renamed before pushing, so whenever i need to switch branches i just commit everything and undo it when i come back. this has the added benefit of being virtually unable to lose those changes due to reflog.
@streettrialsandstuff
Ай бұрын
Fucking KZitem deleted my fucking comment. No idea why. Anyway, I said that I agree with you.
@TheThirdWorldCitizen
Ай бұрын
Been doing this recently and it’s honestly fine because can also squash a follow-up commit.
@mattstyles4283
Ай бұрын
This is how I work too
@philomatics
Ай бұрын
Yeah I really like doing that too. You need to be comfortable with interactive rebases to do that, but if you are, it's a good workflow as well.
@user-qu7qh7qj2t
Ай бұрын
Yup, I always just commit everything with the message “wip” for work in progress before switching branches.
@ChrysusTV
Ай бұрын
This all stems from commit aversion and people treating commits as production-ready items. If you push your commits and that starts some CI or release process, then sure you'd want to avoid that. Committing locally to a feature branch should never do that in any sane workflow, so there's no reason to avoid a local commit. You can always fixup, squash, amend, etc. before you're ready to push your polished code to the remote. For some reason people conflate "commit" with "irreversible code changes that are production-ready" when all a commit means is "this is the current state of the tracked code." All these weird workflows can be avoided by just getting rid of unreasonable, commit-averse mentalities. What you've done here is basically commit code mentally ("these are the changes I've made and I'd like them to remain in this state," which is literally a commit) and developed a workflow to avoid using the one feature that all of Git relies on.
@rmdashrfv
Ай бұрын
This is so fucking true. We also need to understand that it's fine to have not-yet-finished code in your codebase. I've always taught commits to serve as a checkpoint, nothing more nothing less. I personally think that the release process should be almost entirely separate from the push, and people have made me feel insane for years
@philomatics
Ай бұрын
I agree with you. Committing and then potentially rebasing later is totally fine, especially if you are comfortable with interactive rebase.
@mudi2000a
Ай бұрын
I commit always on a branch while working on it but it is also just necessary so that the CI/CD can actually build it so I can deploy and test.
@cdoubleplusgood
Ай бұрын
No, having multiple worktrees has not necessarily something to do with "commit aversion". If you are working on multiple features, fixes etc. in parallel and the build times are slow: That is the use case.
@ChrysusTV
Ай бұрын
@@cdoubleplusgood Sure, if you willfully ignore the premise of the video presented in the first 12 seconds: " *You're not quite ready to commit* your work yet, so you stash your changes." Commit aversion. Maybe you watched a different video, but I am responding to the premise *actually* presented in this video, not your opinion of a viable workflow.
@Jabberwockybird
Ай бұрын
Grug sense complexity spirit demon. Grug say, "no thanks"
@philomatics
Ай бұрын
I agree with Grug. Good grug sense here. Complexity of worktree only worth in specific situations. Grug sorry for clickbait, but bring views. Grug hope other grug still learn something so no reach for club! If not, grug sorry for waste time!
@sorskilla
Ай бұрын
Grog think same thing
@JonnyRobbie
Ай бұрын
@@philomatics You also mentioned that worktree allows you not to have multiple cloned repos. But at the end of the day, that's just semantics. A worktree is just another full version of the tree in your filesystem. Cloning or not, one is managed on a fs level, one on a git level, but tomato tomato.
@baky5372
Ай бұрын
Other Grug agree
@BoonBoonitube
Ай бұрын
Another agree
@kebien6020
Ай бұрын
Also, instead of git stash; git pull; git stash pop. There's git pull --autostash. It even works with --rebase
@SleepyHarryZzz
Ай бұрын
I forgot this was even an option, it's one of the first things I configure on new machines to have autostash by default.
@kenwarner
23 күн бұрын
and, you can use config to do this automatically. I use these options git config --global pull.rebase true git config --global pull.autoStash true git config --global rebase.autoStash true
@ScottHess
Ай бұрын
It doesn't really replace git-stash, it's just another layer of things that get out of control if you don't put in the time to prune frequently. For me the big advantage of worktrees is that it's more like being off on a branch, so if you try to update to a more frequent base, and it goes awry, you can more easily back out and retry. For that reason I mostly use it for development which has gotten kind of distant, like trunk vs production branches, or a particularly gnarly set of changes which are going to have to be heavily revised before landing.
@AlFasGD
Ай бұрын
I prefer creating a dump commit and just amending it, stashes are basically "special" branches so what makes them so special to use
@philomatics
Ай бұрын
Yeah that works well too!
@dudeabideth4428
Ай бұрын
Exactly my view and workflow . Stash also has no branch knowledge, so no point to use them .
@CallumAtwal
26 күн бұрын
Yep in this case I would do a WIP commit
@mskzzz
22 күн бұрын
This is the way
@Fakheet
20 күн бұрын
Idk about that, when I make a stash in Git Fork it is displayed in the tree view as the latest item of the branch it was made on @@dudeabideth4428
@bernhardkrickl5197
Ай бұрын
I used git worktree for quite a while. I had separate worktrees for some release branches and for a special build for a particular customer. That was exactly to avoid long rebuild times when switching between those. But I stopped doing that for two reasons. I just need to switch to an older release version much less frequently than I used to because we roll out new versions much faster these days. And the rebuild time with faster hardware and newer IDE versions is much shorter. There are also some drawbacks of git worktree. If your repo is big you may run out of disk space if you always keep many worktrees, or maybe just backups or virus scanning or similar stuff may take longer. Also, keeping track of your worktrees can be a bit confusing. Maybe git has gotten better at worktree maintenance, but when I removed worktrees I always had to make sure that I removed both the directory where the worktree was checked out and also tell git that the worktree is now gone. Even if that works better now, you still have to mentally keep track of the worktrees you have, what you use them for and in what state they are in. If you are like me, that can be a mental burden.
@SourceOfViews
Ай бұрын
It's better in so far that you can list and delete worktrees pretty easily via the cli. I still sometimes find a random folder in my projects folder and wonder what it is, just to realise it's a worktree of a different one ^^ I guess that could be helped, by having a shared parent folder for all work trees.
@philomatics
Ай бұрын
Agreed, it's definitely a trade off!
@yochem9294
Ай бұрын
@@SourceOfViewsyeah I don't get why you can have worktrees inside of worktrees. Do people use that? It only makes sense for me to have one parent directory contain all worktrees. Or _maybe_ categorize the branches in folders
@SourceOfViews
Ай бұрын
@@yochem9294 worktrees in worktrees? Does that work? I meant that usually, you just git clone and then get one folder with the repository in there (aka the default worktree). Then if you just quickly want a new worktree, you'd have to make that in a completely new folder. I guess if you use it heavily you could do something like mkdir myrepo git clone /myrepo main
@Metruzanca
Ай бұрын
@@SourceOfViews What you can do is clone your repo as a bare repo (git clone --bare), then you can create worktrees inside the repo without issue.
@SteinGauslaaStrindhaug
24 күн бұрын
Sounds more like a faster alternative to making another clone of the repo to work on two branches in parallel, than a replacement for stash. I don't do that too often, but when I do I'll try to remember this.
@philomatics
23 күн бұрын
That's right! Difference is mainly disk space usage, and with worktrees you have a lot less fetch/pull/push ceremony.
@StickmanCorp
12 күн бұрын
Agreed. I'm definitely gonna try using worktrees, but not as a replacement for clones instead of a replacement for stash/temp-commit.
@uss-hephaestus
Ай бұрын
Another great example of why everyone should work the way they personally feel most productive, creative, and do their best quality work.
@nicocarne
Ай бұрын
You can also commit the partial changes and then ammend when ready
@pharmajoe990
7 күн бұрын
This is the way. No need to add yet another layer of complexity.
@soham8555
Ай бұрын
Everyday I learn something new about git.
@samarnagar9699
Ай бұрын
Same goes with neovim and gnu std lib
@BorisBrodski
Ай бұрын
Worktree CONS: - unsupported by some tools, e.g Eclipse,.. - easy to accidental remove local branch used in other worktree
@Metruzanca
Ай бұрын
Vscode doesn't support them either, that's why in the video he opens the worktree in a new vscode instance. You can do the same with eclipse/vs-ide/intellij, just open the new worktree as a "project". Second con, is not a problem specific to worktree, its a git skill issue.
@seungjoolee1012
Ай бұрын
@@Metruzanca But unlike VSCode, Eclipse(or STS for that matter) should import the project . Furthermore the project name should be changed to avoid duplicate error. Not difficult but a bit more bothersome.
Bro came on my feed out of nowhere and started cooking
@CrimeGaming1337
27 күн бұрын
Note that you can use: git switch -C , to switch to a branch and create it beforehand
@philomatics
27 күн бұрын
Good suggestion! I wanted to separate the commands here as to not confuse beginners, but yeah, I usually do `git checkout -b branchname`.
@rickloyd8208
26 күн бұрын
Oh my goodness, this is so helpful! Thank you so much! I had to wait for over 10 minutes when I was switching between branches, and I even thought about cloning the git to keep each in its own branch, but that would waste space.
@BrunoBernard-kn6vt
Ай бұрын
Another thing, git clone --bare can create a wrapper for the worktree feature branches. Example mobile-app/ folder can have all the worktree inside.
@natescode
Ай бұрын
Worktree is great! If you set it up correctly, you can use it with workspaces in most programming languages. This means you don't have to rebuild when switching work trees.
@RushOrbit
26 күн бұрын
15 seconds in and I already can't relate. I'd just commit rather than stash. What are you crazy? What if the computer fries and I lose all that work I've been doing? Just commit and push, that's what it's for. If your workflow is setup like any other normal project, nothing should be deployed to prod until a PR is merged. Stashing to me is something I do for something super short term. Like, I need to stash so I can drop the changes on another branch, or pull, or do some other modification where the code needs to be placed in some short term storage. Anything that'll take more than 1 minute, just commit.
@AmitB
20 күн бұрын
This is fine if you don't care about running CI needlessly (you probably should care), or your pull requests are squash merged (otherwise you'd have a ton of "WIP" commits in your Git history)
@sabyasachighosh6252
20 күн бұрын
The #1 purpose of a remote repository is source code backup. If your workflow is hindering you from backing up your code to a remote repo, your setup is not correct. Perhaps CI should be enabled on only a few branches and not all branches in your workflow. Regarding WIP commits, it is what it is. One can create a new branch and squash commits into meaningful ones if needed, before merging to the main branch. That is better than the alternative, which is crashing your laptop and losing hours or days worth of work.
@xdeama
18 күн бұрын
If your repo is your glorified backup, fine. If your repo is a collaboration tool, worktree is awesome.
@KazzyJr
24 күн бұрын
I personally use shelve as a more convenient way of storage
@Mat2095
Ай бұрын
I don't get the argument about compilation-time. It's a complete additional instance, so you have to download all dependencies again and compile the whole project again. But with a stash, in most cases only a few files should change, so only a small part of the project has to be re-compiled.
@philomatics
Ай бұрын
That's a good point. I guess it depends on how much you're stashing and especially how different the state of the other branch you're switching to is. So in some cases stashing might make more sense.
@Mat2095
Ай бұрын
@@philomatics Yes, and probably also on the language/framework. I'm working on a project with an Angular frontend, switching branches or stashing is super fast. No need to restart the dev-server, it just hot-reloads within a few seconds. But if the backend changes, I have to recompile and (which takes longer) restart the server. And if the database schema changes ... then I hope somebody else does that task so I don't need to switch xD
@rafalg87
29 күн бұрын
Thanks for this comment, I had the same thoughts and I was wondering if I was missing something. Another issue would be if it's a web project using a server configured to serve specific directories - the newly created work tree wouldn't be used by it. So overall, it seems like use cases are fairly limited here.
@SourceOfViews
Ай бұрын
Worktrees are nice and I've been using them a bit. It can be quite useful, but it's a very different feature than stashing. In your example, yes worktrees are fine. Personally I'd probably just make a quick temporary commit and then checkout whatever I want to have. But if building takes a long time or I'm currently executing some longer running tests, I would probably use worktrees. The temporary commit also has the benefit of you being able to push it and also making it much harder to loose as opposed to worktrees. Stashes I mostly use when - I quickly want to move the changes e.g. while rebasing or even sometimes when I was accidentally on the wrong branch - I want to quickly undo all the changes that I made to test in a before-after manner.
@philomatics
Ай бұрын
Thanks for sharing! Temporary commits work well too in my experience!
@NicolaiWeitkemper
18 күн бұрын
I didn't know worktrees could reside outside the main repo! That's so much better than how I used to do it!
@syang1115
Ай бұрын
Well explained, thx. I've done that with separate folders without knowing worktree feature until now.
@Sergio_Loureiro
Ай бұрын
Git can always find ways to make things unnecessarily complex. There are two functions TFS had, that either I didn't discover how to do it in Git, or Git does not have them: Suspend Work and Shelve. Git Stash is not the same thing, because it only stores changes on the local machine.
@OhhCrapGuy
25 күн бұрын
The closest equivalent to shelvesets in git is committing to a temporary feature branch and pushing to the shared repo so the other person can look at it, make further changes, etc. I say "the closest equivalent", because git doesn't have all the fundamental flaws that are built into all linear history VCSs that necessitated things like shelvesets, checking out code, and locking files in the first place.
@1vader
Ай бұрын
I just create a wip commit. Powerline 10k even shows a wip indicator in the shell prompt git status if the last commit has "wip" in the name so I'll immediately be reminded that I still need to clean that commit up.
@philomatics
Ай бұрын
Yeah I think this is a really good approach too.
@natescode
Ай бұрын
Works fine but sometimes I don't want to rebuild and reinstall dependencies
@authorspirit
4 күн бұрын
Thanks for this. Its frustrating to shift to multiple branches during code review and stashing. This reduce most my time.
@matthiasbendewald1803
Ай бұрын
I almost didn't watch that video because I never stash, always just commit and rebase all stuff interactively later (or amend to that commit, whatever). The worktree feature is really nice, I knew that it exists but never used it somehow, thank you!
@philomatics
Ай бұрын
Thank you! I think your workflow is also totally fine though!
@m4rt_
Ай бұрын
personally, I structure my bare git repos (for git worktrees) like this, a folder named "source" in the root of the folder structure for the repo, then branches like "main" and "preprod" under the "source" branch. then I also have a folder "feature" (among others) under the "source" branch, then I keep feature branches in there. So if I have a branch "feature/implement-important-thing" I would place it here: "source/feature/implement-important-thing" (git worktree add -b 'feature/implement-important-thing' source/feature/implement-important-thing main)
@philomatics
Ай бұрын
Thanks for sharing!
@qfrank76
20 күн бұрын
thanks for sharing this command! seems like if you use this often enough, it would be easier to just have a second cloned repo. if you don't use this often, it might be easier to just do a commit. If you want to change the commit, you could do a soft reset after coming back to the branch the second repo has the added benefit of retaining your untracked gitignored local configs and settings
@philomatics
20 күн бұрын
Right, it's definitely situational. There are some advantages over a full clone though, mainly disk space usage and also a bit less fetch/pull/push ceremony.
@jeromesnail
13 күн бұрын
I can see the value of this when you need to test a feature branch that's waiting for some webhook but still need to work on your own feature branch in the meantime. Happend to me a shit load of times actually.
@julien.roques
Ай бұрын
Just "git clone" your project to this new folder, and voilà!
@philomatics
28 күн бұрын
Sure, that works too! Only difference is disk space usage and more fetch/pull/push ceremony than with worktrees. But if that doesn't bother you, totally works too.
@maxcross5454
Ай бұрын
This exact scenario is 80% of my personal motivation to just use jj (jujutsu vcs) as a cli for git repos. It treats working copy as a commit (aka revision) that you are currently editing. So if I'm working on a feature, and I suddenly need to work on a different feature, I just switch to that feature's revision, work there, and switch back when I'm done. I don't even have to think about stashing something, remembering to pop it later, or manually managing worktrees. I can still use worktrees (jj calls them workspaces) if I need to leave build running in the background while working on different features, or to just avoid rebuilds as mentioned in this videos, but in my case - I never had to. And the rest of jj's features (commit editing with automatic rebasing, ability to just leave conflicts in the working directory to resolve them later, operation log, etc) so far is just a nice bonus.
@philomatics
Ай бұрын
Cool, gotta check that out, thanks for commenting!
@stevecarter8810
Ай бұрын
Git is really powerful, I predict that someday someone will build a source control tool on top of it
@69k_gold
Ай бұрын
Nice roast
@4ngelf
4 сағат бұрын
Never used git stash. I just make a local branch ([ featureBranchName ]-local), then git merge everything to the feature branch. The local version filled with countless micro commits. Worktrees seem better tough.
@mactan_sc
Ай бұрын
i can barely convince people to use more the same two branches forever, never got anything more complicated to catch on
@SandraWantsCoke
Ай бұрын
I just commit and switch branch with a dummy message and then I switch back and reset the commit and I'm back where I was.
@holycrimpsauce
Ай бұрын
If I find myself reviewing a lot of pull requests locally for a specific repository, I might create two separate copies of the project - one for making coding changes and another for reviewing PRs. I'll create an alias for the PR repository so I can easily distinguish between the project folders. It's similar to using "git worktree", but it's a one-time manual setup. If I need a more dynamic setup where worktrees are created and removed frequently, then using a tool for managing worktrees makes sense.
@ColinRichardson
Ай бұрын
1:04 my co-worker just clones the repo into another folder... I will just stick to stashing..
@philomatics
Ай бұрын
Yeah that works too, just more disk space and regular fetching/pulling work, but no biggie.
@BlueCardinal33
Ай бұрын
@@philomatics You should have mentioned in the video the worktrees should be used as workspaces, in the sense that, you shouldnt do 1 worktree "per branch", but 1 worktree per simultaneous tasks you can handle at once. This workflow framing makes way more sense. Great introductory video to worktrees anyway.
@ColinRichardson
Ай бұрын
@@philomatics Disk-space, yes.. "regular fetching" prob not. I assume he has folder he does most of his work in, and only goes to the secondary folder when he needs to the quick fix.. And I would always do a fresh fetch if I was asked to do a quick fix, (I will hope/assume he does the same).. So prob the same amount of fetching. Though, the fetch will likely be bigger in size depending on how often he does quick fixes. Though, he hasn't needed my help with any git related stuff in multiple years now, so I assume whatever his process is, is working for him.
@philomatics
Ай бұрын
@@BlueCardinal33 Good point! Should have mentioned that.
@DeronMeranda
Ай бұрын
Worktrees are better than separate clones, since you're really working in just ONE git repo. Besides being more efficient, you can reference commits made in one worktree (say for a cherry-pick) in another worktree without any push/pull! And I use both worktrees AND stashes: you can reference your same stashes across all your worktrees. I sometimes do this when I start a change in one worktree/branch and quickly decide it should be in another instead but I don't want to create a commit - I'll stash save in worktree 1 and stash pop in worktree 2. This is nice especially when you have long-lived worktrees checkout out anyway.
@jammin023
27 күн бұрын
Been using git for years but this is new to me - thanks! Been doing something similar using 'cp -a' but this has some worthwhile extra safety features.
@NuclearFury8
Ай бұрын
I really liked using worktrees, they're useful when you have very long-running things you keep having to switch between. They do have one major downside - they don't work well with submodules. It's even still in the documentation that the support is incomplete, but it was even worse when I needed it. Also, I feel that when your repository is huge it's sometimes nicer to just stash and switch in-place for the hotfix scenario you mentioned.
@philomatics
Ай бұрын
Agreed, it is a situational command for sure.
@Kreubs
27 күн бұрын
worktrees sounded great until I remembered my main project depends on node
@randhir2588
Ай бұрын
Thanks for considering my suggestion. good explanation.
@philomatics
Ай бұрын
Thanks again for the suggestion!
@RazoBeckett.
Ай бұрын
This channel is underrated!
@recessiv3
6 күн бұрын
Something you failed to mention is that it doesn't duplicate ignored files (obviously). In any normal environment files in the .gitignore are vital for execution and so a worktree will either require manual duplication of ignored files or it simply won't work. Sometimes these files are enormous, so in cases such as this worktrees aren't particularly viable
@philomatics
Күн бұрын
Good point, should've mentioned that!
@HaiderAli-oi5fm
Ай бұрын
Great video. Clear explanation! Can you also make video on these. Why these issues happens? 1. You have divergent branches and need to specify how to reconcile them 2. There isn't anything to compare. main and your branch are entirely different commit histories.
@philomatics
28 күн бұрын
Thank you for the suggestions and the nice comment! Just to clarify: 1. Do you mean merge conflicts? If so, I already have a video on that here: kzitem.info/news/bejne/paKluGR4iHl_iGU 2. Gotcha. Can you tell me about a specific situation where that happened to you? Would help me understand the use case a bit better. What were you trying to do, what was your goal?
@HaiderAli-oi5fm
28 күн бұрын
@@philomatics I made a branch fix/bugs from dev branch. 1. I committed to fix/bugs but before pushing to fix/bugs, I took pull from dev branch in case if some one merged the PR on dev. But strangely, I got divergent branches error. I went with fast forward option but fast forward option did not work. With git config pull.rebase false, it said that fix/bugs is Already up to date. 2. Now I created a PR in base:dev
@philomatics
27 күн бұрын
@@HaiderAli-oi5fm Thanks for clarifying! For 1.: How exactly did you pull? Here's what I would do: git checkout -b fix/bugs # fix the bug, commit git checkout dev git pull origin dev git checkout fix/bugs git merge dev Does this match your workflow? If you'd like additional help, you can send me a screenshot of your commit history graph via email (in my YT about page).
@HaiderAli-oi5fm
23 күн бұрын
@@philomatics Sorry i caught up in work. Yeah that solved my problem.
@philomatics
20 күн бұрын
@@HaiderAli-oi5fm No worries, glad to hear it worked!
@JUMPINGxxJEFF
Ай бұрын
I'm glad you've made me discover that
@69k_gold
Ай бұрын
I just maintain separate workspaces even if it's the same repo, what I get as a benefit here is, now I can put other files and folders, that the repo's code is dependent on, in this isolated workspace
@ladyravendale1
Ай бұрын
Interesting, but I probably won’t be using it. My current use of git stash is for when we are doing a major project rework and I have uncommitted changes. I don’t want to commit them to the main branch since that’s about to have a massive overhaul, so instead I stash them which as looks to be about the same thing as creating then committing to a dead branch, except quicker. For actually doing this sort of workflow for switching between branches, I don’t know why anyone didn’t tell me earlier but squashing commits is super easy as long as they aren’t pushed to remote, just a git revert -soft HEAD~n. This also makes rebasing super easy, since it’s all just one commit instead of having to deal with merge conflicts across multiple, which I don’t fully understand how to do yet. With rebasing just one commit, it acts the same as a merge conflict resolution, which I can do.
@kaushalkumar6666
27 күн бұрын
learning something new in git after long time
@nathanoy_
Ай бұрын
Very informative. Looking forward to the cheat cheat 🎉
@VikingSchism
Ай бұрын
My main use for stash is counteracting my bad habit of just starting work for a new feature on my current branch before I've created a new feature branch for it and then I have to move over my changes to that new branch
@mattymattffs
25 күн бұрын
0:34 should be clarified since branches don't require full clones unless they're in separate directories
@AlexanderPrussak
Ай бұрын
there's also gitless which autostashes (including more of the state than just working dir changes) automatically on branch switches
@mormatus
Ай бұрын
This worktree thing seems being mentally heavier than just cloning the repo into a neighboring folder without any "worktree" concepts and links. Frankly, don't see a single reason to memorize that stuff.
@meowsqueak
Ай бұрын
I agree - too much complexity and things can break mysteriously. Better to have independent clones. If disk space is a concern, buy a bigger disk, it’s cheaper than increased mental load in the long run.
@philomatics
Ай бұрын
Yeah, the main advantage over separate clones is that you don't need to fetch/push so often for long lived worktrees.
@mormatus
Ай бұрын
@@philomatics maybe, but for me the mental model is way simpler when there are two absolutely separate clones that are easy to control in a clear explicit way, and when you are absolutely sure there is no covert magic going on. Explicitness and simplicity over efficiency (which never was a problem for me). In dev env, will choose those every day
@cdoubleplusgood
Ай бұрын
If your repo size is 70 GB like mine your conclusion might be different.
@meowsqueak
Ай бұрын
@@cdoubleplusgoodif you clone from a local clone on Linux it hard-links to the original .git directory and takes up no more space than a work tree. Then adjust the push target to push changes upstream.
@xcoder1122
Ай бұрын
My approach is even simpler, more brute force and works with every version of Git: I always have each of my projects cloned multiple times. Disk space is cheap; 1 TB SSD costs 50 bucks (maybe 80 for a high quality SSD module) and my biggest project is around 1.2 GB when fully cloned, so even with having this one fully cloned 4 times, I require 0.0048 TB of disk space. Usually I have 4 clones named main, feature, hotfix and release and you can probably guess which branches each of them is currently set to. However, there isn't always an active feature, hotfix or release branch, so even when I'm working on feature A on the feature clone and need to quickly fix something for feature B, I can just switch hotfix or main to the branch of feature B and make the fix there, commit, push and continue to work on feature A without stashing anything. The clone names are just hints what that clone is intended for but in the end, those are just 4 copies that can each be set to any branch at any time. I could also name them 1 to 4 but most of the time they are used for their intended purpose, hence the naming does make sense.
@philomatics
28 күн бұрын
Yeah full clones totally work too. One thing I like about worktrees is that you save yourself from a lot of fetch/pull/push ceremony. But other than that, using clones is totally fine!
@cyrusol
Ай бұрын
I will continue stashing with this one. It's a huge mono repo and the entire system (even dev envs) have some hard dependencies on the path, it would be impossible for me to test changes in another folder. If the worktree feature worked like a seamless layer on top of stash and switch it would be far easier to make this work. Right now it's a doesnotworktree.
@kennedymwenda3357
Ай бұрын
Just in time when I was wondering how to isolate a new module development that may take sometime while hot-fixing the current version
@DuncanBooth
Ай бұрын
I've used both `git stash` and worktrees. Worktrees are undoubtedly more flexible but a pain to setup if you have uncommitted files in the folder (.venv, vscode config, passwords that don't get committed, etc.). Committing immediately and cleaning up the branch at the end is my preferred method but that won't always work if the precommit hooks say you haven't done everything you need to do (linting, formatting, updating documentation, ...) so then it's back to stashing.
@GrzesiuG44
Ай бұрын
In addition to what people suggest about commiting with plan to amend later - in a project with scenario as described I am not enjoying idea of cleaning up commits. Just do a WIP commit and merge it - you will be able to see what was your progress with adding some bizzare bug - like implementing something one way before weekend, and continuing it wrong after. And keep merge/PR history clean instead of the full commit history. And blame git for not having concept of remote reflogs 😢
@SuprousOxide
28 күн бұрын
Then you have to load your new worktree in your IDE and do whatever setup you need to do on a project by project basis in that IDE. Worktrees could be useful in some cases, but I don't feel like temporary branch hopping is the case. Rather than stash, I'd say just commit with a comment to make it clear it's a work in progress, then squash that commit away before you push to your repo.
@philomatics
28 күн бұрын
You're right about the IDE. I think I should've highlighted this in the video better that this is more for long-lived workflows and only useful in specific situations. I think your WIP commit workflow is a good one too! Thanks for your comment!
@iamunknownperiod3355
Ай бұрын
I still prefer git stash but I see the merit of this for long build times as you said. The main thing I don't like about this is that I need to open a new editor instance.
@philomatics
Ай бұрын
Yeah definitely both workflows have their merits
@Rundik
3 күн бұрын
So basicly the same as cloning a repo multiple times in different directories. There are reasons why people don't normally do that
@philomatics
Күн бұрын
Good point! It's mainly less disk space usage with work trees. Also for long lived worktrees you have less fetch/pull/push ceremony.
@IldarIskhakov
Ай бұрын
I use oh-my-zsh with git plugin. It provides two aliases: gwip and gunwip to create and reset WIP commit on the current branch
@SpaceShot
Ай бұрын
I just never felt the need to stash when i could just commit to any old branch. Its not like it is hard, and in some ways it doesnt require you to think about the whole stash stack. you just go back to the work whenever you want. rebase if you need to bring it together.
@cowstoobh
Ай бұрын
Wait, I don't see node_modules in the new worktree. So would that mean I'd have to run npm install again before I can run it? Isn't that a waste of time, the few seconds which we intended to save in the first place?
@philomatics
Ай бұрын
That's right, unfortunately. This is why I prefer to keep worktrees around for longer usually.
@SteinGauslaaStrindhaug
24 күн бұрын
That's one of the advantages of pnpm over npm.
@MrVecheater
26 күн бұрын
Stashing is still great for changes that don't belong in upstream at all. For example local configs
@leobottaro
Ай бұрын
This is awesome! I can finally delete the copy of my day job source code, which I had to do exactly this! My small SSD thanks you
@sniz-mangalore3562
28 күн бұрын
Stash is useful. You can get back even deleted stash.
@philomatics
27 күн бұрын
Yup, definitely still useful in many situations.
@efeegbevwie9467
Ай бұрын
Intellij's git shelve >>>
@geebsayshi
14 күн бұрын
I still choose stashing even committing my changes.
@PauxloE
Ай бұрын
When I used the similar git-new-workdir addon some years ago, it always got messed up as soon as I had the same branch in both working directories, so I stopped using it. It looks like the version you have actively prevents this from happening.
@vladimircontreras
Ай бұрын
This is the equivalent of "the other ways of debugging in JavaScript" that we learn while using `console.log()`.
@philomatics
28 күн бұрын
Yeah that's a good workflow too.
@SanteeRocks
22 күн бұрын
Wow awesome never knew this feature I always wanted to compare code from multiple branches
@crateer
20 күн бұрын
The only useful thing about worktrees for me is for Code-Reviews etc. and when build times would explode. Else I still stash stuff, especially when trying out things which can get messy. Or I simply do a WIP commit.
@josb
Ай бұрын
Nice, didn't know about this feature, but i would rather commit locally without pushing, then later append to this commit
@dasten123
Ай бұрын
okay, but wouldn't cloning the repo in a different directory accomplish the same?
@philomatics
Ай бұрын
Not quite, since it's a separate repo, you'll have more disk space usage, also when you fetch/pull, of course only one of the repos will get updated, which can get annoying after a while.
@dasten123
Ай бұрын
@@philomatics yes that makes sense! Thanks!
@calimio6
26 күн бұрын
Make a commit and amend further changes
@statuschannel8572
Ай бұрын
finally my brain get the concept of worktrees. already came across some videos about it but this is my "Eureka" moment lol. thanks for the video
@UnnDunn
Ай бұрын
The problem with worktrees is they don’t duplicate untracked files from the original working copy (things like environment-specific files that should not be added to source control. Worktrees are great for long-running feature development, but not short-term work.
@philomatics
Ай бұрын
Agreed, that's probably something I should've mentioned.
@Metruzanca
Ай бұрын
To amend this issue, I use direnv instead of creating .env (/equivalent) files. Then I create a .envrc file that lives in the parent of my worktree.
@ymi_yugy3133
Ай бұрын
I don't know.... Nnless I have a global build cache, creating a new worktree means building everything from scratch. That doesn't sound good. A scenario where is does make sense, is if you have significantly divergent branches, e.g. LTS branch, current branch, next-release branch. I try to avoid them for small changes, because it can be quite painful to wait for the IDE, to reindex all files and I can't really have more than 2 instances open anyways because I'll run out of memory.
@philomatics
Ай бұрын
That's a good point. I guess it depends on how much you're stashing and especially how different the state of the other branch you're switching to is. So in some cases stashing might make more sense.
@frubert123
Ай бұрын
I didn't understand this "benefit" either. The video suggests there is a benefit of not having to wait for a compile (for example). But I thought the same as you - if the new worktree is bare, you are stuck with the build requirement. If the "worktree" command copied your current directory, then updated the new GIT metadata and switched to a different branch, you could (possibly) do an incremental build in the new tree. Otherwise stash and checkout wins, because you do keep all your compiler outputs and can build incrementally.
@danielbodon14
Ай бұрын
please keep doing these vids. as a software engineer student i find these very helpful))
@aCat11
Ай бұрын
How did you get the "Open in Terminal" and "Open in VSCode" buttons in the Finder toolbar? The icons as well.
@simonthecube2814
Ай бұрын
Same question
@philomatics
Ай бұрын
Actually I found the thing that I use again: Check out this repo (I use the lite version): github.com/Ji4n1ng/OpenInTerminal
@LocherYT
Ай бұрын
I dont quite understand because on paper it sounds like you are temporarily copying the entire git repository in some folder besides your main folder, which means during your work on the hotfix you got to manage two separate branches that exist simultaneously on your computer's hard drive. In a real world scenario, you have to mind two separate work procedures with the underlying question "how big is actually the repo i am working on", and based on that decision you follow the appropriate procedure that requires a different subset of commands (stash-pop clipboarding vs worktree management and cleanup). Nevertheless, i thank you dearly for bringing the feature of worktrees to my attention, I'll probably use that and see for myself how it can improve my workflow. You can disregard my nitpicks as I am a nitpicky person.
@philomatics
Ай бұрын
Yeah, worktrees do bring quite a bit of complexity with them. Only use them if they work for you. No worries about nitpicking, I totally get it :)
@leonwang3072
Ай бұрын
stash still feels more convenient.
@philomatics
28 күн бұрын
Yeah I definitely think the complexity of worktrees is only worth it in some situations.
@user-iu1xg6jv6e
Ай бұрын
What is the difference between worktrees and cloning multiple times (for most used branches)?
@philomatics
Ай бұрын
Since it's a separate repo, you'll have more disk space usage, also when you fetch/pull, of course only one of the repos will get updated, which can get annoying after a while.
@andreasaba4566
Ай бұрын
I usually do a tmp commit in branch A with all the last changes, then switch branch to B, do other stuff and then, when I'll come back to A, i just git reset ~HEAD that brings me at the start of this story
@philomatics
Ай бұрын
Yeah this is a good workflow too.
@wesley_silva504
Ай бұрын
People are too heated even on chill topics like VCS. You can have a strong opinion against worktrees or anything else in your life. What you can't or at least shouldn't do is forget that you might be wrong, opinions aren't necessarily equal to facts, and different people may deal with the same stuff differently but this doesn't mean one of them is wrong
@philomatics
Ай бұрын
I agree with you - at the end of the day it's always just trade offs.
@wilmanlopez1742
27 күн бұрын
Any info on how to add the terminal and vscode icons on the finder window?
@Igrium
Ай бұрын
Meanwhile there's me, who uses stash in instances of "wait what did I change and why is broken? Screw it, I only changed a few things i'mma stash and try again"
@philomatics
Ай бұрын
Hah I do that too!
@vamsi8669
Ай бұрын
Thanks, this is very useful as I can eleminate stashing and switching
@prakashr7011
27 күн бұрын
Worktree is not a stash alternative
@NatiiixLP
4 күн бұрын
Yeah, just commit -m 'WIP', checkout, do whatever you need, and then checkout back, undo the WIP commit, and ez pz. I would never recommend leaving any changed stashed for more than a couple seconds. That just feels like a bad practice to me. The worktree functionality is pretty cool and all, but it's frankly rather convoluted and feels extremely error-prone.
@midnightfuture
Ай бұрын
I guess open source has product managers trying to hit OKRs now, because this is a terrible misfeature. Worktrees and stash are symptoms of the obscurity of interactive rebase, and the (perceived?) cost of clone. It is much simpler to commit whatever is in-flight with a “WIP - ” message and then checkout the hotfix branch. Interactive rebase before push cleans up the history, which is the main reason why people think they need stash or worktree.
@philomatics
Ай бұрын
Fully agree, making wip commits and rebasing is what I do most of the time as well. That said, you gotta be comfy with interactive rebase for that, which unfortunately not many people are.
@re.liable
Ай бұрын
Nice. I understand worktrees now
@seancooper5007
Ай бұрын
no
@sevi-kun
Ай бұрын
Amazing. You just changed my life 😂
@PremDev1122
28 күн бұрын
I have been doing this for long ago as different workspace folders like WS1, WS2, WS3 and so on. Just switch the folder not the branch. 😅
Пікірлер: 429