Welcome to the Treehouse Community

Want to collaborate on code errors? Have bugs you need feedback on? Looking for an extra set of eyes on your latest project? Get support with fellow developers, designers, and programmers of all backgrounds and skill levels here with the Treehouse Community! While you're at it, check out some resources Treehouse students have shared here.

Looking to learn something new?

Treehouse offers a seven day free trial for new students. Get access to thousands of hours of content and join thousands of Treehouse students and alumni in the community today.

Start your free trial

Development Tools

Posted by dcn
dcn
10,296 Points

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?

5 Answers

Tommy Morgan
STAFF
Tommy Morgan
Treehouse Guest Teacher
Tommy Morgan
Tommy Morgan
Treehouse 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:

  1. A working directory representing the currently checked-out state of the project, and
  2. 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.

Chris Dziewa
Chris Dziewa
17,781 Points
Chris Dziewa
Chris Dziewa
17,781 Points

I believe you are looking for information about pull requests. This allows you to update your local repository by gathering and reviewing any changes made to the master branch and uses the git pull command.

John Treacy
John Treacy
10,246 Points
John Treacy
John Treacy
10,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.

dcn
dcn
10,296 Points
dcn
dcn
10,296 Points

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.

dcn
dcn
10,296 Points
dcn
dcn
10,296 Points

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.