Using Git & GitHub to Save Your Code When I was very young, I somehow stumbled into the world of C++ and put together the perennial favorite "Hello World" program. I compiled it, executed it, and got the pop-up confirming a successful foray into "programming." I, however, never went much further than that because as a 12-year-old, my version control process....sucked. I would lose the source code, then come back to it a week later and make a new file all over again. I would play around and make progress doing little things with C++, but every time I did so, it was basically starting from scratch because I was so bad at maintaining control of my source code. Nothing will kill your ambitions to work with code faster than losing all your progress every time you 'build. The solution to this problem is Git, or in this case, specifically GitHub. We will now take this little Terraform deploy from Part 3 and put it into GitHub using a few basic Git commands on the built-in terminal in VSCode (there is a VSCode Github extension to do this, but it’s best that you understand what Git commands are used to achieve this type of task before relying on an extension to do it for you). You could also use your OS’s native terminal (CMD, Powershell, ZSH, whatever) for these steps. Open the terminal in VSCode by hitting "CTRL + `" (thats a backtick, the little key to the left of "1") In this new terminal, verify that you are in the correct file directory (it should be by default). In the next step, we will initialize a Git repo in this folder and start tracking changes to your code. If this isn't the directory where your code is, change it to the correct directory. We now want to initialize Git; to do this type: git init Git is now running in this directory, however, it isn't tracking any files (or code in those files). Git can use local code repositories as well as remote code repositories (“repo”). In most professional settings, you will be using a remote repo with a service like Github, Gitlab, Bitbucket, etc… We need to tell Git where to send this code we are about to have it tracked. To do that, we use the . git remote add The syntax for this looks like this: git remote add origin https://github.com/owner/repo_name.git breaking this down: instructs git to add a remote repo named “origin” and use the URL after it as the destination for this remote repo git remote add origin In my case, I have created a new (empty) repo on GitHub under my account so it looks like this: git remote add origin https://github.com/wellmadeoldfashioned/YT-single-server-arch-AWS.git Now, we can move on to telling git to “track” files. To track a specific file, we can do: OR to track everything in the current repo, you can do: - it’s usually best to be explicit and add individual files and not track all files in a local directory. git add [filename] git add . Let’s now add our terraform file; issue the following command to do that: git add main.tf At this point, the file or files you added in the previous step are now “staged” - all this means is you have told Git to “take a copy of these files as they are now and get ready to send the copies to a repo” (in this case, a remote repo: Github). Once the files are staged, we need to create a commit - think of it like a checkpoint in your development progress where you can add a short message describing the checkpoint. To stage a commit, we use - it’s tradition that on the first commit, you use something like “initial commit,” but there are no rules dictating what goes into the message. Generally speaking, you want to be concise and descriptive. For example, if this was a commit that updated a variable name, we would say just that git commit -m “[message_goes_here]” git commit -m “updated AMI variable to XYZ” Now issue: - you should receive a few lines of feedback from Git that look like this: git commit -m “initial commit” This is almost complete, but not quite yet. We have initialized Git, added a remote repo, instructed Git to track a specific file, and staged a commit to the remote repo, but we have not yet the commit to the remote repo. sent To send the commit (your "checkpoint” we created above using the Git commit command), you need to issue git push [remote-repo-name] [local-branch-name] To figure out the remote repo name, we need to look back at step 4 to see what we named it, in this case, “origin.” To figure out the local branch name, you can either issue , OR if you didn’t change it from its default setting, it will be “master” for the master branch. git branch As you can see, we are indeed working on the master branch locally. So, to push the code to Github, we need to issue: git push origin master Checking on the GitHub side, we can see the commit I just sent. As well as the actual commit changes: Hopefully, this helps get you started with Git and GitHub. In this working demo, there were some shortcuts taken for the sake of simplicity (like not creating a new branch to preserve the master branch, not merging changes, forking, etc.), but this knowledge is the foundation for learning those things. Once you have comfortability established using Git in this fashion, you should move on to working on different branches, understanding what the “HEAD” is and how to manipulate it, forking repos, merging changes, etc…

Too Long; Didn't Read

Developers: Build Less. Deliver More. [Learn how]	

Unlocking IaC Part 4: Terraform & Github

Too Long; Didn't Read

Chris Ray

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

Unlocking IaC Part 4: Terraform & Github

Too Long; Didn't Read

Chris Ray

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES