12 Days of Gitmas: Committing your changes in Git
Tags: beginners, git, github, tutorial
Published: 2020-01-06 20:00:50

*On the seventh day of Gitmas, my mentee asked of me...
__push-ing, pull-ing, diff-ing?__
[what is SSH-ing](https://dev.to/sushicodes/12-days-of-gitmas-ssh-vs-https-19bp),
[how do I connect these](https://dev.to/sushicodes/12-days-of-gitmas-connecting-your-local-repository-to-github-1d9h),
[what's this "GitHub" of which I've heard](https://dev.to/sushicodes/12-days-of-gitmas-what-is-github-11po),
[Git's ready - what then](https://dev.to/sushicodes/12-days-of-gitmas-your-first-git-project-g3m),
[how do I get Git set up](https://dev.to/sushicodes/12-days-of-gitmas-setting-up-git-39i8),
[and could you explain Git, pretty please?](https://dev.to/sushicodes/12-days-of-Gitmas-intro-to-Git-4l26)*

Today's Day 7 of the 12 Days of Gitmas, and today we'll be talking about how you actually track and commit your changes in Git.

If you've been following along, by now you know how to [create your own Git project](https://dev.to/sushicodes/12-days-of-gitmas-your-first-git-project-g3m), and [connect it to GitHub](https://dev.to/sushicodes/12-days-of-gitmas-connecting-your-local-repository-to-github-1d9h).  Now you can work on your project locally!

But... how do you actually *use* the version control aspect of Git?  And how do you get your changes onto GitHub?

**(For this post, make sure you're working on your own repository!  The concepts will be the same if you're working with someone else's project, however there's some additional information you'll need to know first that we'll go over when we discuss branches and PRs, in an upcoming post.)**

First thing first, go ahead and make some changes in your project.  For example, add some information to your README, and add a new file within your project.

Now go to your console, and type:
`git status`
You'll see a list of all the files in your project that have been added or changed since the last commit.

![screenshot of my terminal with the results of the git status command](https://live.staticflickr.com/65535/49340725516_c9b2de3193_o.png "git status")
<figcaption>Here you can see that I deleted a file called <code>.DS_Store</code>, made some changes to the <code>README.md</code> file, and added a new file called <code>index.html</code>.</figcaption>


If you want to see more details about exactly what has been changed, type:
`git diff`
This will show you a "diff" of the files (the difference between the previous version of each file and the new version).

![screenshot of my terminal with the results of the git diff command](https://live.staticflickr.com/65535/49340739736_176203c310_b.jpg "git diff")
<figcaption>This screenshot shows the diff of my changes.  As you can see, it's only showing the changes in the <code>README.md</code> file, because <code>index.html</code> isn't being tracked yet.  Type <code>q</code> to get out of this view.</figcaption>


If you're happy with the changes, then you can
`git add [filename]`
to add all the changes associated with a specific file, or
`git add .`
to add all the changed files.  This tells Git which files you want to add to your commit, to record them to your version control history.

![screenshot of git add and subsequent git status](https://live.staticflickr.com/65535/49340977107_4771df8d1e_o.png "git add")
<figcaption>Once you run <code>git add .</code>, you can do <code>git status</code> again to see that your files have been added.  The files with changes that are staged to be committed will be in green.  If there are any files left that you haven't added, they will still be red.</figcaption>

Lastly, you need to run
`git commit`
in order to commit your changes.  This will open your default editor to write your commit message.  If another text editor opens when you type this, you can write your commit message at the top, save, then quit the application, and Git will commit your changes.

Otherwise, it's likely the default editor is vim.  Vim is notoriously difficult to exit once opened if you're not familiar with it, so there are a few other options.

You can do 
`git commit -m "Write your commit message here"`
to just take care of it entirely in the command line.

Or, you can change your editor.  I prefer to use nano, so whenever I set up a new computer, I run
`git config --global core.editor "nano"`
to set nano as my default editor.  You can get more information about setting different text editors as your default [in this GitHub article](https://help.github.com/en/github/using-git/associating-text-editors-with-git).

![screenshot of git commit in nano](https://live.staticflickr.com/65535/49340995732_f905c4c631_o.png "git commit")
<figcaption>If you change to nano, your commit will look something like this.  <code>^x</code> to exit, then <code>y</code> to save your commit message.  If you <code>n</code>, it will just cancel the commit.</figcaption>

You may be wondering, what should you write as your commit message?  Different companies or projects have different standards, so depending on what you're working on, you may have to format your message a specific way or include certain information - like an issue ID, task name, change type (bug, feature, etc.), and so on.

Regardless, you'll want your commit message to be short and concise, yet descriptive.  "bug fix" or "asdf" are terrible commit messages (that, let's be honest, we're all probably guilty of - but it's still a bad practice!), while "adjusted spacing on homepage banner" or "created API for scheduler" are much better.  Ultimately, you'll want to be able to look at your commits from a day ago or a year ago (or have someone else look at your commits!) and be able to have a pretty good idea of what changed in that commit, in case you need to revert your code, or see how something used to be done.

As far as Git is concerned, you've now successfully committed your changes to the version control system.  But wait - your changes aren't in GitHub yet, so nobody else can see or use them!

In order to update GitHub with your changes, there are two more commands you need to know.

First,
`git pull origin master`
If someone else is working on the project with you, then they may have made changes as well!  You need to pull down their changes to your local machine regularly, so your repository is up to date.  (We'll talk about what `origin master` means when we discuss branches in a couple of posts.)

![screenshot of git pull](https://live.staticflickr.com/65535/49341016847_8f4fae4c4b_o.png "git pull origin master")
<figcaption>No one else has made changes to my repository, so when I pull, it's already up to date.</figcaption>

Then,
`git push origin master`
This pushes your changes to GitHub, so everyone else on the project can see them.  It's good practice to always make sure you `git pull` first, because if there are changes on GitHub that you don't have locally, and you try to `git push`, you'll get an error telling you to `git pull` first.

![screenshot of git push](https://live.staticflickr.com/65535/49341016822_9c03b1b1d8_o.png "git push origin master")
<figcaption>Every time you push your code, it will look something like this.</figcaption>

And that's that!  You now know how to make changes, commit them in Git, and push them to your GitHub repository.  But that's not all!  We still need to discuss what `.gitignore` is, how to work with someone *else*'s repository, and so much more!  If you're not following yet, make sure to click the Follow button so you'll get notified when the rest of this Git series is posted!

And if you have any questions about Git or requests for other topics you'd like to see me blog about, please leave a comment!  And if you're enjoying this series, consider supporting me on [Patreon](https://www.patreon.com/sushiday), following me on [Twitter](https://twitter.com/sushiday) or checking out my [coding](https://www.twitch.tv/sushicodes) or [cooking](https://www.twitch.tv/sushiday) Twitch streams!