Effective Git, zero to max in small steps: First 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.