Showing posts with label GIT Working Tree. Show all posts
Showing posts with label GIT Working Tree. Show all posts

Friday, 28 December 2018

GIT: The Pieces of Git

As far as the Git workflow is concerned, there are three pieces of Git that we should be aware of before moving forward with some slightly more complex (but totally doable!) explanation.
They are:
  • Repository
  • Index
  • Working Tree
Let’s cover each one in a bit more detail.

Repository

A repository is a collection of commits, and a record of what the project’s working tree looked like at one time. You can access the history of commits via the Git log.
There’s always a current starting point in a repository and that’s called the HEAD. A repository also contains tags and branches.
The job of the repository is to be the container that tracks the changes to your project files.

Working Tree

This is a directory on your file system that is associated with a repository.
You can think of this as the filesystem manifestation of the repository. It’s full of the files you edit, where you add new files, and from which you remove unneeded files. Any changes to the Working Tree are noted by the Index (see below), and show up as modified files.

Index

This is a middle area that sits between your Git repository and your Working Tree.
The Index keeps a list of the files Git is tracking and compares them to your Working Tree when you make changes. These changed files show up as modified before you bundle them up into a commit.
You might have heard this called the staging area where changes go before they are committed to the repository as commit objects.
If you ever use the -a flag when committing, then you are effectively bypassing the Index by turning your changes directly into a commit without staging them first.

GIT: What is a bare Git repository?

The standard way of initializing a new Git repository is to run git init. The directory in which you do this will be become the Working Tree for the repository.
As part of the initialization process, Git creates a .git directory (which his hidden by default because of the . in the name) that contains the repository itself. This is brains of the repository; it's where Git tracks your changes, stores commit objects, refs, etc. You probably only rarely interact with that hidden directory.
Okay, so all of this is to lay the groundwork for understanding a bare Git repository. What the heck is it?
A bare Git repository is a repository that is created without a Working Tree. Go ahead and create one to see.
git init --bare .
Run ls on that directory and you won't see a Working Tree but just the contents of what is typically in the .git directory.
Why this setup?
A bare Git repository is typically used as a Remote Repository that is sharing a repository among several different people. You don't do work right inside the remote repository so there's no Working Tree (the files in your project that you edit), just bare repository data.
And that's it.

GIT: What is the Working Tree in Git?

The Working Tree in Git is a directory (and its files and sub directories) on your file system that is associated with a repository.
It's full of the files you edit, where you add new files, and from which you remove unneeded files. Any changes to the Working Tree are noted by the Index (see below), and show up as modified files.
When you open the files for a project that is being managed as a Git repository then you are access the Working Tree.