7day-Devops: Setting up Github
Connect a GitHub Repo with AWS
Project Link: View Project
Author: Andrei Morosan Email: andrei.morosan2994@gmail.com
Connect a GitHub Repo with AWS
Introducing Today's Project!
Today is all about starting slowly to build the pipeline for our project. For that of course we do have to setup a way in which to manage the temporal flow of the project and ensure multiple people will be able to access the resources and work on our product.
This being said today is all about setting up a version control system and for that we will install GIT and setup our project with Github!
Key tools and concepts
Services I used in this part of the project are:
AWS EC2
Github and Github API
VSCode
Maven/Java
Markdown
Biggest takeaways:
Always setup secure repositories.
Create amazing documentations for other people to be easily able to join your projects and teams.
Project reflection
This project took me approximately 1 hour. The most challenging part was to mess up a bit with Github because I tried some other commands behind the scenes of what you see written in here. The most rewarding part was to refresh some knowledge hidden about Git somewhere in the depths of my brain.
I loved this part of the 7Day-Devops-Challenge as it really puts things into perspective about interconnectivity. Although a small stepping stone in terms of goals I believe this project just builds up to the bigger background goals I had setup for myself to do this year.
This project is part two of a series of DevOps projects where I'm building a CI/CD pipeline! I'll be working on the next project tomorrow and the following days! Stay tuned!
Git and GitHub
Git is like a time machine and filing system for your code. It tracks every change you make, which lets you go back to an earlier version of your work if something breaks. You can also see who made specific changes and when they were made, which makes teamwork/collaboration a lot easier.
In order to install Git I used the following commands:
A command to get the latest updates on the repository for the EC2: sudo dnf update -y
A command that pulls from the repository Git: sudo dnf install git -y
After installation to verify Git was installed we can use the command: git --version
If Git is the tool for tracking changes, think of GitHub as a storage space for different version of your project that Git tracks. Since GitHub is a cloud service, it also lets you access your work from anywehere and collaborate with other developers over the internet.
In this project I will be using Github as a tool that gives us the ability to see our filke changes in a more user-friendly way. Think of how in the previous part of the project we used VSCode to make editing code easy, now we will get the ability to track code changes easy.
In addition to that Github is especially useful in a situation where you are working within a team that needs to share updates and that will review code shared to a code base.
My local repository
A Git repository is a way for developers to store all the files pertaining to project or a product. Aside being a storage space, Git repositories or on short 'repos' also keep the entire history of updates and changes done to that repository.
In addition to Git, since we are setting up the whole thing in cloud we pretty much offer our project a way to be accessed from anywhere in the world, and also we would be able to share the work with any other software engineers in a secure way.
Remember what I was telling you about making our project folder 'think' like a git repo. It's exactly here when we are doing that.
Inside the project folder on our EC2 instance, we run the command: git init
After running git init, the response from the terminal was:
hint: Using 'master' as the name for the initial branch. This default branch name hint: is subject to change. To configure the initial branch name to use in all hint: of your new repositories, which will suppress this warning, call: hint: hint: git config --global init.defaultBranch hint: hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and hint: 'development'. The just-created branch can be renamed via this command: hint: hint: git branch -m Initialized empty Git repository in /home/ec2-user/snowlynx-web-project/.git/
Imagine a branch in git is like a parallel version of the project or a clone which resides in an universe of its own which, as you might already guess, will give us the ability to work, test and develop in parallel with other people!
To push local changes to GitHub, I ran three commands
git add
Let's break down now the basic commands to connect our local Git to Github:
git remote add origin [YOUR GITHUB REPO LINK]
The first command we are using is to let our local git repo know where the github repo is located online, and more than that 'remote add origin' is an instruction we give it to let it know the origin folder from where it should start pushing our work.
git add .
This command stages all (marked by the '.') files in snowlynx-web-project to be saved in the next version of your project.
A staging area is a place where we basically put all the files for a final review before proceeding further to uploading to the branch we want.
git commit
The second command I ran:
git commit -m "Updated index.jsp with new content"
This command saves the staged changes as a snapshot in your project’s history. This means your project's version control history has just saved your latest changes in a new version.
The "-m" argument is simply used to leave a description message for the changes.
git push
The third command I ran is:
git push -u origin master
This command uploads in git cases "pushes" changes to the Github repository.
The "-u" argument tells git to push to a specific branch the 'upstream' of data transmission it creates for the local branch. This is used only for the first commit as the upstream needs to be set once and the local git will now into which branch to 'push' changes next.
For the following changes we will be able to use only 'git push' as a command and it will now to push to the master branch in our case directly.
Authentication
When we commit changes to Github, Git asks for credentials in order to double check you are a person that is authorized to make those changes to the Github repo.
Local Git identity
Git needs author information for commits to track who made what change. If you don't set it manually, Git uses the system's default username, which might not accurately represent your identity in your project's version history.
Running git log showed us the information of what we did in the last step.
It shows the data of the Author the Date and the message we set up when we commited the changes to our master branch.
GitHub tokens
Github however will fail in our case. Wondering why? Well HTTPS although seemingly a secure protocol, it still poses many security risks when transmitting user data and passwords over the internet. Github as a whole decide to drop this type of authentication for this specific reason in order to make our work more secure.
Although the HTTPS authentication will fail Github uses a way more secure method of authentication which will lead us into the next step of creating a Github token!
A GitHub token is a special secret code that lets you log into your GitHub account to use it with apps or to move code around, but it’s safer than a password because you can make it only work for certain things and only for a little while. If you lose it, you can make a new one and the old one stops working so nobody else can use it.
I am using a token in this project to make it more secure and of course adhere to the Github standards I was briefly discussing about earlier.
In order to setup a Github token I had to access my User Settings and then go down on the sidebar on Developer settings where I accessed the Tokens (classic) interface to create one.
Making changes again
I wanted to see Git working in action so I changed the index.jsp file by adding a new line for verification. An issue I had with VSCode and Remote SSH was that I couldn't save the index.jsp file. I will have to do some more debugging on that, but for now I managed to do the changes with the good ol' nano editor.
I finally was able to continue with my commit and push only using the terminal and I am happy. I believe the issues I was having with VS Code Remote SSH are tied to the fact that I am using Manjaro Linux as an operating system and some extensions tend to have their own hiccups if they are proprietary and not fully open source.
Setting up a READMe file
A README is a document that introduces and explains your project, like what the project does, how to set it up, and how to use it.
Having a README is super common practice in software development (not just on GitHub).
My README is written in Markdown because Github processes the markdown language and showcases it nice and stylish in the browser. Special characters can help you format text in Markdown, such as:
Headers
for largest header (H1)
for second largest (H2)
for third (H3), and so forth up to ###### for the smallest header (H6).
Text styling
text to make text bold text to make text italic text to strike through text
Lists
or * for unordered bullet lists 1., 2., etc., for ordered lists Links
link text to create a hyperlink
for a line break (HTML style)
Images
to embed an image
My README file has 6 sections that outline all the necessities to understand this repository such as:
Table of Contents - The table of contents with hyperlinks to different sections
Introduction - Introduction to the project
Technologies - Technologies used.
Setup - how to set it up.
Contact - a way to get in touch with me.
Conclusion - which features the collaborators!
Last updated