When I first came across Git and GitHub, I honestly found the two terms confusing. I knew they had something to do with software development, but I did not really understand how they were different or how they worked together.
Then I started seeing words like repository, commit, staging area, push, pull, and SSH keys. That made things even more confusing.
Reading definitions was not enough for me. I wanted to actually see what happens when I use these tools on my own computer. So, instead of only following the theory from my institution, I decided to practice the process step by step.
This is what I learned from setting up my first project and connecting it to GitHub using Git and SSH.
Step 1: Checking and Setting Up Git
The first thing I needed was Git.
Git is a version control system. In simple terms, it keeps track of changes made to files in a project. This means I can see what changed and keep a history of my work.
I first checked whether Git was installed on my Ubuntu environment by running:
git --version
If Git is installed, the terminal displays the version.
After confirming that Git was available, I configured my name and email. Git uses this information to identify the person making a commit.
git config --global user.name "Your Name"
git config --global user.email "your.email@example.com"
This was my first practical understanding of Git. It is not just a place where I store files. It records who made changes and when those changes were committed.
Step 2: Creating and Initializing My Project
Next, I created my project folder and moved into it using the terminal.
cd my-first-project
Then I initialized Git:
git init
The git init command turns the folder into a Git repository.
A repository is simply a project that Git is tracking. When I ran this command, Git created a hidden .git directory inside my project. This directory contains the information Git needs to track the project's history.
At first, I could not see the .git folder normally because it is hidden. That helped me understand that Git works in the background rather than changing the way my project files look.
Step 3: Adding Files and Making My First Commit
After initializing the repository, I needed to tell Git which files I wanted it to track.
I used:
git add .
The dot means to add the files in the current directory to the staging area.
The staging area was another concept I had to understand practically.
I think of it as a preparation area. Before Git records a change permanently in the project history, I first select the changes I want to include.
After staging the files, I created my first commit:
git commit -m "Initial commit"
A commit is basically a saved point in the project's history.
The message "Initial commit" describes what I was saving at that moment. This made more sense to me after actually doing it because I could see that Git was creating a history of my project instead of simply storing another copy of my files.
Step 4: Creating an SSH Key
The next part was connecting my computer to GitHub.
This is where SSH came in.
SSH stands for Secure Shell. In this case, it provides a secure way for my computer to communicate with GitHub without having to enter my GitHub password every time I interact with the repository.
I generated an SSH key using:
ssh-keygen -t ed25519 -C "your.email@example.com"
This created a pair of keys.
The private key stays on my computer and should not be shared. The public key can be added to GitHub.
I displayed my public key with:
cat ~/.ssh/id_ed25519.pub
I then copied the public key and added it to my GitHub account under the SSH and GPG keys section.
After that, I tested the connection:
ssh -T git@github.com
Getting a successful response from GitHub confirmed that my computer could authenticate with my GitHub account using SSH.
That was an important moment for me because I could finally see how my local computer and GitHub were connected.
Step 5: Creating the Remote Repository
The project was still only on my computer at this point.
I needed somewhere on GitHub to store it.
So, I created a new repository on GitHub and gave it the same project name. The repository on GitHub is called a remote repository because it exists online, while the repository on my computer is the local repository.
GitHub gave me an SSH address for the repository. It follows this general format:
git@github.com:username/my-first-project.git
I then connected my local repository to the GitHub repository using:
git remote add origin git@github.com:username/my-first-project.git
Here, origin is simply the name Git gives to the remote repository. It is a common convention, so when I see origin, I know Git is referring to the GitHub repository connected to my local project.
Step 6: Pushing My Project to GitHub
The final step was sending my local commit to GitHub.
I used:
git push -u origin main
The push command sends my local commits to the remote repository.
The origin refers to the GitHub repository I connected earlier, while main refers to the branch where I wanted to push my project.
After the command completed successfully, I opened GitHub and found my project there.
That was probably the part that made everything click for me.
I had created files on my computer, initialized Git, staged the files, committed them, connected the repository using SSH, and finally pushed the project to GitHub.
What I Learned From the Practical Exercise
Before doing this exercise, Git and GitHub felt like two similar things with a lot of unfamiliar terminology.
After doing it myself, the relationship became much clearer.
Git is the tool I use on my computer to track changes and manage the history of my project. GitHub is the online platform where I can store Git repositories and work with other people.
The whole process started with my project on my computer. I used Git to track the project and save its history, then connected that local repository to GitHub. Once the connection was ready, I pushed my project online, where I could access and manage it through my GitHub repository.
I also learned that SSH is not Git itself. It is a secure method of authentication that allows my computer to communicate with GitHub.
What I Took Away
This practical exercise changed the way I looked at Git and GitHub.
Before, commands such as git add, git commit, and git push looked like things I was simply expected to memorize. After using them on a real project, each command started to have a clear purpose.
I also realized that GitHub is more than somewhere to upload code. It can help developers keep track of their work, collaborate with other developers, and access their projects from different computers.
For me, this was a small project, but it was an important step in my data engineering journey. I know I will be using Git and GitHub a lot more as I continue learning, especially when working on data projects and collaborating with other people.
My biggest lesson was simple: some technical concepts only really make sense when you stop reading about them and actually use them.
Top comments (0)