Last week we explored what version control meant, and how Git works behind the scenes, but how is it actually used on the user-end?
Before we start, you need to install Git, which can be done easily using their website.
With Git installed the initial step is to set up your Git configurations. This is as easy as running two commands to set your username and email address:
[elle@penguinbook]$ git config --global user.name "myusername" [elle@penguinbook]$ git config --global user.email email@example.com
You can also run
git config --list to review all available settings. Most users need not change any more than their username and email.
Before we proceed, you want to create or navigate to a project directory from which to work. This can be an already-existing project, a new one you intend on working with, or a sample, throw-away directory with files that you can expunge when you are comfortable with using Git for actual projects. We are using a project, “gitetgithub,” saved in a directory with the same name. In it, I have two files: A README, and blog.md (a copy of this post written up to this very point).
Ensure you are in your project directory, then initialize the directory:
[elle@penguinbook gitetgithub]$ git init Initialized empty Git repository in /Users/elle/Archives/Playground/Linux/git/gitetgithub/.git/
A Git repository is now initialized in your chosen directory, but no files are committed to the project yet. You can check this with the
git status command.
[elle@penguinbook gitetgithub]$ git status On branch master
Untracked files: (use "git add <file>..." to include in what will be committed)
nothing added to commit but untracked files present (use "git add" to track)
This means that Git does not yet track changes to these files. However, this is not what we want. To track our files, we need to use the `git add` command.
[elle@penguinbook gitetgithub]$ git add .
As it stands, the above code adds everything in the directory to the staging area of Git, where file saves are stored before committed. The period (
.) can be replaced with individual file names for a more fine-tuned way to add files.
However, we are still not quite done. While Git now tracks changes to these files, they have not been committed to the repository. Think of a commit as a hard save. Up until this point, you have changed and saved the individual project files. When you commit a project in Git, you are saving the entirety of your project in its current state. Think of it as taking a snapshot of your work: You can, in the future, go back and take a look at the state of your project the moment a commit was made. Like looking at a photograph, you can access the past, but with far more useful implications.
Which brings us to the commit: Assume we have reached a place in our project where we are content with things as a whole and want to save it to Git. To do this we use
[elle@penguinbook gitetgithub]$ git commit -m "Initial commit for blog." [master (root-commit) cdccaae] Initial commit for blog. 2 files changed, 16 insertions(+) create mode 100644 README create mode 100644 blog.md
-m flag denotes a comment, or message, for the commit. We included that this was the initial commit. You can also see where Git outputs the changes made: Two files have been changed with 16 insertions between them. Additionally, you can see that these files were new to Git, because
create mode is referenced in the output; this does not happen when files are only updated on the repo.
Now, assume more time has past and changes have been made to your documents. You’ve saved the files, but these changes are still not committed to Git, and will not be until you decide the project is ready for its next “snapshot.” We suggest running
git status before tracking or committing changes to ensure the proper files are included.
[elle@penguinbook gitetgithub]$ git status On branch master Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory)
no changes added to commit (use "git add" and/or "git commit -a")
We can now add the files to staging and commit when ready:
[elle@penguinbook gitetgithub]$ git commit -m "Substantial addition to blog post" [master 3bdeaf6] Substantial addition to blog post 1 file changed, 50 insertions(+), 2 deletions(-)
Again, note where it lists the changes.
But say you want to make a potential change that you do not know belongs in the master version of the document. To take a copy of your project and work with it in a separate “environment,” you can use branches.
In our example, we want to review our document to make edits, but we’re not sure we want to keep those edits in the final version. To safely make edits without having any effect on the original project, we can use a branch.
Create a new branch (we called ours “edits”), and review your available branches:
[elle@penguinbook gitetgithub]$ git branch edits [elle@penguinbook gitetgithub]$ git branch edits * master
The master branch, denoted by the asterisk (
*), is the primary branch of the project. If anything, think of it as the trunk from which the different branches grow.
We want to switch branches before we make any edits:
[elle@penguinbook gitetgithub]$ git checkout edits Switched to branch 'edits'
edits with the name of your branch.
From here, we can make any changes we desire, then track and commit them as before.
[elle@penguinbook gitetgithub]$ vim blog.md [elle@penguinbook gitetgithub]$ git status On branch edits Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory)
no changes added to commit (use "git add" and/or "git commit -a") [elle@penguinbook gitetgithub]$ git add blog.md [elle@penguinbook gitetgithub]$ git commit -m "More blog." [edits a8fadeb] More blog. 1 file changed, 51 insertions(+), 1 deletion(-)
Now, let’s say we’ve looked over the edits and are happy with them. We want to bring these changes over to our master version of the project. Return to the master branch:
[elle@penguinbook gitetgithub]$ git checkout master Switched to branch 'master'
And simply merge your edits with
git merge, replacing
edits with your chosen branch name:
[elle@penguinbook gitetgithub]$ git merge edits Updating 3bdeaf6..a8fadeb Fast-forward blog.md | 52 +++++++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 51 insertions(+), 1 deletion(-)
You can also delete the merged branch if you are no longer working from it:
[elle@penguinbook gitetgithub]$ git branch -d edits Deleted branch edits (was a8fadeb).
At this point, the basic Git functions have been used, your project has been altered, edited, and you think it might be ready to extend to the greater community. There is where GitHub comes in.
Git with GitHub
Assuming you have registered with GitHub and completed any steps necessary to activate your account, you can now take your new project and push it to GitHub.
From GitHub, select New repository. I gave mine the same name as my file directory: gitetgithub.
Since our local repo already has a README, we do not need to select the option to add one. Press Create repository.
We then want to use the
git remote command to associate our local repo with our GitHub. For us, this looks like:
[elle@penguinbook gitetgithub]$ git remote add origin firstname.lastname@example.org:rabbitheart/gitetgithub.git
You will have to replace your username and Git repository with your own. The command should also be provided on your GitHub page.
We can now push our project to GitHub using
[elle@penguinbook gitetgithub]$ git push -u origin master Warning: Permanently added the RSA host key for IP address '22.214.171.124' to the list of known hosts. Counting objects: 10, done. Delta compression using up to 4 threads. Compressing objects: 100% (9/9), done. Writing objects: 100% (10/10), 3.10 KiB | 0 bytes/s, done. Total 10 (delta 2), reused 0 (delta 0) To email@example.com:rabbitheart/gitetgithub.git * [new branch] master -> master Branch master set up to track remote branch master from origin.
git push -u origin master to push any additional changes you make to the project to GitHub.
Beyond working on your own projects, you can also clone someone else’s repository to work from. This is as easy as running
git clone and then appending the text provided in the clone URL box to the end.
To clone the example directory created for this blog, you can use:
[elle@penguinbook gitetgithub]$ git clone https://github.com/rabbitheart/gitetgithub.git
This option requires you to input your GitHub password.
Alternatively, if you have your GitHub account configured to use SSH keys, you can use:
[elle@penguinbook gitetgithub]$ git clone firstname.lastname@example.org:rabbitheart/gitetgithub.git
GitHub itself recommends using the first, HTML5 option.
Git is a vast topic and one that is endlessly useful for those working in a sysadmin or developer position. While the basics are provided here, Git is chock-full of other commands to manipulate your project versions. Similarly, GitHub is not your only online Git repository, although is currently the most popular.
Interested in learning more or exploring alternative options for online repositories? Check out our Git and GitLab course!