Welcome to the Treehouse Community
The Treehouse Community is a meeting place for developers, designers, and programmers of all backgrounds and skill levels to get support. Collaborate here on code errors or bugs that you need feedback on, or asking for an extra set of eyes on your latest project. Join thousands of Treehouse students and alumni in the community today. (Note: Only Treehouse students can comment or ask questions, but non-students are welcome to browse our conversations.)
Looking to learn something new?
Treehouse offers a seven day free trial for new students. Get access to thousands of hours of content and a supportive community. Start your free trial today.
Git - Bare Repos, Working Directories, and Accessing Newly Created New Files
This is driving me nuts and I suspect the answer is stupidly simple. Let's say you're doing a Git Centralized Workflow with one Shared Repository hosted on a private server accessible to Person A, B, and C. The Shared Repository is a Bare Repo - there is no working directory - the working directory (actual files used) is in the regular Non-Bare Repo's on each contributor's local computers.
But what happens if Person A creates a new file, say "stylesheet.css", to add to the project. Person A commits, and pushes it to the Shared Repository. Person B and Person C can see that it was added to the project, but how do they then access and edit it if they want to, if it's hosted only on Person A's computer?
Tommy MorganTreehouse Guest Teacher
Tim Harrison - no worries! Let me see if I can help clarify.
Think about it like this - a normal git repository has two parts:
- A working directory representing the currently checked-out state of the project, and
- A log of commits to the repository that represent individual changes to the project in the order in which they were applied.
That's what it looks like on your computer when you create a normal git repository - you can browse around inside the files and folders of your project, but you can also (using
git commands) look at the history of your project, add new commits as you make changes, etc. Every change you make to your local working folder ends up represented by a commit in the repository, which is important - even if you totally deleted your working directory, you'd be able to recreate it easily by "replaying" each of the changes described by your commit.
A "bare" repository is one that doesn't bother with a working directory - it just keeps the log of commits. So if you added a new file to your local (normal) repository and committed it, you added a commit to your repository that includes information about where that file is located and what it contains. When you push that commit to your remote bare repository, all of that information is still preserved in the commit - the only thing the bare repository does differently is that it doesn't "replay" that commit locally, because it doesn't have a working directory. When your collaborators pull the latest set of commits from the bare repository, though, your latest commit will be included in that list, and their local repositories will be able to "replay" it and create the new file for them locally.
So John Treacy had the right of it :) It's just a matter of understanding what exactly gets sent back and forth when you push/pull between repositories. It's not the files themselves, it's the commits that describes changes to the repository.
This is why bare repositories are useful - because they don't bother with maintaining a working directory, they operate more efficiently - the only thing they have to worry about is storing commits.
Hope that helps.
John Treacy10,246 Points
Once person A has pushed the change to the shared repository it is no longer empty. Person B and C can pull the change and merge with it in their local repository.
John Treacy - thanks for responding. A follow-up as I'm still a little confused - pushing a change the Bare Repo adds history/logs/etc. that can be pulled, but what of the brand new file that was created by Person A? I was assuming that the Bare Repo would then get a working directory with only the new file, but that doesn't sound right either, since then it defeats the purpose of a Bare Repo for shared updates. Tommy Morgan , sorry to harrass you, but any insight?
Chris Dziewa - Thanks for the response. You might be right, but it wasn't entirely clear so I asked John a more specific question. I tried to avoid GitHub in the example as it has some file storage properties that I thought might be exclusive to its setup.
Tommy Morgan and John Treacy - Thank you guys so much. The concept you described was in my head, but I didn't want to just assume it - and it was paralyzing my progress. This was a question I couldn't phrase properly so I couldn't find it, and being a beginner in all of this programming and Git stuff, couldn't parse on my own.
Chris Dziewa, thanks again for your contribution.