The very first step in creating any project that uses multiple JS dependencies that are managed by node package manager (npm) is to create a
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.
Just like with
.gitignore files for the remained of the program.
.gitignore file lists all of the files that are local to a project that Git should not push to GitHub. A
.gitignore always goes in the top level of the project directory, which is also called the project's 'root'. The root of a project is the folder that is the parent for all the project files and subfolders.
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 create a
.gitignore now and add a few files to it.
node_modules/ .DS_Store // only include this if you are on a Mac dist/
We add the
dist/ folders to the `
.git_ignore/ because these are both automatically generated by npm and webpack, respectively. Since we've only just been introduced to these folders in the last lesson, we'll revisit why we add these folders to the
.gitignore when we learn how they are generated.
As previously mentioned, Git will only ignore the files and folders inside of the
.gitignore if we commit
.gitignore to our project's Git history before we add those folders/files inside of the
.gitignore to our project.
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. And if our project already had a
dist folder when we went to commit out
.gitignore, then we'd be adding those files to GitHub along with our
.gitignore file. This will cause Git to not be able to ignore those files.
This is 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 absolutely needs to know what files should be ignored before they (usually accidentally) get pushed.
That's why we need to be diligent about setting up the
.gitignore first thing, and also committing
.gitignore without any other file with
$ git add .gitignore.
.gitignore file has been pushed to GitHub, we can make further commits without worrying about accidentally pushing files that are listed in our
From now on, you should always include a
.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 Git 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 on GitHub's documentation.
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.
While you could add these files to your
.gitignore_global file, it's still important to have the local
.gitignore file. If other developers push to the project later, or if you push to it from a different machine, you'll automatically use the local
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:
ready-to-commit.js, is ready to be committed and pushed.
really-yucky-code.js, isn't ready yet and shouldn't be committed.
$ git add . isn't the answer here. Instead, we should just run
$ git add ready-to-commit.js. And 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, 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 .:
$ git status.
$ git diff [FILE-NAME]to verify that the changes look correct.
$ 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.
$ git commitand 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 5 of 39
Last updated August 31, 2022