Your First Week In Git

Welcome to Opening Moves. I'm Nadia, an AI host, and today we're talking about your first week in Git.

And I'm Farris, the show's AI co-host. I'm looking forward to this one, Nadia. For anyone new, Git is the most widely used version control system in software development, and it can feel a bit overwhelming at the start.

That's right. We'll break it down day by day, covering what you'd typically learn in your first week. By the end, you'll know the essential commands and understand why Git is so valuable.

So let's jump in. Day one: what actually is Git, and why should you care about version control?

Git is a distributed version control system. Let me unpack that. Version control means keeping track of every change you make to your files, so you can go back to earlier versions if needed.

So it's like a detailed undo history for your project, but spread across time and potentially across many people working together.

Exactly. And distributed means every collaborator has a full copy of the project, including its complete history. That's different from older, centralized systems where there's one central server.

Why does that matter? What advantage does having a full local copy give you?

Two big things. First, you can work offline — most operations are local, so you don't need an internet connection. Second, if the main server goes down, everyone still has a complete backup.

That makes sense. And I imagine it's especially useful when you're working on something experimental and want to keep your main work clean.

Absolutely. You can create branches — separate lines of development — without affecting your main code. We'll get to branches later in the week.

So day one takeaway: Git tracks changes, lets you work offline, and supports branching for experiments. What about installation? How does someone get Git on their machine?

Git is free and open source, and it runs on Windows, macOS, and Linux. The easiest way on macOS is to open Terminal and type git --version. If it's not installed, it'll prompt you to run a command to install it.

And on Windows?

You can download the installer from git-scm.com. Run it, accept the defaults, and you get Git Bash as well, which gives you a Unix-like terminal on Windows.

That's handy. And Linux?

On Debian-based distributions like Ubuntu, you'd run sudo apt-get install git. On Fedora, it's sudo dnf install git. The package manager handles it.

Got it. Now, once it's installed, is there any setup someone should do before they start?

Yes, one important step: configure your identity. Git associates your name and email with every commit you make. Run git config --global user.name, followed by your name in quotes, and git config --global user.email with your email.

So that global flag means it's set for all repositories on this machine, not just one project.

That's right. You can override this per repository if you need to, but the global setting is what you'll want for most cases.

And I imagine this shows up when you look at commit history, so it's useful for collaboration.

Exactly. You'll see who made which change. It's the basis for teamwork in Git. Now, let's create your first repository.

A repository, or repo, is just a folder that Git is tracking. Navigate to where you want your project, create a new folder with mkdir, then run git init inside it.

So git init is the command that turns an ordinary folder into a Git repository?

Yes. It creates a hidden .git folder inside your project. That's where Git stores all the version history and its internal data. You won't typically interact with it directly.

What does someone see after running git init?

You'll see a message saying Initialized empty Git repository in, followed by your folder path. That's it. Your repo exists, but it's empty — no commits yet.

So the repo exists but there's nothing to go back to, no history yet. That makes sense. Now, day two: making your first changes.

Day two is about the core workflow. You make changes to your files, then tell Git about them, then save a snapshot. Let me show you. Create a file called readme.txt and add some text to it.

In plain file terms: create the file using touch or a text editor, add some content, save it. Then what?

Now run git status. This command tells you the current state of your repository — which files have changed, which are new, which are tracked.

And what does git status show for a brand new file?

It'll show the file under Untracked files, coloured in red typically, because Git sees it but isn't keeping track of it yet.

So untracked means Git knows the file exists, but it's not part of the version history. How do you start tracking it?

You add it to the staging area with git add, followed by the filename. So git add readme.txt.

Staging area. That term trips people up. What actually is it?

Think of it as a preparation zone. When you add files, you're saying these exact changes are what I want in the next snapshot. It lets you be precise about what goes into a commit.

So you can stage some files and leave others unstaged, even if they've both changed. That's useful for keeping unrelated changes separate.

Exactly. Run git status again after adding, and you'll see the file now under Changes to be committed, usually in green.

So red means Git sees the change but it's not staged yet. Green means it's staged and ready to be committed. What happens when you commit?

A commit is a snapshot of your staged changes. You create one with git commit -m, and the message in quotes describes what changed and why.

The message flag is -m, and you add a descriptive note in quotes. Why is that message important?

Because months later, when you're looking through history, that message is how you understand what each change was for. Good commit messages are specific and brief.

So commit messages are for your future self and your teammates. What does the output of git commit look like?

You'll see something like, Created commit with a hash — that's a long alphanumeric identifier — and the message you wrote. The commit now exists in your local history.

So that's the basic cycle: modify a file, git add to stage it, git commit to save it. Repeat. What about viewing that history?

Day three. You use git log to see your commit history. Run it and you'll see each commit listed, with the hash, author, date, and your message.

The log shows you the story of the project over time. What if you want to see exactly what changed in a commit?

Git show, followed by the commit hash, displays that specific commit — what files changed, what was added, what was removed.

And if you want to see differences between your working directory and what's been committed?

Git diff does that. Without arguments, it shows unstaged changes — what you've modified but not yet added to the staging area.

That's really useful for reviewing your work before committing. Now, what about day four? What's the next big concept?

Day four is branching. A branch is a separate line of development. By default, you start on the main branch, often called main or master.

Why would you create a separate line? What's the advantage?

You can experiment or work on a feature without touching your working code. If things go wrong, your main branch stays clean. When you're ready, you merge the branch back.

So branches let you work in isolation and only bring changes back when they're ready. How do you create one?

Git branch, followed by a name, creates a new branch. Git checkout, with the branch name, switches to it. You can do both at once with git checkout -b.

So git branch makes it, and git checkout switches to it. And checkout -b is the shortcut for making and moving to a new branch in one step.

Right. Once on your new branch, make commits as usual. Those commits only exist on that branch, not on main.

And when you want to bring those changes back into main?

First, switch back to main with git checkout main. Then run git merge, followed by the branch name. Git combines the histories.

What happens if the same part of a file was changed in both branches?

That's a merge conflict. Git will tell you which files have conflicts. You open those files, manually edit to keep the changes you want, then add and commit.

So conflict resolution is manual — you choose which version to keep. It sounds like something that happens more in collaboration.

Exactly. Which brings us to day five: working with remote repositories and collaborating.

Day five. A remote is a version of your repository hosted elsewhere, typically on services like GitHub, GitLab, or Bitbucket. You connect to one with git remote add.

So you define where the remote lives, give it a name — origin is the conventional name for the main remote.

Yes. Then git push sends your local commits up to the remote. Someone else can then git clone to get a full copy on their machine.

So push is uploading your work, clone is downloading someone else's. What about staying up to date with others?

Git pull fetches changes from the remote and merges them into your local branch. It's essentially git fetch followed by git merge.

So push, pull, and clone are the basic commands for syncing with a remote. That covers the first week nicely.

It does. You now have the foundation: the daily workflow of status, add, commit, log; the confidence to branch and merge; and the basics of working with others remotely.

That's a solid first week. There's more, of course — rebasing, stashing, cherry-picking — but this gets you working.

Absolutely. And the best way to learn is by doing. Create a repo, make commits, create branches, push to GitHub. You'll build muscle memory quickly.

Let's recap what we covered. Day one: Git is a distributed version control system that tracks changes, lets you work offline, and supports branching for parallel work.

Day two: you install Git, configure your identity with git config, and create a repo with git init. The core cycle is modify, add, commit.

Day three: git status shows what's changed, git add stages files, git commit saves a snapshot, and git log lets you review history.

Day four: branches let you work in isolation. You create with git branch, switch with git checkout, and merge with git merge.

Day five: remotes are hosted versions of your repo. You push commits up with git pull, and bring others' work down with git pull.

That's your first week. With these commands, you can track your own work and start collaborating. The rest builds from here.

Thanks, Nadia. If you want to keep learning, chkmate academy has short video courses on digital literacy, coding, software development and cloud, and one-off courses are free with an account.

Thanks for listening to Opening Moves. See you next time.