Lesson Weekend

Before we build out our shape tracker project any further, we'll add a .gitignore file to the root directory of the project. We briefly discussed .gitignore files in Git Configurations. That lesson discussed setting up a .gitignore_global file which we can use to ensure that git ignores files we don't want to commit to GitHub. .gitignore files aren't specific to JavaScript. In general, they should be included in all projects being pushed to GitHub.

A .gitignore file specifies that git should ignore files that are local to a project. It always goes in the top level of the project directory. In order for a .gitignore file to work correctly, it must be committed to GitHub before we commit (by accident) any code we don't want to push to GitHub.

Let's add a few files to our .gitignore now.


We add node_modules/ because we don't want anything from this directory to be pushed to GitHub. All we need to install these packages locally is in our package.json file. $ npm install will take care of the rest. The node_modules/ directory can get very big and it would really bloat our repository to include this code. It also looks unprofessional to have any of the above files in a GitHub repository. (Note: .DS_Store is a Mac-specific file that doesn't need to be committed with your repository - it won't exist on PC machines. We'll learn more about the dist/ directory when we explore webpack further.)

You may wonder why package-lock.json is not included in this list. If it's automatically going to be generated when we run $ npm install, shouldn't we ignore it, too? Well, even though this file is automatically generated, it's still meant to be checked in to source control. It has an exact list of dependencies that are installed at the time the latest commit to it was made. The result of an $ npm install can vary, even with the same package.json. For that reason, it can be very helpful to use the package-lock.json for the previous working commit if there are any issues.

Let's go ahead and make a commit. Set up the repository on your own if you haven't ready. Now we'll make our commit:

$ git add .gitignore
$ git commit -m "add .gitignore file to project"
$ git push origin main

Note that we didn't do $ git add .. That's because our project directory has other files already, including node_modules. If we did a git add . instead, we'd push node_modules to GitHub along with our .gitignore file. It would be like putting up a sign that says "Wet Paint" on a bench after someone has already sat on the bench by accident. Then we'd have a mess to clean up. GitHub needs to know what files should be ignored before they (accidentally) get pushed.

Once our .gitignore file has been pushed to GitHub, we can make further commits without worrying about accidentally pushing files that are listed in our .gitignore.

In fact, let's make another commit that includes our updated package.json file. When we push the code (even if we use $ git add .), node_modules won't be added.

From now on, you should always include a .gitignore file in the top level directory of your projects, not just in this JavaScript course but in future courses as well. This goes for C#, Ruby, and React projects, too. Your first commit should generally include your .gitignore file. Once again, make sure to avoid pushing any files that you want to ignore when you make that first commit - because GitHub won't know they should be ignored yet.

If you do accidentally add a file that should be ignored to your repository, you'll need to remove it. You can do so by running $ git rm -r --cached [FILE-NAME], where [FILE-NAME] is the name of the file that shouldn't be tracked. Git will no longer track the file.

However, this won't entirely fix the problem if you are working with sensitive data. We won't be working with that kind of data in this section, but we will do so once we start working with APIs in the next section. Sensitive data often includes a private key that should never be shared with others. (It's similar to a password.) Just running $ git rm -r --cached [FILE-NAME] won't fix the issue. While GitHub will stop tracking the file, it won't remove the file from your history. That's a big problem - a hacker could still get that information. If you find yourself needing to remove a file from a repository's history, see Removing Files from a Repository's History.

In future lessons, we will specify which files and directories shouldn't be tracked. These files should be added to the local .gitignore file for all future projects. You can also add them to your .gitignore_global file as well. However, it's still important to have the local file. This is a convenience if other developers push to the project later (or you push it from a different machine), using the local .gitignore file in the process.

Git Best Practices

Let's take another look at our commit above. Instead of using $ git add ., we specified the name of the file we wanted to commit. In the real world, using $ git add . is often a bad idea. It's generally better 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 demonstrate why with an example. In the snippet below, we run $ git status to look at an imaginary file.

$ git status
On branch main
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:

  • The first, ready-to-commit.js, is ready to be committed and pushed.
  • The second, really-yucky-code.js, isn't ready yet and shouldn't be committed.
  • The third should never be pushed to Github. You'd never live it down!

Obviously, $ git add . isn't the answer here. Instead, we should just 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.

Checking Changes with $ 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, we can verify we're committing the right code.

If we want to be thorough and follow best practices, we should do the following when we commit (instead of using $ git add .):

  • First, get the $ git status.
  • Use $ git diff [FILE-NAME] to verify that the changes look correct.
  • Use $ git add [FILE-NAME] to select a file to commit. Multiple files can be committed at once if they are related to the same feature - but should be added one by one by doing $ git add file1 file2 etc.
  • Run $ git commit and add a great commit message.

While it's often convenient to run $ git add ., especially for learning projects, we recommend practicing good habits with your git workflow now.

Lesson 8 of 49
Last updated June 22, 2022