Git Commands I’ve Learned to Use

I got interested in software engineering after taking a few college classes in Computer Science, and I learned more by attending a coding bootcamp. Something that I ended up using a lot, and that I didn’t expect I’d have to learn was Git and GitHub. All of the labs that I worked on at my bootcamp come from repositories on GitHub, and when we worked on group projects, knowing how to use Git was vital. In this blog post, I’ll talk about some of the ways I learned to use Git while at my bootcamp.

First off I’ll talk about what Git is and why we use it. Git is something called a version control system (VCS), which basically means it is a system for managing changes to computer programs or documents. There are many different VSC’s out there, but Git is the most commonly used one. It has many different ways to manage changes, including committing changes with a message about what has changed, making branches to make changes that won’t affect your main branch while you work on a new piece of functionality, and merging in changes that were made on a separate branch, either your own, or one someone else made.

So Git is very helpful for keeping track of changes you’ve made in a project, but it would be nowhere near as useful as it is without GitHub. Git commands keep track of your project on your local machine, and GitHub keeps track of it on the internet. This is necessary when you are working on a project with other people, so that there can be a copy of your project on GitHub that everyone can access. GitHub also makes it so that there is a back-up of your project, so if something happens with your computer, it’s relatively easy to get the project onto a new machine.

Now to talk about some of the Git commands I have learned to use the most often. The main one that I’ve learned to use frequently is git status, and it looks like this:

// ♥ > git status
  On branch main
  Your branch is up to date with 'origin/main'.
  Changes not staged for commit:
    (use "git add <file>..." to update what will be committed)
    (use "git restore <file>..." to discard changes in working  
       directory)
          modified:   README.md
  no changes added to commit (use "git add" and/or "git commit -a")

This is the command that will tell you where you are git-wise. It tells you what branch you are on, in this case main. It tells you if your branch is up to date with the version in GitHub, in this case ‘origin/master’. And it tells you if there are any changes to commit and, if so, what files have been changed, in this case README.md, and if those changes have been added to be committed, which they haven’t been in this case. Using git status helps me get my bearings, so that I know what branch I’m on and what files I’ve changed.

But before you can use any git commands, you need to be working with a git repository, or repo. To initialize a Git repo, you run this command:

// ♥ > git init

But in my bootcamp, we started most of our projects using a generator, like rails new or create-react-app, and I found that these will initialize a Git repo for you. This is a place where it is good to use git status to see if you need to initialize a repository, because the command will not work if it is not a git repo, and if it does work, it will tell you if you have anything commit.

Once you’ve started a repo, the next thing you should do is get it on GitHub. This is pretty easy, because GitHub has a button to start new repositories, and it gives you a few sets of commands you’ll need to hook up the repo on your local machine to the one on GitHub. Some of the commands are for initializing or committing, which git status will tell you if you need to do, but the main ones in each set are these:

// ♥ > git remote add origin git@github.com:
           <githubUsername>/<repo-name>.git
// ♥ > git branch -M main
// ♥ > git push -u origin main

I’ll explain a bit about what these commands mean in a later post, but you don’t really need to know what they do to get a Git repo all hooked up with GitHub.

Next, the commands to commit changes. You should be making a commits frequently, and I do it any time I have finished a piece of functionality that I can describe in a short message. First, you have to add any changes to be committed, and the way to do that is:

// ♥ > git add <name>

The <name> is for the file or directory name that you want to track the changes of. You can either use git add with the name of each file you changed that you want to be included in the commit, or, if you want to include every file, you can use git add ., which is a shorthand to include every file in the repo.

Once you have everything added, you can make the commit with this command:

// ♥ > git commit -m "I'm a commit message"
  [main 869f925] I'm a commit message
   1 file changed, 19 insertions(+), 2 deletions(-)

You can see from the response that the commit includes what branch the commit was made in (main), a series of characters to identify the commit (869f925), and the message you wrote, along with some information about what changes were made. Also, when making commits, there are other ways of adding the message, other than -m "<message>", but this is the simplest because it can be done all on the command line without opening another file.

After you’ve committed changes, it’s time to push them from your local machine to your GitHub repository. You do this with this command:

// ♥ > git push

With this, I’ve mentioned everything I’ll cover about Git in this blog post. So far, I’ve talked about most of the things you need to know to use Git for a project that is only one person will work on. There are a lot more Git commands that are necessary when many people add to the project in a GitHub repository. In my next blog post I’ll talk about some of these things, such as branching, cloning, and merging.