This article was co-authored by Nicole Marie Eduliantes
Ever tried sending code to your groupmates via Messenger? Or maybe even Discord? Yep… we’ve been there. And trust us, it was not pretty.
Writing code on your own is a breeze. Open your text editor, fire up Python, C, C++, or even whip up a quick webpage with HTML and CSS — easy peasy. But once you start working with others… that’s the exciting part. (Can you feel the sarcasm through the screen?)
Every CS first-year knows the classic horror story: your program works perfectly on your computer, but the moment your groupmates compile it… suddenly your debugger looks like a crime scene. Ask any freshie — they’ve all been through it.
After surviving the tragedy that was our CMSC 18 final project, we decided to save others from the same fate. That’s why we created this step-by-step guide for anyone — CS freshie or not — who’s ever faced the terror of group coding.
This guide is beginner-friendly and covers all the essentials of version control, plus how to implement it using Git and GitHub. And yes, if you’re still wondering what the difference between Git and GitHub is… don’t worry, that’s another canon event for every student out there.
So buckle up! We’re about to take you from a complete version control noob to a Git-and-GitHub master.
Table of Contents
Section 1: Introduction to Version Control
What Is Version Control?
Version control, also known as source control, is the practice of tracking and managing changes made to source code over time. It allows developers to maintain a detailed history of modifications while establishing a central repository that serves as the authoritative version of the project.
This shared reference makes it the perfect solution for collaborative coding, as it helps teams monitor updates, ensures that everyone works on a consistent and up-to-date version of the same source code, and provides a way to manage conflicting changes.
Attribution: SFDC Panther+
What Are the Advantages of Implementing Version Control?
Collaboration
Version control allows multiple developers to work on the same project simultaneously without interfering with one another by maintaining a shared repository. It also helps detect overlapping changes, making merge conflicts easier to identify and resolve efficiently.
Traceability
Implementing version control preserves a comprehensive history of changes, allowing developers to review past modifications and revert the codebase when errors occur or when specific changes need to be undone. It also provides information on when the changes were made, who made them, and why they were made, enhancing the program’s readability and scalability, especially for long-term development.
Debugging
Version control facilitates the debugging process by enabling developers to systematically identify which specific code modifications contributed to the occurrence of bugs and errors.
Automation
Version control also enables the automation of software releases through Continuous Integration (CI) and Continuous Delivery (CD) workflows. These CI/CD tools can automatically build, test, and deploy new versions of the software whenever updates are pushed.
Now that we know what version control is, the question remains:
How do we put it into practice?
Enter Version Control Systems (VCS) — the essential tools that bring version control to life.
What Is a Version Control System (VCS)?
A Version Control System (VCS) lets you manage your code’s history.
Think of it as a Time Stone on steroids — granting god-like control over your code’s timeline. You can:
- Create new timelines (branches)
- Rewrite history (modify commits)
- Erase realities (delete commits)
- Merge alternate timelines safely
Teams collaborate via pull requests, reviewing and approving changes before merging into the main timeline. Every action is tracked, giving you full power to shape, reshape, or reset your code with precision and confidence.
There are several types of Version Control Systems, each with its own features and workflows. Since this article focuses on Git, we will take a closer look at Distributed Version Control Systems (DVCS).
What Is a Distributed Version Control System (DVCS)?
A Distributed Version Control System (DVCS) is a type of VCS in which developers create a full local copy of the repository by cloning the original source code.
This allows them to:
- Commit changes locally
- Create branches
- Perform merges
- Experiment safely
All without accidentally modifying the main repository.
By working locally, developers can experiment and manage their changes safely before sharing them with the team. For this reason, DVCS is best suited for projects requiring high collaboration and the ability to work offline.
Now that we’re done with all the “boring” introductory concepts, let’s dive into the world of Git.
Section 2: Introduction to Git and GitHub
What Is Git?
Git is a free and open-source Distributed Version Control System (DVCS) created by Linus Torvalds in 2005. It is currently maintained by a team of open-source contributors led by Junio Hamano.
Today, Git is one of the most widely used VCS tools in the tech community, renowned for its speed, flexibility, and suitability for collaborative development.
Git Components
- Repository – Contains all files, folders, and history of a project
- Remote Repository – Repository on a server accessible by the team
- Local Repository – Copy stored on your computer
- Working Tree – Project folder where you edit files
- Branch – Separate line of development
- Local Branch – Branch in your local repository
- Remote Branch – Branch on the remote repository
- Staging Area – Area where changes are prepared before committing
What Is GitHub?
GitHub is a cloud-based platform that hosts remote repositories and uses Git as its version control system.
It allows developers to:
- View code
- Share projects
- Collaborate through pull requests
- Manage workflows
- Review changes
Beyond storage, GitHub provides tools — including AI-powered features — that help teams collaborate more efficiently.
GitHub Concepts
- Remote Repository – Repository hosted on GitHub
- Fork – Copy of someone else’s repository under your account
- Clone – Downloading a local copy of a repository
- Pull Request (PR) – Request to merge changes
- Upstream – Original repository you forked
- Syncing / Pulling from Upstream – Updating your fork with changes
What Is the Difference Between Git and GitHub?
In simple terms, Git is the Version Control System (VCS) that manages changes in code, while GitHub is a cloud-based platform where developers host and share their remote repositories. The actual version control process is carried out using Git, with GitHub serving as a place to store and collaborate on those repositories
Git performs version control.
GitHub facilitates collaboration.
Section 3: Setting Up Git and GitHub
Setting Up Git
Step 1: Download Git
Download Git based on your operating system:
https://git-scm.com/install/
Step 2: Open Git Bash (or Terminal)
After installation, open:
- Git Bash (Windows)
- Terminal (Mac/Linux)
Step 3: Configure Your Identity
Run the following commands to configure your global Git identity:
git config --global user.name "Your Name"
git config --global user.email "youremail@example.com"
This ensures that your commits are properly labeled.
Step 4: Set Default Editor (Optional but Recommended)
git config --global core.editor "code --wait"
This sets Visual Studio Code as your default Git editor.
Step 5: Set main as Default Branch Name
git config --global init.defaultBranch main
This ensures all new Git repositories use
mainas the default branch.
Step 6: Verify Your Global Configuration
git config --global --list
Ensure the following appear:
user.name=Your Name
user.email=youremail@example.com
core.editor=code --wait
init.defaultbranch=main
Creating a Git Repository
In this section, we will create a Git repository. This is a local repository that exists only on your computer and cannot be accessed by other devices unless you push it to a remote repository such as GitHub.
Step 1: Create or Choose a Project Folder
- Create a new project folder or choose an existing one.
- Copy its file path.
Step 2: Navigate to Your Project Folder
Open Git Bash and run:
cd [filepath]
Your working directory should now display your selected folder path.
Step 3: Initialize a Git Repository
git init
You should see:
Initialized empty Git repository in [filepath]
Step 4: Create a Python File (app.py)
In your code editor, open your project folder and create a file named app.py with the following code:
def greet(name):
return f"Hello, {name}! Welcome to Git."
def main():
user_name = "Beginner"
print(greet(user_name))
if __name__ == "__main__":
main()
Step 5: Create a .gitignore File
Create a file named .gitignore.
This .gitignore file is important since there might be files in our project folder that we don’t want to include in our repository. It tells Git which files and folders should be ignored and not added to commits.
Step 6: Create a .env File (Simulating Sensitive Data)
Create a file named .env.
For this demonstration, pretend it contains:
- Secret keys
- API keys
- Passwords
These should never be committed.
Step 7: Configure .gitignore
Paste the following into your .gitignore:
# Ignore environment files
.env
# Python cache
__pycache__/
*.pyc
# Virtual environments
venv/
.env/
This ensures that sensitive files and unnecessary system-generated files are not tracked by Git.
Step 8: Stage Your Files
git add .
This will add all new and modified files, excluding those specific in .gitignore, to the staging area.
Step 9: Create Your First Commit
git commit -m "first commit"
This records the changes in the staging area as a new commit in Git’s history. Each commit acts like a save point, so you can later view or restore your project to a previous state if needed.
Step 10: Verify Your Commit History
git log
You should see:
- Author
- Date
- Commit message
Setting Up GitHub
Step 1: Create a GitHub Account
Go to:
https://github.com/
Click Sign Up and complete registration.
Step 2: Setting Up an SSH Key (Optional but Recommended)
Before setting up an SSH key, let’s first understand what it is. This step is optional, since you can also use HTTPS instead of SSH, though SSH is a more secure option.
SSH (Secure Shell) - This is a network protocol that lets one computer communicate securely with another over the internet by encrypting the connection to protect sensitive data. This enables developers to log in to servers, manage files, and run commands remotely.
-
SSH Key - A “password” used by the SSH to verify your identity. Configuring it to your Github account allows you to perform commands without having to type in your username and password each time.
- Private Key – A secret key that stays on your computer and must never be shared.
- Public Key – A “lock” that can be safely shared and can only be opened using the matching private key on your computer.
Think of Facebook:
- Username = Public Key (safe to share)
- Password = Private Key (never share)
Remember that it's "technically" safe to share your username with anyone (stranger danger). Your password, however, must stay secret because anyone who knows it can unlock your account and read all your messages, just like someone could break into an SSH connection if they had your private key.
Follow this tutorial to generate your SSH key:
https://medium.com/@kyledeguzmanx/quick-step-by-step-guide-to-generating-an-ssh-key-in-github-d3c6f7e185bb
Creating a GitHub Repository
We will now be creating a GitHub repository, a remote repository on the cloud that can be viewed and accessed by other people if the repository has been set to public.
Step 1: Create a New Repository
Go to the following link and click on New Repository
https://github.com/new
Step 2: Enter Repository Details
- Repository name
- Description (optional)
No need to modify default settings.
Step 3: Click Create Repository
Remote Repository Configuration
Step 1: Copy Repository URL
On your GitHub repository page:
- Click the Code button
- Copy the HTTPS or SSH URL
Step 2: Link Local Repository to Remote
In Git Bash:
git remote add origin [repository-url]
This connects your local Git project to the remote repository on GitHub.
Step 3: Rename Branch to main
git branch -M main
This renames your current branch to main.
Step 4: Push to GitHub
git push -u origin main
This uploads your local main branch to the remote repository on GitHub and sets it as the default branch for future pushes and pulls
Step 5: Verify Upload
Open your GitHub repository page.
If your files appear under the main branch, your push was successful. Notice that .env was NOT uploaded — thanks to .gitignore.
Section 4: Utilizing Git and GitHub
In this section, we’ll dive deeper into how Git and GitHub are used in real-world collaborative coding. We’ll explore key concepts and commands—and then put them into action by modifying a remote repository ourselves!
Git Commands and More Concepts
- Clone – Copies a remote repository to your local machine.
git clone [repository-url]
- Staging – Adds changes to the staging area and tells Git which changes you want to include in the next commit.
git add [filename] # Stages a specific file
git add . # Stages all changes in the current directory
- Commit – Takes a snapshot of your staged changes and adds them to the project’s history. Each commit acts as a restore point you can backtrack to if needed.
git commit -m "[message]" # Saves your staged changes with a commit message
- Cherry-pick – Applies a specific commit from another branch onto your current branch.
git cherry-pick [commit-hash]
- Status – Shows the current state of your working directory and staging area.
git status
- Commit History – Displays the history of commits in your Git repository.
git log # Complete view of commit history
git log --oneline # Simplified view
git log --oneline --graph --all # Visual graph of commit history
- Branching – Creates a separate line of work so you can develop features or fixes independently without affecting the main code.
git branch # List branches
git branch [branch-name] # Create a new branch
git checkout -b [branch-name] # Create a branch and switch to it
- Merge – Combines changes from one branch into your current branch, creating a unified history.
git merge [branch-name]
- Push – Sends your local commits to the remote repository.
git push [remote-repo-name] [branch-name]
- Pull – Downloads the latest changes from the remote repository and merges them into your current branch, updating your local code automatically.
git pull [remote-repo-name] [branch-name]
- Fetch – Downloads the latest changes from the remote repository to your local repository without merging, allowing you to review them first.
git fetch [remote-name]
- Rebase – Reapplies commits from one branch onto another to maintain a linear history.
git rebase [branch-name]
- Merge Error – Occurs when two branches have changes to the same line of code (or overlapping changes in the same file) and Git cannot automatically determine which change to keep.
Other Useful Commands
- git diff – View unstaged changes.
git diff
- git diff --staged – View staged changes.
git diff --staged
- git restore [file-name] – Discard changes in a file.
git restore [file-name]
- git restore --staged [file-name] – Unstage a specific file.
git restore --staged [file-name]
- git reset – Unstage all files.
git reset
- git commit --amend – Edit the last commit.
git commit --amend
Copying a Repository
Attribution: dataschool.io
This diagram illustrates the workflow of forking a repository, starting with Fork, then Clone, followed by Update, Commit, Push, and ending with creating a Pull Request.
1. Open the demo repository in your browser
https://github.com/lowCortisolDev/python-merge-demo
This is the original (upstream) repository that you will copy and use for practice.
2. Click the Fork button at the top right of the page
Forking creates your own copy of the repository under your GitHub account, letting you experiment freely without touching the original project. In real group projects, developers usually clone the repository directly. But for this demo, we’ll fork it so that you have a safe space to try things out
3. In the dialog that appears, click Create Fork
This generates your own remote repository copy that you fully control.
4. Navigate to your forked repository in your GitHub account
You are now viewing your personal remote version of the project. Any changes you make here won’t affect the original repository.
5. Click the Code button and copy the HTTPS link
This link will be used to clone (download) the repository to your computer.
6. On your computer, create another folder named Demo
This folder will store your local repository files.
7. Open Git Bash (or your terminal) and navigate to the folder
cd ~/Documents
cd Demo
You are moving your terminal into the directory where the repository will be cloned.
8. Clone the repository using the link you copied in step 5
git clone [link] # Paste the link you copied in step 5
Cloning downloads the remote repository and creates a connected local Git repository on your computer.
9. Navigate into the cloned repository folder
You must enter the project directory before making changes. This now serves as your local repository.
10. Open the repository in your Text Editor (VS Code optional but recommended)
Managing Changes
Attribution: Amazon Web Services (AWS)
This diagram shows how changes move between your working tree, staging area, local branches, and the remote repository in Git.
1. Pull the cloned repository on your local Git repository
git pull origin main
Ensures your local repository is synchronized with the latest changes from GitHub before starting new work. This is important as accidentally working on an outdated version will cause a Merge Conflict later on.
2. Create a Second Feature Branch on your local Git repository
git checkout main
git checkout -b feature-analytics
Here, you are switching to
main, and then creating a new branch stemming out of it. The new branch will allow you to develop new features without affecting the main branch.
3. Modify app.py from feature-analytics branch
This allows you to implement the analytics feature in an isolated development branch.
4. Stage, commit, and push the changes in feature-analytics branch
git add .
git commit -m "Add analytics feature"
git push origin feature-analytics
git addmoves changes to the staging area,git commitsaves changes locally, andgit pushuploads the branch to GitHub.
5. Merge Two Feature Branches towards the main branch via Pull Request
A Pull Request allows you to review and merge changes safely on GitHub.
6. Go to your GitHub repository and open the Pull requests tab
This is where branch comparisons and merges happen.
7. Click New pull request
8. Set Base to main and Compare to feature-analytics
This means that you are requesting to merge the feature branch into the main branch.
9. Click Create pull request
This submits the request for review and merging.
10. Click Merge pull request, then Confirm merge
If no conflicts exist, GitHub automatically merges the branch into
main.
11. Repeat the process but merge feature-logging into main
This will result in a Merge Conflict because we deliberately made both branches modify the same line of code.
12. Click Resolve conflicts
This will allow you to see conflicting sections that must be manually resolved.
13. Resolve the Conflict in GitHub Editor
You must manually combine both versions and remove conflict markers (
<<<<<<<,=======,>>>>>>>). Ensure the final code contains both logging and analytics features correctly.
14. Click Mark as resolved, then click Commit merge
This will confirm that the conflict has been properly fixed.
15. Click Merge pull request, then Confirm merge
The feature branch is now successfully merged into
main.
Synchronizing Your Code
After merging the two feature branches using a Pull Request, your local repository may not yet reflect the latest changes from GitHub.
1. Switch to the main branch
git checkout main
We need to switch to the main branch first because we’re about to pull the latest changes from the remote repository into our local main branch.
2. Pull the latest changes from GitHub
git pull origin main
Now, our local main branch is completely up to date with the remote version.
3. Delete the merged branches locally (Optional but recommended)
git branch -d feature-logging
git branch -d feature-analytics
You can delete these branches in our local repository to remove clutter. These branches are no longer needed since the changes in these branches have already been applied to main.
4. Delete the merged branches on GitHub (Optional)
git push origin --delete feature-logging
git push origin --delete feature-analytics
This is similar to the previous step, but this will delete the branches in the remote repository.
5. Verify your branch status
git branch
You should now see:
* main
This confirms that only the
mainbranch remains and your repository is fully synchronized.
Your repository is now fully updated, clean, and ready for your next feature
Congratulations!
You’ve just completed Software Development 101: A Crash Course to Version Control with Git and GitHub!
From understanding the basics of version control, to creating branches, resolving merge conflicts, and collaborating with GitHub, you’ve taken your first big steps toward mastering the tools that power modern software development.
Whether you’re a complete beginner or just brushing up your skills, the knowledge you’ve gained here will make teamwork, code management, and project organization far easier—and way less stressful.
Now go forth, commit boldly, merge wisely, and never fear a conflict again!
References
- https://www.atlassian.com/git/tutorials/what-is-version-control
- https://about.gitlab.com/topics/version-control/
- https://www.w3schools.com/git/git_intro.asp?remote=github



Top comments (0)