Git Worktrees Tutorial #3 - Bare Repositories

Key Takeaways

Okay then gang in the last lesson we saw how to add a new git work tree to a repo which we cloned on our computer and when we initially cloned that repo git cloned the repository itself the dotgit folder and it also created a default work tree checked out at the latest commit on the main branch from there we then added a second work tree to work on a different feature while we had uncommitted changes in the default work tree however when I'm using work trees a lot in a project I like to work slightly differently and manage my work trees in in a more organized way. And I do that by first of all cloning what's known as a bear repository. So in this lesson we're going to be talking about what a bear repository is and we'll clone a bear repo to our computer as well. Then in the next lesson I'll walk you through the workflow I like to use when I'm working with work trees alongside that bear repository. So then first of all what is a bear repository? Well, like we've already seen when we clone a repo from GitHub to our computer, Git brings down two things, right? The repo itself, which is the git folder and everything inside it, like the branches, the commit history, refs, hooks, etc., and the default work tree, which is the project code checked out at the latest commit normally on the main branch. So, this would represent a standard clone of a repository. Now, when we clone a bare repository, git doesn't create the default work tree and only brings down the contents of the docket folder. And this would now be a bare repo containing no work trees and only the repository data itself. So it still contains all the information like the branches, the history, the refs, all that kind of stuff. But we have no working directory for the project code or no work tree. So the reason I like to use a bear repo when I'm using work trees and I know I'm going to be using them from the start is that it stops me from using the default work tree as a bit of a junk draw. Also, it allows me to organize my work trees in what I think is a much cleaner way by having them sit alongside the docket folder inside a parent folder for the entire project. Whereas in the previous example, when we added a new work tree, we kind of came out of the parent folder, then added it alongside that parent. And to me, that doesn't feel very organized. So, anyway, that's what a bear repo is. Now, let's try cloning one. So, I'm on the same GitHub repo as before, and we're going to clone it in almost the same way as we did before. So, let me grab the repo web URL from down here first. And now in the terminal, I'm currently in the same project directory as before. And if I run the ls command first, you're going to see I already removed the previous clone from the last lesson. So, there's actually nothing in here at the moment. Now, if we were to clone a bear repo directly in here, then it's going to bring down the entire contents of what you normally find inside the do.git folder and it's going to dump all that directly inside this project folder. Now, I don't want to do that. I want to put it inside a specific project folder and then inside agit folder within that. So let me first of all make a new project directory called I don't know portfolio by typing mkdir to make a new directory then portfolio and then I'm going to cd into the portfolio folder. So this is where I want to create the bear repo inside this portfolio directory. And to do that I'm going to type get clone. Then I'm going to paste in the URL and then at the end I'm going to add on the bear flag. So say we only want to clone the bear repo and not create a default work tree. At the end of this I'm going to add a destination path for the bear repo as well which is going to be inside agit folder. Again if I skipped this path part then git is just going to bring down all the repo contents that you normally find inside a dotgit folder and it's going to dump them directly into this project folder. And you might be fine with that. Some other developers work like that. But I put everything inside a dotgit folder just to keep the parent project folder a little bit cleaner. So now I'm going to hit enter to clone it. Okay. So once that's done, I'm going to run the ls command with the a flag to show hidden folders. And we should see that git folder, which we do. Also notice we don't have anything else. Git didn't create a default work tree like before. And there's no project code to speak of yet. I can demo that by trying to run the git status command. And when I do, we should get an error saying that we have to run this command within a work tree, which we don't have yet. Anyway, if we cd into that.git folder, we can then run the ls command again to list the contents of it. And we should see all the same repository data as normal, including all the branch information, history, refs, whatnot. Okay, so let me cd out of this.git folder now back into the project folder. Right. Then, so we've got a bear repo now without any work trees. And we can't work on the code without a work tree.