Ok so I know I've talked about how this is a "ninja" level and that's an ever so slight misleading statement. In my honest opinion, I think this post will take you to that green belt level, which is green belt by the eyes of a traditional developer. You'll be a "ninja" with your system administrators, engineers, and solution architects (basically your traditional "on-premises" IT roles). So it's "ninja" for ops people and "green belt" for devs. I wanted to make sure you 100% knew, in case you decided to tell a developer you reached "ninja" level. ;)
I personally still think you'll find yourself tripped up from time to time (yes, even after these blogs). That's why I encourage collaboration with your dev friends. I know plenty of devs who love rattling on and on about source control, almost as if it's a hobby. They can help you if a repo (local or remote) is completely borked and in need of some TLC. Never be afraid to befriend and ask! Turns out devs aren't as scary as we may have all thought and there's a high probability they need your help at some point, too!
Now, what have we covered so far? Well first, I outlined all the terms you'll find when folks talk about source control. Then I took you through the basics of source control. This post will cover the next step in this process: pushing local changes to a remote repository.
I often commit local code to a remote repository. In the days where hardware still fails, saving your code somewhere else is beneficial. I use this technique if I'm the sole contributor to a repository and I think it'll help you out as you become more familiar with source control!
So let's take that Harry Potter example from my last blog. After my last blog, you should've edited the harry.txt file, the dumbledore.txt file, and the snape.txt file. This would mimic changes you potentially made with any local code you've saved. The files should literally only look like this:
I know in my earlier blog, I had you clone from my repository. Because I don't want to do anything to that repository and I'd rather leave it up for others, let's create a brand new remote repository on GitHub. Rather than cover how to set up a GitHub account, check out the documentation for how to set this up. Note, if you prefer to use something else (maybe something in the Atlassian family, for example), that's completely fine. The flow will be the same.
After your account is set up, we'll want to create a new repository using the web GUI. I decided to include a link to the documentation in case you've never seen it before. The big thing will be to initialize with a README file as the repo is created. I'll briefly walk through what we'll do in the following example.
1) At your profile home page in GitHub, click on New at the top, underneath Repositories.
2) Leave the template at No template, select the owner (for my example, it will be my GitHub user handle), type in source-control-test for the repository name, you can provide a description if it's helpful to you, unless you pay for GitHub, you'll need to ensure the repo is set to Public, place a checkmark next to Add a README file, don't add a .gitignore template, don't worry about the license file (this is if you're providing example code and want to add an open sourced license file), and leave the Azure Pipelines unchecked. Your example repository should look similar to my example repository and if so, click on the Create repository green button at the bottom:
3) Now that the repository is created on GitHub, it should look somewhat like this example (if the print is too small, you should be able to click on the image and have it load up in a brand new browser window):
4) Next, we need to create a new local repository and match it up with this new remote repository. Use the skills you acquired from my previous blog post to copy the https clone address and I encourage you to use your shell prompt wherever you can to become more comfortable with the git commands. Here's what I typed into my command prompt:
mkdir source-control-test
cd .\source-control-test\
git clone https://github.com/sbkuehn/source-control-test.gitIn my terminal, here's how everything looked:
Locally, you should see the following files:
5) Copy the .txt files from the sample-git-demo folder to the source-control-test folder. The results should look like this:
6) Switch back to your shell prompt. We're going to dig into the commands to push changes to the new remote repository. Follow along and plug these commands into your local environment.
git status
git add .
git commit -m "Adding in files for first commit"
git push originIn your shell prompt, this is what it will look like (I edited the transparency level so you can see the -m in the git command flow):
So in this example, I moved into the git repo locally on my machine. I first checked the status using git status (always a good idea if you're brand new and working with a repo that contains a number of contributors). From there, I added in all the files I wanted to commit using the git add . command. Next, I committed all the new files into a commit using the git commit -m command. And finally I pushed all changes to the origin using git push origin. In terms of differences between my last blog and my current blog, we have a push and origin that probably need some clarification.
In this example, we're pushing local changes to a remote repository in GitHub that we created earlier in the blog. Let's take a look at the remote repository configured within the local git repository you cloned. You can inspect this with the following git command: git remote -v.
In my example, think of origin as a shorthand name for the remote repository the project was originally cloned from. Since I created a separate repository on GitHub for this specific purpose of getting you more familiar with remote repositories and we're going to take this up a notch in the last blog post, we don't need to specify a branch. Origin works for purposes of pushing local changes to GitHub.
Let's take a look at GitHub next:
All of the files are now in the source-control-test repository with the changes you made locally within the last blog post:
Hopefully this simple example shows you how quickly you can commit code to a remote repository for safe keeping. This example is good if you're a sole contributor to a repository with example code. I'm always keen on sharing code with folks online, so hopefully you are, too. And this example shows you how easy it is to commit code to a remote repository!
Stay tuned for the last post where I walk you through a forking exercise. I think after that exercise, you should feel a lot more comfortable with source control and be that "ninja" in the hearts and minds of ops folks and a perpetual green belt in the mind of a dev. The big takeaway is to always consider partnering up with a dev in case you get yourself stuck committing code to a remote repository for safe keeping!
Until next time!
Comments