In Using Git for Website Version Control I talked in general about how I use Git to manage development of my website. In this post, I’ll show you the process step-by-step.

Overview

To update my website (which I developed using HTML, CSS, and a little JavaScript), I edit the files on my laptop, and then copy (FTP) these modified files to the server. On my laptop, Git lets me make changes on a copy of my website. Ideally, smart use of Git gives me the ability to discard experimental changes and return to an earlier version.

Here is the process I use.

Step 1 — Tell Git I will be making changes

The first thing I do is open the command line (GitBash) and navigate to the GitHub folder for my website. (I use GitBash because I’m using Git for Windows.)

Next I open my development branch. This tells Git I will be working on a copy of my files.

(You can create as many branches as you want, and name them descriptively. I use the name “development” for generic tweaks of my website. I could have a branch called “update,” and then – if I found a bug – I could create a new branch called “bugfix.” This separation can be useful, but you do have to pay more attention to branch management. For what I’m doing it’s just easier to deal with a single “development” branch along with my master branch.)

Any changes I make, from modifying html to adding images, will now be associated with this development branch. My master branch remains pristine, and I can return to it at any time. It’s important to realize that the current branch determines what files are visible in my website folder. When I change branches, Git moves files in the folder on my computer to match the versions associated with the active branch.

Remember: the current branch determines what files are visible in your folder.

What does that look like? Well, if I add a new html file, then switch back to the master branch, that new file will not be visible in my folder. Don’t worry! It’s not gone. Git is showing the files that are associated with the master branch. If I switch back to the development branch, and go back to my folder, the new file will be there. (This does not always seem to happen instantaneously, so be patient.) It can be disconcerting, so take it slowly at the beginning.

Step 2— Modify my files: commit early, commit often

Now, I leave GitBash and start making changes to my files. Rather than saving versions of my index.html file under different names, I will designate “versions” by making commits in Git. These commits are snapshots of my entire project. By using the message option, I can describe exactly what each version represents. Git keeps a history of all the commits, which are identified by a code. Here are some of my recent commits:

Am I at a stable point and thinking of adding a new feature? Commit. Have I finished making navigation changes on one page, and I’m ready to roll it out to all pages? Commit. Am I ready to delete a lot of unused code? Commit.

Use the commits to create strategic snapshots of your changes.

My commits are not ideal; I’m still learning. But, personally, I would rather have too many commits than have no idea what I changed or be unable to go back to an earlier, stable commit. A good philosophy is: commit early, commit often!

Prepare to commit: git status

I’ve made some changes, and I’m ready to make a commit. The first thing I want to do is check what files have been changed. The git status command shows me that I have modified several files, which show in red.

Add files to staging area: git add --all and git status

The next step is to add the changed files to the git staging area. I use the git add --all command to ensure I pick up all file changes, both deletions and additions. I always follow this with a git status command, to check that I have added all the modified files. (I may be a tad paranoid, but I like the visual confirmation.) Notice the files now show in green.

Commit the changes: git commit -m "Add your 50 char message here"

I’m ready to commit these changes, so I use the git commit command. I use the -m message option so I can keep track of what was changed. (The first line of your commit message is what shows in the git log command. See the seven rules of a great git commit message.)

I always follow this command with the git status command. (If you leave off the -m option, Git will open an editor and you can enter a longer commit message.)

Step 3 — Apply your changes

After I’ve made and tested my changes, I want to apply them to my master copy. I’m going to review the commit log, check the file differences to make sure I’m applying the changes I want, and finally, I’ll merge the development branch changes into my master branch. This is how I do it:

Check the commit log: git log

First, I’ll review the commit log. There are many options to the git log command, but I use git log --oneline --graph --all --decorate because it shows a single line per commit and has color-highlighting:

Notice that the development branch has more commits than the master branch. That reflects the changes I’ve made. (The HEAD pointer tells me that the development branch is the current branch.)

Check the differences between the branches: git diff

I always like to take a look at the changes before applying them to the master branch. To do this, I use git diff master..development. This command will show me the differences between the master branch and the development branch.

Items (or files) that were removed are shown in red, and items (or files) that were added are shown in green. (The red patch indicates I removed some white space.)

Change to the master branch

Now that I’m happy and ready to apply the changes, I switch back to the master branch using git checkout master.

(Finally) Apply the changes: git merge development

Once I’m in the master branch, I use git merge development to tell Git I want to merge the changes from the development branch into the master branch.

Check the status

I can use my git log --oneline --graph --all --decorate command to check that all of the branches are now at the same commit – in other words, that I have successfully applied my changes to the master branch. As you can see below, HEAD, master, and development are at the same commit: d13e98d.

Step 4 – Final Test and Deploy the website

At this point, I perform one last check using my local files and FTP the files to my web hosting server. (I use Filezilla.) My website is deployed!

Now it’s your turn!

You don’t have to publish your own website to practice using Git for local version control. Although it is more useful for text files and source code, Git will track changes in any type of file. Pick a folder and try it out!