Up to this point, you've probably been using
$ git add . every time you commit your code. In the real world, using
$ git add . can be a terrible idea. Instead, you want to add files one at a time and push code that's both ready to be committed (in other words, working, not broken code) that's relevant to the commit you're working on.
Let's check the
$ git status for some imaginary code:
$ 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) modified: ready-to-commit.js modified: really-yucky-code.js modified: most-embarrassing-elementary-school-secrets.md no changes added to commit (use "git add" and/or "git commit -a")
Here we have three files:
$ git add . isn't the answer here. Instead, we'd run
$ git add ready-to-commit.js. If we want to commit multiple files, we could do so by passing in multiple file names like this:
$ git add file1 file2 file3.
$ git diff
We could also verify all the changes we've made in ready-to-commit.js since our last commit by using the
$ git diff command. If we run
$ git diff ready-to-commit.js, we'll see a list of these changes. It's generally a good idea to do a quick
git diff before committing files; that way you can verify you're committing the right code.
Here's how we should make a commit instead of using
$ git add .:
$ git status.
$ git diffto verify that the code looks good.
$ git addto select one or more (but generally not all) files to stage for committing.
$ git commitand add a great commit message.
What about the third file? If we never want to commit it, git shouldn't be tracking it at all. There are many files that shouldn't be tracked. For instance, if a file contains sensitive environmental variables (such as API keys), it shouldn't be tracked. If a file or directory contains libraries or packages that can easily be installed (such as with
npm install), these libraries and packages shouldn't be tracked, either.
We can ensure these files don't get tracked by adding a .gitignore file. It's possible to add a .gitignore file through Github's UI but we'll add one manually. In fact, adding a .gitignore file with any files you want to ignore should be the first thing you do.
The .gitignore file always goes in the top level of the project folder. Here's an example .gitignore file.
.DS_Store is a Mac-specific file that doesn't need to be committed with your repository. It's unnecessary and repos looks cleaner without them. If you haven't done so already, you can also configure your global .gitignore file to always ignore these, as instructed in the Git Configurations lesson from Intro to Programming.
We ignore node_modules because we don't need the code for our individual dependencies in our remote GitHub repository. Our future selves, or other potential users can just run
$ npm install after cloning our project down to install necessary dependencies in their own node_modules directory.
You should never assume a file isn't being tracked just because it's been added to .gitignore. It's very common to add files to .gitignore after Git is already tracking those files. By that point, the horse is already out of the barn. In fact, as soon as you make a commit, Git will start tracking files. We need to create the .gitignore file and specify which files shouldn't be tracked before committing.
If you find that Git is tracking a file that should be ignored, first make sure to add that file to .gitignore. Then run
$ git rm --cached [FILE-NAME], where
[FILE-NAME] is the name of the file that shouldn't be tracked. Git will no longer track the file. The last thing you want is to find out (too late) that a file with sensitive information is on Github for anyone to see.
From now on, your projects should always include a .gitignore file. In future lessons we will specify which files and directories shouldn't be tracked.