Published on | Prototyping: From UX to Front End — Medium Patricia Penton

Basic Workflow Commands:

git clone <url>

You’ll need to do this just once for each repository you work with. You can use SSH or HTTPS. It makes an exact copy of the entire repository on your local machine.

2. git status

This is the most important Git command for beginners (arguably for all Git users). It can prevent you from getting into a lot of trouble. It will also help you gain a deeper understanding of how Git works, because it allows you to see what is happening behind the scenes.

What does git status do? It shows you everything you need to know about your current branch. It will show you:

what branch you are currently on
if your branch is up-to-date with the origin
if you have any unstaged changes
if you have any changes in your staging index that are ready to be committed (we will talk more about what a staging index is later)
if you have any changes that have been committed but not merged
useful tips on what to do with this information (Git can be very polite sometimes)

A quick look at my command line history shows that I run git status about every third command. I have a lot of favorite things— my favorite amino acid is proline, my favorite color of Sour Patch Kids is yellow (I know, I’m a monster), and my favorite Git command is git status.

Fig.1. Here, `git status` shows me that I have modified two files (style.css and index.html) and added them to my staging index. I have also modified game.js (but I have not yet added those changes to my staging index).

3. git diff

This will show you all the unstaged changes you have made. It’s different from git status which just shows you the names of the unstaged files you have changed.

Pretty cool, huh? You can also do git diff –color-words to see only the words you have changed. This can be helpful if you have made a lot of changes, because git diff alone will highlight the entire line that has been changed. The output of git diff –color-words is easier on the eyes.

If you add all your files to your staging index, and you run git diff, you won’t see your change anymore. Don’t worry, you can run git diff –staged to see all the changes to the files in your staging index.

4. git checkout -b <branch-name>

This is how you make a new branch and switch to that new branch, all in one command. Your branch names should be short but meaningful.

If you made a typo in your branch name, or otherwise just want to rename it, you can do git branch -m <new-branch-name> and that will rename your current branch.

5. git add <file_name> and git add .

Warning: use git add . with caution! Never run git add . without looking at your git status first.

How does git add <file_name> work? It adds your modified file to your staging index. If you have modified more than one file, git add . will add all the files your have edited to your staging index.

With some twisted kind of Git sorcery, I have in the past accidentally added a whole bunch of files, including a whole bunch of changes that I didn’t actually make, to my staging index. This was terrifying. It’s not a huge deal, because you can unstage them with git reset HEAD <file_name>, but it is avoidable by running git status before adding anything to your staging index.

What the hell is a staging index? It’s where Git stores all your changes that are ready to be committed. If you’re into baseball, you can think of your staging index as being “on deck” and all your unstaged changes as being “in the hole” (if you’re not into baseball, forget I said that).

6. git commit -m “<descriptive but short message about my commit>”

After running git add <file_name> or git add ., you must run git commit -m “<message>” (or you can unstage your changes if you don’t want to commit them, see above). Most likely, you’re going to want to commit your changes.

What’s this message thing about? You must provide a message with your commit. This can be very helpful for you and your fellow programmers if you provide a quality commit message. Here are some guidelines about commit messages:

keep commit messages short (under 50 characters)
make your commit messages descriptive
use the imperative mood (this just means make them sound like commands, so instead of “fixed, fixing, or fixes” just say “fix” )

Here are some examples of bad commit messages:

“Fix stuff” (this tells me nothing, please don’t do this)
“Adds test fixture” (this doesn’t use imperative mood, and it’s only slightly more descriptive than “fix stuff”)

Here are some examples of good commit messages:

“Fix typo in contact us section of landing page”
“Add test fixture for Canadian customer”
“Update CSS button class to make buttons rounded”

7. git push

This will push all your changes to the remote repository. You can think of this as uploading your changes.

After you git push, you will probably (depending on your workflow) have to submit a pull request, get approval, and merge your changes to a master branch. This can all be done in a web browser with a program like GitHub or Bitbucket.

8. git pull

If you think of git push as uploading your changes, you can think of git pull as downloading everyone else’s changes. Remember: you always pull down (download) before pushing up (upload).

After you have pushed your changes, it’s probably a good idea to hop on the master branch (you do this by running git checkout master) and doing a quick git pull, so you can develop on the most current version of master.

Tip: you can do both of these in one command by running git checkout master && git pull. This will execute both commands in that order.

Workflow Summary:

You now have everything you need to successfully clone a repository, create a branch, make changes, and push those changes up to a master branch. Your workflow should look something like this:

git clone <url> (clone a Git repository)
cd (change directory) into your newly cloned repository
git checkout -b <branch-name> (create and switch to your new branch)
git status (the output of this should be pretty boring right now)
make your changes
git status (you should see a list of the files you changed now)
git diff (make sure you actually want these changes)
git add (add your changes to your staging index)
git status (yes, it’s my favorite command, do it)
git commit (commit your changes)
git push (push your changes up to the remote branch)
merge your changes in Bitbucket or GitHub
git checkout master (switch back to the master branch)
git pull (pull down the changes your just merged)
git status (just to make sure everything is nice and clean)
repeat! (except step 1, you only need to clone once)

Other Helpful Commands:

These won’t make-or-break your workflow, but they will make your life easier.

9. git checkout –

The git checkout – command lets you switch to the last branch you were on without actually typing the branch name. It’s like the “last” button on your remote control.

Warning: do not confuse git checkout — with git checkout . that would be a terrible mistake

10. git checkout . and git checkout <file-name>

This can be a bit confusing, because earlier I told you that git checkout -b <branch-name> would create a new branch and switch you to that new branch. The git checkout . command does something very different.

Let’s say you write a lot of code in many different files, and you decide it’s all garbage. The git checkout . command will erase all your work. If you just want to erase all your work in one file, you can use git checkout <file-name>.

Note that these two commands will only revert your unstaged changes. If you run git checkout ., the files in your staging index will be untouched.

11. git grep “<something you want to find>”

This command is invaluable, git grep has saved my life so many times. It’s most helpful if you are working in a very large codebase. The git grep command is like doing a Google search within your repository. GREP is short for “globally search a regular expression and print.” If you search for something, git grep will show you all the files in your repository that contain that thing.

Note: you can run grep without the git in front of it. I don’t recommend doing this unless you specifically want to search all the files that are gitignored in your codebase. It’s slow. It’s painfully slow. It moves like pond water.

Want something even faster? I recommend installing the Silver Searcher. I like the output better than git grep, and you can do convenient things like ignore files you never want to search.

12. git cherry-pick <sha-value>

This command will pick a commit from another branch and put it onto your current branch. It’s helpful if the changes you are making are dependent on changes in a different branch that haven’t been pushed up to master. It’s also helpful if something goes terribly wrong on your branch, and you need to create a new branch to get out of the dark Git hole you have found yourself in, but you want to keep the changes you have made.

Now is a good time to explain what a SHA value is — I thought about explaining it above, when I introduced the git commit -m “<message>” command, but I went on a rant about imperative mood and commit messages instead.

A SHA (Secure Hash Algorithm) value is generated every time you make a commit. You might also hear it referred to as a checksum or a hash value. It’s just a long string of letters and numbers that is unique to each commit (I’m writing about SHA values like they’re no big deal, but they are actually very cool — if you want to nerd out, you should go read more about SHA values).

If you do git log, you will see a list of all the most recent commits in your repository and their corresponding SHA values. It will look something like this:

@:~/trivia-game <master>$ git log
commit 22b620b516f6157224b6d862e7b625e0f201ebb6 (HEAD -> master)
Author: Patricia Penton <pkpenton@gmail.com>
Date:   Fri Sep 29 09:33:22 2017 -0700

Create assets directory and index.html

To cherry-pick a commit, you don’t even need the entire SHA value. You can use the first few characters, like so: git cherry-pick 22b620b51 (this will cherry-pick the commit from the example above).

Summary of all commands:

git clone <url>
git status
git diff and git diff –color-words and git diff –staged
git checkout -b <branch-name> and git branch -m <branch-name>
git add <file_name> and git add .
git commit -m “<message>”
git push
git pull
git checkout –
git checkout . and git checkout <file-name>
git grep “<something you want to find>”
git log and git cherry-pick <sha-value>

Did you find this article helpful? Do you want to see more articles like this? Please hit the “clap” button and share on social media! 🙂

Git for beginners: 12 commands you need to know. was originally published in prototypr on Medium, where people are continuing the conversation by highlighting and responding to this story.

Git for beginners: 12 commands you need to know.

Cool stuff, every week

More Articles