The usage of Git as a primary Source Code Control is ever increasing and with Microsoft purchasing GitHub this is only set to increase.
Personally I have been using Git and Github for a few years now, and it has become my number one choice in Source Code Repository and Version Control System (VCS). Compared to others that I regularly have to deal with in the Enterprise Software Development landscape, it is far less clunky and for the most part far easier to use.
Although I would be the first to admit, it can be a bit intimidating to use, when you’re coming from the IDE based version control systems.
If you want a guide on how to get started and understand the basic Git commands you need to know then this post is for you!
The tool a software developer will probably use the most throughout their day will be a version control system. In some respects you will probably use it as frequently as a text editor or an IDE (Integrated Development Environment).
Gaining a competent level of understanding of how to use a version control system will help your career and future progression. It will also save your bacon when you need it most!
What is Git ?
Git is a distributed version control system for managing source code, which helps developers to manage and track changes to files. Using Git developers can quickly and easily follow and examine the history and changes made to a file of source code to understand the changes made.
When working on a software development team, this is become an essential practice, with multiple team members making changes and additions to source code files on a daily basis. The ability to go back in time, to learn about how a file has changed, who made the changes and why, is crucial to understanding how a bug or unintended behaviour has crept into a file.
Git also helps developers by preventing unintentional overwrite by any developer on a team who may be working on an older version of a file.
A version control system like Git helps developers too:
- Keep track of code history
- Collaborate on code as a team
- See who made which changes
- Deploy to staging or production
Why Learn Terminal Git Commands
Many developers are starting to drift away from the cumbersome do it all for you, point and click Integrated Development Environments (IDE) and starting to make use of lightweight Text Editors like Visual Studio Code, Sublime Text, Atom and myriad of others. These tools are great and can really be a boost to productivity. The downside is many of them don’t necessarily have a direct connection or plugin to a version control system and a lot of the interaction can boil down to using a terminal window.
I came across one of those scenarios the other day when a developer on a team I was working with on a project had not used Git via the command line and didn’t really know how or where to get started. However, after just spending 5 minutes explaining the basic commands and how and when to use them my colleague was able to get up and running with Git really quickly and now it has become his favourite VCS. He also made the remark that he now feels liberated from depending on an IDE to submit changes to a repository.
Another major plus, is the commands and approach to interacting with Git are the same whichever platform you choose to work on. Which from my experience is not always the case with other VCS.
Although the Git does have a extensive documentation available , it can be somewhat overwhelming and intimidating. It may also be a case of a little too much information for most new starters.
I’ll attempt to highlight the most basic commands you need to know to get started, and what you will most likely use on a day-to-day basis. For a broader understanding of Git I recommend Understanding Git Conceptually
Common Git terms
There are a number of common terms and words developers will use when talking about git repositories and working with git. it’s important to understand and remember these,
- Repository – a container that tracks the changes to your project files.
- Working Tree – Consists of files that you are currently working on. You can think of a working tree as a file system where you can view and modify files.
- Index – a snapshot of the content of the working tree, and it is this snapshot that is taken as the contents of the next commit. Staging area where commits are prepared
Common Git commands developers should know
Although mastering git in its entirety, like most things in software development, is an art form, and for the most part, at least 80% of what you’ll learn will more than likely not be used in your regular day-to-day development task.
The below is a list of the most common git commands I predominantly use on a daily basis, which I believe are the essentials for most developers to learn and master.
To create a new empty git repository or to reinitialize an existing one you simply need to navigate to your target directory eg.
cd code and then
This command essentially creates a hidden
.git directory with a number of subfolders
if you execute
git init on an existing git repository, it won’t overwrite any settings or details. it will only pick up any newly added templates or move a repository.
There are a few options you can use, which are essential
-- switches to enable more advanced features.
Check out the Git Init Documentation further details.
For the most part, the average developer starting a new project is
git init more than enough.
Once you’re created files in your folder and you want a quick review of what files have been added, modified or deleted in your folder as compared to you Git Repository. You can use
This will show the working tree status, which is essentially the differences between the index file and the current
HEAD. This provides a list of files that can add to git repository.
git clone is the command you’ll use to target an existing repository and create a clone, or copy of the target repository on your local machine.
Git’s collaboration model is based on repository-to-repository interaction, this means that you
pull commits from one repository to another.
The original git repository you want to clone can be located on the local filesystem or on remote machine accessible supported protocols (https, ssh) i.e. GitHub, BitBucket or your enterprise Git version control repository.
During the course of your development, you will undoubtedly be adding, modifying and deleting files ass you go. At some point you will need to add them to your repository, this is where the
git add command comes in handy.
git add command adds file contents to your index, by adding the content found to your working tree. It typically add the existing paths as whole, but there are options you can use to customise this behaviour.
When first starting out with git, you will enevitably first see the short hand command
git add ., which basically enables developers to add all files with current changes and additions to the index.
git add . with caution often it could incur some unintended consequences
Ideally, you should become a little more verbose when adding files to your index, I typically add files on a one by one basis, using
filepath is the absolute or relative path to a file to the current working directory.
There two additional options you should become familiar with:
-A – stage files new, modified or deleted
-u stage only files modified or deleted files
commit command is used to save your changes to the local repository.
A commit is not automatically transferred to the remote server. Using
git commit only saves a new commit object in the local Git repository.
Sets the commit’s message, to help provide a concise description that helps your teammates understand what and why changes were made to a file.
Includes all changed files to a commit.
new or untracked files are not included
Rewrites the very last commit with any currently staged changes and/or a new commit message. Git will rewrite the last commit and effectively replace it with the amended one.
rewriting of commits should only be performed on commits that have not been pushed to a remote repository
Developers will also make use of a common shorthand for commit files
git commit -am "changes to homepage", but overuse of this can lead to some undesirable outcomes on larger projects.
Once you’ve committed your changes, you will often need to send them to your team repository, often called the
git push isd used to to updates remote refs using local refs, while sending objects necessary to complete the given refs.
git pull command is used to fetch and download content from a remote repository and immediately update the local repository to match that content. Merging remote upstream changes into your local repository is a common task in Git-based collaboration workflows.
git pull command is actually a combination of two other commands,
git fetch followed by
In the first stage of operation, git pull will execute a
git fetch scoped to the local branch that
HEAD is pointed at. Once the content is downloaded,
git pull will enter a merge workflow. A new merge commit will be created and the
HEAD updated to point at the new commit.
A checkout is an act of switching between different versions of a target entity.
git checkout command operates upon three distinct entities:
In addition to the definition of “checkout” the phrase “checking out” is commonly used to imply the act of executing the git checkout command.
git checkout command lets you navigate between the branches created by
git branch. Checking out a branch updates the files in the working directory to match the version stored in that branch, and it tells Git to record all new commits on that branch. Think of it as a way to select which line of development you’re working on.
git branch & git merge
The two most important commands most developers will make use of, and two that make git the number one choice VCS is Branching and Merging. Git helps to simplify this task. Enabling developers to do fairly painlessly compared to other VCS’s I have had experience in working with.
The git documentation has a great example of how to do basic branching and merging and it is well worth taking the time to work through and understand that example. Quite litterally that scenario is highly likely going to be one you’ll be using most of the time.
It may seem daunting at first, but honestly it’s worthwhile taking the time learn and understand branching and merging because its the feature you’ll most likely be using everyday once you learn. It is such a key part of the developer workflow it’s almost as essential as oxygen and StackOverflow.
The most common command I find myself using is
git checkout -b [and what ever I name my branch] Typically the branch name will be a Ticket number I’m working on or something similar. I’ll do all the new development for that specific ticket on that branch and will more than likely do a number of commits to central repository to that branch, so other developers can also checkout of the branch if needed.
Once development has finished and we’re all golden, you’ll invariably merge it to whichever branch it needs merging too – in the case of simple workflow, you may merge it back in Master.
Honestly I cannot recommend the tutorial on how to do basic branching and merging on the git website enough. Rather than repeating the entire content here I would advise you to take at least an hour of your time to go through that tutorial and practice it several times. It really is that important if you’re starting out with git.
Git is a powerful version control system, which is steadily becoming the defacto standard for software development teams. GIt has many commands and can be overwhelming for developers who are new to it to learn. The above guide has covered a majority of the commands developers will most commonly use on a day-to-day basis.
What are some of your favourite git commands you use on a daily basis which you feel every developer should know ?
Let me know in the comment section below!
A unique background as business owner, marketing, software development and business development ensures that he can offer the optimum business consultancy services across a wide spectrum of business challenges.
Latest posts by Gary Woodfine (see all)
- Book Review: Java by Comparison - Jan 7, 2019
- Book Review : The 4 Hour Work Week - Dec 28, 2018
- Happy 4th Blog Birthday – A blogging year in review - Dec 6, 2018