Comic From: http://angriestprogrammer.com/comic/source_control

Git-ing down with Git! The Basics of Git for Linux

William Weston Williams

--

Let us start off with a little bit of honesty and transparency! I didn’t use any sort of formal version control until after I graduated from University and I can’t be the only one. Now do not get me wrong, I did have my own kind-of version control system that I learned way back in CS135 and it followed me all the way through to graduation. I would copy my source code into a new folder named “v1”. I would then save this file into another file called “versions” and then continue making edits and saving consecutive versions into the versions file and incrementing the version number for the folder name.

This gets the job done, but in no way is extremely useful and does not work well with teams. I heard this ‘get’ word thrown around all through school, but never really utilized it. I was certain this ‘get’ thing was just shorthand for GitHub. I did have to access code from GitHub from time to time, but I was not going to bother with figuring out anything extra and would just download the zip file and call it good. With my newfound love of command line and exposure to industry, I have quickly learned that ‘git’ was not spelled ‘get’ and could be utilized with or without GitHub. I have found git to be an extremely valuable tool and won’t get into the specifics of what version control is or its inner workings, but will cover the basics of setting up Git and utilizing the basics in a project.

Setting Up:

Before we can start using any tool, we probably should make sure we have the tool installed. Linux makes this extremely easy for us to do. Run the following commands in your command line:

$ git — version

$ git

After running the first command, if you have ‘git’ installed, which came installed by default on my machine running Ubuntu 20.04 as a WSL, you should see the version number of ‘git’ currently installed on your machine. Running the second command will result in displaying git’s help page which can also be displayed using this command:

$ git — help

If the git version number and help page did not show up and you got an error telling you that ‘git’ is not recognized as a command, then it is not installed. Linux will typically tell you the command to install a tool that is not installed, but in case it does not provide it to you, the following will install git:

$ sudo apt-get update

$ sudo apt-get install git

Cool! Now that we have ensured the tool is installed, let us get started on using it! The first thing we should do is configure the name and email git will utilize. We will need to set our name and email to interact with any repositories so that it can track the changes and interactions you make with it. This is helpful when multiple people interact with a repository allowing everyone to see who has done what. Run the following commands inserting your name and email.

$ git config — global user.name <name>

$ git config –global user.email <email>

$ git config — list

The good news is we only must do this once during our first use of git; however, you can change these settings later if you would like. The third command lists the current git configuration; running it should show you at least your name and email that you just set, but there possibly could be additional settings displayed.

Cloning and Commiting:

Now that we have git installed and configured for our use. Let’s get into the actual use of git. For this I utilized GitHub to host my repository. I suggest creating a GitHub repository and adding a few files to it to try the commands out for yourself. The first thing that needs to be done is to create a copy of the repository by cloning it. This will create an exact copy of everything in the repository, but on your local machine. Running the following command will clone a repository to your machine. Use the https URL to clone, so we will not have to worry about fiddling around with SSH keys today.

$ git clone <URL>

Now that you have cloned the repository onto your machine, change directories to where it was cloned, and you will see all the files from the GitHub repository. Open one of the files in a text editor and make some changes; add some content, remove some, do whatever fits your fancy! Now to see the difference between our cloned repository and our GitHub repository we can use the following command. This will show us every difference between our version and the repository version.

$ git diff

Our changes are not officially in our local clone of the repository, even if we saved the file after making edits. To make them official, we first need to tell git we would like it to remember the changes we made. Use the first command to tell git that we intend to add a changed file to our local clone of the repository or the second command to tell git we would like to add all changed files to the local clone of the repository.

$ git add <changed-file>

$ git add .

Now that we have notified git that we intend to save these changes to our local master branch, we are ready to finalize those changes to our local repository. We now will commit the changes to our local repository with the following command. We also will need to write a message about the changes we made, it is best practice to try to make this meaningful.

$ git commit -m “Type you commit message between these quotes”

Updating the Remote Repository:

Now our local repository officially includes the changes we made to our files; however, the remote repository located on GitHub is still unchanged. We will want to update our remote repository so that anyone else who clones it will get the most up-to-date code. To do this, we will push our local repository to the remote repository on GitHub which will update it with our changes we made locally. Run the following command to accomplish this, you will likely have to input your GitHub credentials after submitting the command if you used https to clone the repository to verify your identity:

$ git push origin master

Now our local clone repository and our GitHub remote repository are both up to date with our changes. Suppose after our changes, our team-mate cloned the repository, made changes, and updated the GitHub repository. Our local repository is now out of date! To update our local repository with the changes so that we can work on the most up to date code, we will need to run the following command:

$ git pull

Now our local clone repository is up to date with the most recent version of the project. With just these simple commands that I have covered, you will be able to get started with utilizing git for your project’s version control. This will allow better tracking of versions along with changes that happen during the lifespan of your project along with allow for better team collaboration.

Finally:

I find git to be an extremely valuable resource in project development and way better than my “version” folder solution that I utilized through school. It provides a simple way to implement version control for small to large projects along with allowing better collaboration between team members. GitHub is not the only git compatible resource, as I use Azure DevOps for some projects. You can even utilize git without any remote repository hosting service and do everything on your local machine. Just like any other topic in technology, this has covered only a few bytes of memory when analyzing the vast amount of capabilities and functionalities that git provides.

--

--