Visualizing Git

GIT Tutorial: Part 2

This is Part 2 of the Git tutorial. To see the rest, click here

 Local and Remote

At a high level we will be discussing two separate instances of Git. Firstly there is the instance on your own machine which we can refer to as the local instance. Then there is the instance on some remote machine which we can refer to as the remote instance. There aren’t really any differences between the local and remote except for being on different machines. The remote instance for example could be the place where the team pushes their code to. Ultimately there usually are at least 2 Git copies, your local and somewhere that you push your copy to. Think of it like Subversion and pushing your changes to a remote repository.

Side note: quite often in documentation you will see the remote referenced as “origin” (a default name). 

Creating a Git Repository

Let’s start off by creating a brand new Git Repository.

mkdir Demo
cd Demo
git init

This creates our Demo folder and then creates a new Git repository. Simple!

Logical sections within Git

Within an instance, Git is best visualized as 3 separate buckets.

Buckets

Working Directory

The working directory is what you see in your folders and file system. You make code changes here.

In the Working Directory, you might create a new file called A.txt, add some content and save it.

If we run the command

git status

This will ask Git to see what the current status is. Has anything changed? Are there any files waiting to be added to Git?

Screen Shot 2014-09-07 at 4.34.39 PM

You can see in this example, Git isn’t tracking A.txt. It also tells us how to add the file.

Staging Area

Next you would tell Git to track this new file.

git add A.txt

Alternatively you could add all files within the directory by specifying the dot syntax.

git add .

Running Git status again we see:

git status

Screen Shot 2014-09-07 at 4.38.10 PM

The whole point of the Staging Area is to create a candidate for committing to the database. Take for example fixing a bug. It would be far cleaner and easier to read 1 commit to the database e.g. “#424 Bug fixed” rather than 10 piecemeal commits all contributing to the commit. In Git we can stage and manipulate our commits to make history more logical and easier to read.

Once you are happy with your your Staged work you would commit it to the actual repository.

Repository

git commit -m "#424 Bug fixed"

Screen Shot 2014-09-07 at 4.40.22 PM

This would move our staged changes into the Repository. Essentially freezing those changes in place.

That’s it! That is a very simple example that touches upon all 3 buckets within Git.

Workflow

To help visualize the bigger picture, the typical day-to-day workflow that you would use would be something like this:

  • Fetch from the database (this updates your repository and brings down all information from the centralized repository)
  • Pull to update your local copy with what is in the remote repository
  • Make some local changes
  • Add them to the Staging Area
  • Commit your Staging Area to the repository
  • Finally when you are happy with your commits, Push them to the remote instance
  • And go to step 1 again…

Don’t worry about the other verbs that we haven’t discussed yet, we’ll touch upon them in later topics.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s