This is a series of posts about using Git. You can read the previous entries at:

Tracing Our Steps (Part 1)

Last time, we built the case for using git. Git is a command line tool. If you haven't worked with the command line too much, you can reference my post about that here.

We're going to cover a lot of technical ground so let me diverge into some lessons I've learned about the process of learning first.

Learning About Learning Technical Info

I've found that, in my experience, and those I've taught, you'll need 2 exposures to the material to really have any of this information stick. My personal process is to read through something like this without being at a computer first. Then go back and try the commands listed again after a day or two have passed. You don't have to do this but it works for me because:

1. I find it easier to read an article or post while out and about (at a restaurant, coffee shop, etc.)

2. If you jump directly into following along, you'll most likely make some mistakes that necessitate re-reading sections anyway, effectively working through it twice

It is, however, crucial that you follow along, type the commands out, and struggle with the instructions at least once to receive ANY benefit. But first, some background on the different platforms.

Introduction to Git Platforms (GitHub, GitLab, Bitbucket)

When it comes to handling our git repositories, several platforms come to the rescue. git is a command line tool, as mentioned, however we need a centralized location to use for collaboration. The big players provide cloud-hosted versions of this. They all provide a place to store your projects, track changes, and collaborate. However, each has its own unique offerings.

GitHub

GitHub, widely used and recognized, has been around since 2008 and boasts a massive user base. It's a go-to platform for open-source contributions, so if you're keen on participating in or initiating open-source projects, GitHub is an excellent choice. They've also made excellent strides in the continuous integration/continuous deployment (CI/CD) space in recent years so this is what we will be demonstrating from.

GitLab

GitLab set itself apart by being one of the first to offer additional features beyond basic git functionality. It included built-in CI/CD features and its own integrated DevOps lifecycle tool that was way ahead of its time. Other products have caught up and taken notes from GitLab since. GitLab does, however, provide an option for self-hosting, giving users more control and customization.

Bitbucket

Bitbucket caters particularly to small teams by offering free private repositories for up to 5 users. It's a good pick for smaller-scale projects and integrates well with other Atlassian products like Jira and Trello.

Remember, these are tools designed to facilitate your work. How you use them will determine your experience. Next, we'll explore how to utilize these platforms and git effectively, beginning with basic git concepts.

Local vs Remote Repositories

Local Repository

When you initiate git in a directory on your computer (or clone from an existing project) that creates what we call a local repository. This is your project's home base where all your changes and versions are tracked. I personally suggest creating the remote repository in Github first, then cloning it down (we'll cover cloning soon).

Remote Repositories

While the local repository keeps track of your work on your own machine, a remote repository exists somewhere else - on a server in the cloud. It provides a shareable copy of your project that others can access and also serves as a backup. You can think of this repository as a home base. People come here to get changes, check-in, drop off changes, etc.

Creating a Remote Repo on GitHub

Making your first remote repository is straightforward with GitHub. Let's go through the steps:

1. Sign in to your account on GitHub. If you don't have one, sign up.

2. Click the '+' icon at the top-right of the page and select 'New repository'.

3. Name your repository and choose if you want it to be public or private. You can also add a brief description.

4. You can initialize the repository with a README file, a .gitignore file, or select a license - but these are optional.

5. Click 'Create repository' when you're done.

6. And there you have it! Your first remote repository on GitHub is set up and ready for collaboration.

Next time, we'll figure out how to authenticate to Github and get a local copy of this onto your computer.

Keep learning and keep growing!

Darrell