Exploring Git Internals: Git And GitHub - Part 2
Subtitle: A Comprehensive Guide to Understanding Git's Core Concepts and Developer Workflows
Git is one of those tools every developer hears about early on—but it can feel confusing until you understand what’s happening behind the scenes. In this blog, we’ll build a solid foundation by learning what Git is, how repositories work, and how a developer typically uses Git in a real workflow.
What is Git?
Git is a Distributed Version Control System (DVCS) used to track changes in your code over time.
Following are the some of the features of git:
Keeps history of every change
Allows you to revert to older versions
Enables multiple developers to work in parallel
Helps manage features, bug fixes, releases, and experiments safely
Components of Git: Repository, Staging, and Committed
When working with Git locally, your project exists across three main states:
Working Directory (your local files) - This is your actual project folder—the files you edit in your code editor.
Staging Area (the “ready to commit” box) - This is where you prepare changes that should go into the next commit. Files can be removed from this stage if they are not to be commited.
Committed Area (history stored in Git) - Once committed, changes are saved in Git’s history.
Developer Workflow: From Local Changes → GitHub Branch → Merge
Let’s simulate a scenario. We have a developer (devA) working on a new feature called login-ui. DevB is working on homepage-ui. Both want to build it safely without breaking the main codebase.
Here is how DevA may want to go about it.
Create/ clone a repository
git init: Initializes a repository as git repository.git clone url: Copies an existing repository to local machine from remote (like from gitHub).This command creates a new Git repository in your folder by generating a hidden
.gitdirectory.Git starts tracking the project from now.
Create a new branch
This allows developer to create a branch where he can make changes without worrying about messing the existing code. Once the developer has made the changes and is confident that the changes he made are correct, he can merge it back into the main/ master branch.
git checkout -b "branch name": Creates a new branch and switches the developer to this new branch.
Check current state
While working, developer may want to check the status of the files (tracked/ untracked, added to staging). This can be done using the following command
git statuswhich branch you're on
which files are modified
which files are staged
what Git expects next
Staging changes
Once a piece of work is done, developer needs to stage the changes (this is final stop before changes are committed to the branch)
Developer has an option stage and unstage files till this stage.
git add <file names>,git add .(adds all new/ updated files to staging)
Committing changes
Once all work is done, the changes can be committed to the branch. This will create and entry in the git log for any one to view in the future.
git commit -m "commit message"This creates a snapshot in Git’s history.
Commit messages should be meaningful and action-based.
“Fix login validation bug”
“Add mobile responsive navbar”
Connect your local repo to remote (Github)
This step is required if the repo was created locally (not required if the repo was cloned from remote)
git remote add origin: This adds a “remote” called origin, pointing to your GitHub repository.origin is just a nickname (a default convention) for the remote URL.
git remote -v: Verify the remote.
Push your branch to GitHub
Time to push local changes to the branch in the remote.
git push origin "branch name"
The developer can not login to the remote site (like GitHub) and verify that his branch is updated with the latest changes.
The team can review the branch, test it, or merge it into the main branch.
Merge the branch to master/main (on GitHub)
On GitHub, merging usually happens through a Pull Request (PR).
Typical GitHub Merge Flow:
Open GitHub repo
Click Compare & Pull Request
Add a description
Request reviewers (optional)
Click Merge Pull Request
Merging on GitHub is usually a better approach rather than merging in local. It helps in Better collaboration in team members, allows code review process, enables running CI (for testing and other activities) and also some companies may have an approval process before merging.
Git Pull Behavior: Rebase True vs False
Finally, pulling the code from remote (to get the changes made by other users ), use git pull
This does the following things:
Fetch latest changes
Integrate them into your branch
But how it integrates changes depends on the git configuration.
git config pull.rebase true: Git will rebase your local commits on top of the updated branch history. This helps in keeping a clean commit history and avoids unnecessary merge commits Visual:
Before pull:
main: A---B---C
local: \---D---E
After rebase pull:
main: A---B---C---D---E
git config pull.rebase false: This is the default. Git will merge remote changes into your branch. This creates a new merge if histories diverge. This helps in tracking ‘when branch is updated’
Before pull:
main: A---B---C
local: \---D---E
After merge pull:
main: A---B---C------M
\ /
D----E
Git Configuration for Working in Terminal
Setting the following configurations in terminal is a good idea (makes the job easier later on)
git config user.name “your name” : git needs to know who is pushing/ pulling
git config user.email “your email”: git needs to know the email
These values appear inside commits so Git can track authorship.
To set them globally add —global to the commands.
git config —list : lists all the configurations
Conclusion
Git is not just a tool—it’s the foundation of how modern software teams collaborate safely and efficiently. Once you understand the idea of staging, committing, and working through branches, Git becomes far less intimidating and far more powerful.
In the next blog, we’ll deep dive into the .git folder to understand what Git actually stores internally and how it manages commits, branches, and history behind the scenes. 🔥
