Git(Hub) Workflow

GitHub 101 – Module 2/4

This is the second of four posts about GitHub for beginners. In the previous one we talked about what GitHub is; today we are going to discuss its workflow. To help us better understand the concepts, we are going to do a little hands-on, so feel free to download Git and follow along.

As said in the previous post, “at its core, GitHub is a server for storing Git projects” thus GitHub's workflow is really just Git's workflow, so let’s take a look at that:

Source: https://git-scm.com/book/en/v2/Getting-Started-Git-Basics

The working directory is where our source code files are stored. Since we already know that one of Git features is to recall specific versions of files, we can assume that when a file in the working directory is changed a snapshot of it can be saved somewhere – this place is the .git directory, which is kept hidden under the working directory.

Let’s see that in action. We are going to create our working directory. Run Git Bash if you are running Windows, otherwise run Terminal, then enter:

mkdir ~/LearningGit

Great! We now have an ordinary directory under the system home folder (represented by the ~ character). Let’s put Git to work in it; first navigate to our new directory…

cd ~/LearningGit

… then:

git init

All done! ~/LearningGit is now a working directory under which you can see the hidden .git directory by typing:

ls -A

Let’s now create some empty source code files:

touch style.css
touch skin.css

Now that we have added some files to the project, have a snapshot of them been saved in .git? No! Note in that picture above that there is no direct arrow from the working directory to the .git directory; there is a stop in the staging area. What it means is that we must specify which files we want to save a snapshot of by adding them to the staging area:

git add style.css skin.css

We can do that using wildcards too, like…

get add *.css

… or even …

git add *

… to add all files in the current directory (non-recursively).

Once the files are staged, we can save them by issuing a commit. Every commit you make is assigned to your name and email address, so let’s set this first so we can never worry about it again:

git config --global user.name 'My Name'
git config --global user.email my@email.com

Now let’s actually issue the commit:

git commit -m "A useful message"

All done! We have committed our first change to the project, which can be viewed and recalled any time later. To see your commits, enter:

git log

Now let’s change the current state of both files so we can see how recalling – the arrow pointing the other way in the picture – works. You may use whatever text editor you want and insert whatever content you prefer in these files. After that, let’s commit our new changes (and let’s not forget to stage the files first):

git add *
git commit -m "Another useful message"

Finally, let’s recall the files to the state they were at our first commit: blank files. By typing…

git log --oneline

…we can view a very resumed view of our commits from newest to oldest. The code in the left is the commit identifier, which we need to specify in order to define to which point we want to recover our files to, so let’s get the oldest one and enter:

git checkout <commit identifier> style.css

Now your style.css is blank, as it was at our first commit. We can also recall all files, like this:

git checkout <commit identifier>

Now both files are blank and Git gave us a very confusing messages about detached HEAD and branches. What does that mean? That is our subject for the next post. While you wait for it, I recommend you read the Git documentation on the commands we learned today: init, add, log, and checkout) and play around. See you soon!