If you don’t have Git installed on your system, you can find downloads and instructions for your operating system on the Git home page.
We won’t discuss version control in detail in this book, but if you’re not using it, you should be. If you’re not familiar with Git, I encourage you to use this book as an opportunity to practice.
First, from your project root, initialize a repository:
$ git init
This will create a project repository for you (there’s now a hidden directory called .git in your project root).
Inevitably, there will be some files you never want tracked in version control: build artifacts, temporary files, and the like. These files can be explicitly excluded in a file called .gitignore. Go ahead and create a .gitignore file now with the following contents:
# npm debugging logs npm-debug.log* # project dependencies node_modules # OSX folder attributes .DS_Store # temporary files *.tmp *~
If there are any other “junk” files that you know of, you’re welcome to add them here (for example, if you know your editor creates .bak files, you would add *.bak to this list).
A command you’ll be running a lot is git status
, which tells you the current status of your repository. Go ahead and run it now. You should see:
$ git status On branch master Initial commit Untracked files: (use "git add <file>..." to include in what will be committed) .gitignore nothing added to commit but untracked files present (use "git add" to track)
The important thing that Git is telling you is that there’s a new file in the directory (.gitignore), but it’s untracked, meaning Git doesn’t recognize it.
The basic unit of work in a Git repository is the commit. Currently, your repository doesn’t have any commits (you’ve just initialized it and created a file, but you haven’t registered any of that work with Git). Git doesn’t make any assumptions about what files you want to track, so you have to explicitly add .gitignore to the repository:
$ git add .gitignore
We still haven’t created a commit; we’ve simply staged the file .gitignore to go in the next commit. If we run git status
again, we will see:
$ git status On branch master Initial commit Changes to be committed: (use "git rm --cached <file>..." to unstage) new file: .gitignore
Now .gitignore is to be committed. We still haven’t created a commit yet, but when we do, our changes to .gitignore will be in it. We could add more files, but let’s go ahead and create a commit now:
$ git commit -m "Initial commit: added .gitignore."
The string that follows -m
is the commit message: a brief description of the work you’ve done in this commit. This allows you to look back at your commits and see the history of your project unfold.
You can think of a commit as a snapshot of your project at a moment in time. We’ve now taken a snapshot of the project (with only the .gitignore file in it), and you could go back to that at any time. If you run git status
now, Git will tell you:
On branch master nothing to commit, working directory clean
Let’s make some additional changes to our project. In our .gitignore file, we’re ignoring any files named npm-debug.log, but let’s say we want to ignore any files with the .log extension (which is standard practice). Edit the .gitignore file and change that line to *.log
. Let’s also add a file called README.md, which is a standard file that explains the project in the popular Markdown format:
# Learning JavaScript, 3rd Edition ## Git We're learning about Git! This is where we'll put our notes.
Now type git status
:
$ 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: .gitignore Untracked files: (use "git add <file>..." to include in what will be committed) README.md
We now have two changes: one to a tracked file (.gitignore) and one to a new file (README.md). We could add the changes as we did before:
$ git add .gitignore $ git add README.md
But this time we’ll use a shortcut to add all changes, then create a commit with all of those changes:
$ git add -A $ git commit -m "Ignored all .log files and added README.md."
This is a common pattern you’ll be repeating frequently (adding changes and then committing them). Try to make your commits small and logically consistent: think of them as telling a story to someone else, explaining your thought process. Whenever you make changes to your repository, you’ll be following the same pattern: add one or more changes, then create a commit:
$ git add -A $ git commit -m "<brief description of the changes you just made>"
Beginners are often confused by git add
; the name makes it seem like you’re adding files to the repository. Those changes can be new files, but just as likely they’re changes to files already in the repository. In other words, you’re adding changes, not files (and a new file is just a special type of change).
This represents the simplest possible Git workflow; if you want to learn more about Git, I recommend GitHub’s Git Tutorial and Jon Loeliger and Matthew McCullough’s book, Version Control with Git, Second Edition.
3.133.160.14