Git Basics - getting started on the command line

Tools like Git desktop and Acquia dev desktop allow people to use Git without understanding how it actually works. These tools are a fantastic on-ramp to the world of Git, but at some point I hope that everyone gets a chance to work with Git directly from the command line. This will complete your understanding of what happens when you push those buttons in the desktop applications, and make you better at using both! Here are some basics to get started.

Navigating to your code in the terminal

First, you'll need to get a local site up and running. You can do so using MAMP, Kalabox, or any other tool that makes that easier, but make sure you can find out where the files are saved on disk. You'll need to get there from the command line to follow along with the rest of this post.

Open your terminal, and navigate to this location. I do this using the cd command. cd stands for "change directory".

$ cd ~/Sites/jenlampton.com/backdrop/docroot

Pulling the latest changes from the remote

Since other developers might have been working on the code very recently, you'll always want to start by doing a pull. The command for that is straightforward, and you'll use it often:

git pull

Checking on the status of changes

It's a good idea to check on the status of files frequently, so you can keep in mind how much is changing, and when to make your next commit.

git status

The result of the git status command will allow you to see which files have changed, which have been added, and even which have been removed.

Un-doing your recent changes (before they are committed)

If you've changed a file and want to undo those changes, there's a very easy way to put things back the way they were:

git checkout filename.php

The git checkout command will put things back the way they were at the last commit. (This is another good reason to commit often!)

Adding files, and committing your own changes

I recommend committing every time you complete a task, or make some progress that you know is good and worth keeping. In order to include changes to files in your commit you will need to stage them first. Staging files for commit is done using the git add command:

You can stage files individually, or in a group.

// Add a single file
git add index.php
// Add a whole directory
git add themes
// Add everything that's changed (careful with this one!)
git add .

Once the result of git status shows you everything you want to commit at the top (usually in green) you are ready to commit! That command looks something like this:

git commit -m "Fixed a problem with the thingamabobber, and added the smartmenus module."

If you are working with a ticketing system or issue tracker, you probably also want to include the ticket or issue number:

git commit -m "Issue #2121: Fixed a problem with the thingamabobber, and added the smartmenus module."

Pushing your changes to the remote

Once your changes are committed, you should push them up to the remote so that other developers can have your changes too. Note that you should always pull before you push.

git pull
git push

If there's a merge conflict when you pull, you'll need to sort that out before you push. This is why it's a good idea to pull first!

Checking the logs

You may want to review your own work, or see what others have been doing at the same time. Fortunately git keeps a nice clean log of everything, and it's easy to review that log using the following command:

git log

These are the Git commands I use most often, and they should be all you need to get started. As you get more comfortable with Git you'll learn about reverting commits, using different branches, and so much more. But let's not start in the deep end!

Git

Add new comment

© 2024 Jeneration Web Development