Why even use Git in the first place? What's the point? What Git skills constitute "enough" learning? How do I know when I can confidently say I "know how to use Git"?

Git is what's known as a "Version Control System" or VCS. There are many VCSs out there, Mercurial, SVN, CVS, TFVC, but Git is by far the predominant one.

The "Why" of Git

Simply put, Git enables efficient collaboration among software engineers. It helps us ensure that development teams have a clear history of what code was changed, when and by whom.

Git also allows engineers to make copies of a codebase and edit that copy as much as they like, without any worry about disrupting others' work.

The "What" of Git

Git allows engineers to:

1. Take "snapshots" of code.

These snapshots or "commits" make it easy for them and others to track progress on a project and share code. How do we do this in Git? Rather than being distracted with commands, we'll cover this in an upcoming tutorial. Read on for now!

2. Sollicit feedback from others.

Collaboration via teammate reviews of your code, especially changes to make to your code, ensure that before you take that final "snaphot" and "commit" it to the official history of changes to your codebase, that it is well written, reduces the chance of it causing problems in the future and most importantly, does what it is supposed to do.

We do this via "pull requests", which is a more itermediate topic which again, we'll cover in an upcoming tutorial.

3. Merge changes made by others engineers.

Often multiple engineers will want to update the same code at the same time. Git lets us ensure that these changes do not conflict with each other before they make it into the official history of changes.

This is done by merging what are known as "branches". Sometimes when you work on code updates, you'll want to create a copy of your entire codebase so you can edit it as you see fit. This is typically called a "branch" and we'll be working with this feature in an upcoming tutorial.

Because branches are copies of an entire codebase, they can exist in various places: on your own machine, on a server somewhere and on other engineer's machines.

When we decide to merge these changes, we will "merge" one branch into another in Git.

4. View the "official history" of what "snapshots" were made to a codebase.

Say you're a new engineer on a project. Or you've just come back from vacation and you want to see what changed among the codebase you're working with. Seeing a "log" or "official history" of your team's main "branch" is a useful feature, which will show a "diff" or record of what was removed or added and by whom.

The Git Concept Cheatsheet

Now that we've covered what Git exactly does and have sprinkled various concepts into the explanations, I'll summarize the key concepts you'll want to understand, hopefully before playing around with Git. Understanding concepts, even briefly, before playing around with a tool, in my personal view, makes everything easier, especially when learning Git.

1. Commits

A given change made to a codebase citing what changed, who made the change and when it happened.

2. Logs

That "official history" of "snapshots" taken of changes made to a codebase. An item in our "log" is basically a "commit".

3. Branches

A copy of the codebase that you can edit to your heart's content, without any implications or risk of disrupting others' work.

Copies of code, or "branches" can live on your local machine, on a server or on other engineer's machines.

4. Merging

Before a "snapshot" (not an official Git term, by the way) or "commit" (indeed, an official Git term) is sometimes created, we want to merge the changes of two branches of the same code and if any conflicts arise, resolve them. A conflict can be a change to a line of code made one person but a similar change made to the same line of code made by another person. The person merging will decide whether to chose theirs, the other person's or combine them both. Sometime, this can be automatic as well.

5. Push

Remember that "branches" can be kept locally on your machine, on a server or on another person's machine. Ultimately though, we'll want to designate some server somewhere that be responsible for taking your code and deploying it to production (or, making it "live" and visible to the public).

Therefore, we will "push" our latest "branch" to this place, which again, is typically a remote server somewhere.

6. Pull

When others "push" their "branches" to this server we're talking about, how do we, the humble engineer working on our version of the codebase, receive updates? What if someone changed the same line of code, "push"ed it to our server but we are working on the same line of code, making a different change?

Well, when using Git, our codebase does not update automatically. That would certainly disrupt our work.

Therefore, when we "pull", we're basically updating the latest version of our code on our local machine.

What Git Does Not Do

Lastly, a word on what Git does not do.

Reviews, feedback and collaboration is a critical aspect of writing quality code. There are tools outside of Git, such as Github (which you probably have heard of), that add extra collaboration features on top of Git. We'll cover these tools in upcoming post bu for now, I wanted to mention this distinction.

What Next?

Read over this article a few times to really ensure you understand the concepts. Write down any questions you have.

Then, when you start playing around with Git, you'll learn much faster, in my opinion.