This step of the Cloud Resume Challenge requires that you maintain and version your code using some form of Source Control. I’ve actually been doing this all along but it’s technically step 13 so I’ve held off talking about it until now 🙂 Like most people, I’m using Git. Technically other Source Control tools are available but Git is so ubiquitous that its use is practically a no-brainer.
Source Control allows you to take a copy (known as a ‘branch’) of your production code, so that you can work on this separately, and then reincorporate (or ‘merge’) it back into your stable codebase later. Git tracks exactly what changes occurred when you committed changes to your branch, meaning that it’s easy to roll back to a previous state if you run into issues.
Separately to Git are cloud-based repository hosting services, the most visible of which being GitHub. With GitHub, you can host your code remotely by pushing it to the service, allowing collaborators to clone your repository (take a copy of it, which still links and can be synchronised with the original repository) or fork it (make an entirely new and separate copy.) When collaborators have finished modifying a file or adding a feature, they can request that code be merged back into the main branch by creating a Pull Request for review and approval.
If you’re on macOS or Linux, Git should already be installed on your machine but it’s generally a good idea to check that it’s at least up to date. The simplest way to then get started is to run:
$git init
…in your project folder, which should then start tracking changes. The first thing you should do after that is to immediately create a branch other than ‘main’ on which to do your actual development. You can check out and create a new branch at the same time with (for example):
$git checkout -b dev
Best practice here is to never work directly on main, and only merge code back into it once it’s ready for public consumption in your production environment. Also, this is a bit of an aside – and there are other ways to do this – but if you’re working on Mac or Linux, I can strongly recommend using OhMyZsh to style your zsh terminal, not least because it gives you a lovely explicit and colourful view of what branch you’re currently on:
When new files are created in your repo, you need to tell Git to track them with:
$git add .
This will bring all untracked files under Git supervision but you can also specify files individually. Once you’re ready to commit changes you can do so as below, making sure to add a message describing the nature of the commit with the -m flag (or else Git will shout at you):
$git commit -m "Made meaningful and important changes."
You can then checkout your main branch and do:
$git merge dev
…to merge in the changes. However, I’ve very much gotten into the habit of of creating pull requests via GitHub, for three reasons. It gives you a great opportunity to pause and reflect on the changes you’re about to make, it provides a visible change log just for your main branch, and finally I’m going to add a manual approval step using GitHub PRs when I create my CI/CD workflows.
To get started using GitHub (once you’ve signed up etc), I can also recommend installing the official GitHub cli tool. This allows you to do things like setting up a your repo on GitHub with:
$gh repo create
This will interactively walk you though the options to create and authenticate with your repo on GitHub. You can also set flags to skip the wizard by setting flags to tell the tool exactly what you want to do (create a new remote from the current local directory, in this case):
$gh repo create my-project --private --source=. --remote=upstream
Once your repo is uploaded, you push committed changes to it with:
$git push origin [branch]
…and pull any new changes down from the remote with:
$git pull origin [branch]
So that’s a whistle stop of Git / GitHub basics. Next, I’m going to start tying everything together and use the GitHub actions automation tool, to build out my CI/CD pipeline…