Appendix B. Version Control with Git

Installing Git

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.

Using Git

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>"
Tip

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.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.133.160.14