Effective Git, zero to max in small steps: First Steps
Tags: git, tutorial, beginners, newbie
Published: 2020-04-28 08:17:49

---
title: "Effective Git, zero to max in small steps: First Steps"
published: true
description: A series exploring how to use Git effectively.
tags: git, tutorial, beginner, newbie
series: "Effective Git, zero to max in small steps"
---

Git probably has the highest ratio of misunderstanding/usage ratios of any software tool. It's also one with a tremendous variety of valid usages that look very little like each other.

I'm going to walk through some of its strengths and one good thing to use it for.

Ostensibly, git is a tool to:
1. Keep track of changes to a codebase
2. Synchronize, and provide tools to synchronize, changes to the same file that may sometimes conflict.

If you're using git for open source work, you need to consider that the credentials you add to it are public too so you need some extra strategies to deal with that.

## Tools and Intro
If you'd like a GUI, I'd recommend whatever's built into your code editor. vcode and Android Studio both have quite decent git clients.

For an advanced usage like selective stage ( partially committing changes in one file ) I very highly recommend git-cola.

Knowledge of the commandline is very useful if you've totally broken something ( which happens on an uncommon but not rare basis ), and to better understand some cryptic errors you might get from the GUIs sometimes.

As far as possible, I'll try to remain tool agnostic and use only git terms, but also tell you things in terms of the commandline.

Note: Since git depends on a local database in the .git folder, changes made from any tool are generally visible in any other tool ( except Android Studio's stages ). So feel free to mix and match as you like.

## Concepts
For the barest use of git, you only need to know two commands.
`stage`

and

`commit`

A commit is a group of 'changes' that you save at once into git. There's a reason I said changes and not files but we'll get to that later. You can think of a change as one line of text that's been added or deleted.\

Since we can add multiple changes at once, to tell git what changes we want to group together, we `stage` them.
Staging tells git that this version of the change is something you're adding to a list that you might want to save or `commit` together.

If you try to `commit` without `stage`, git will do nothing. Since the list of changes that you wanted to save or `commit` is empty.

So let's say you create a new folder and open a terminal inside it.
You initialize git in that folder, to track changes in that folder, with the command
`git init`

Now, let's say you create a text file in there called Readme.txt, you can see how git sees it with
`git status`

Now that you can see that git knows a new file is in there, you can save it into git with
`git add Readme.txt`

Another thing you could do, is `stage` all the files in the folder with
`git add .`
Notice the dot at the end, this tells git to add whatever files it sees *in this folder*

Once you've got the files staged, you can commit!

The barest command (which you should never run actually) you need for this is
`git commit` and you'll see that it's done.

Why shouldn't we just commit (save changes) like this? Because no one would know what changed in with this set of changes.

A *high-level* description message should always be provided with every commit that says *why* it changed along with an *overview* of what.
So a good description message could be "Added readme"

Here's what the commit command looks like when you add a message that explains the change as well.
`git commit -m "Added readme"`

---
That's it for this intro!
Next time, we'll look into branching and merging. What those are and why you might do them.