What is covered in this part
- What version control, push, and pull mean
- Version control (Git)
- Push
- Pull
- The main stages of Git
- A Practical Example(Part 4)
## What Do Version Control, Push, and Pull Mean?
Version control (Git)
Version control is a system that records changes to your files over time.
In simple terms, it’s like having a save history for your project. With Git, you create checkpoints called commits. Each commit becomes part of your project history, allowing you to see what changed, know when it changed and go back to an earlier version if needed.
So if something breaks or you realize you preferred an older version, you can easily go back to it instead of starting over.
Here are some commands to keep in mind:
-
git status— Shows which files have changed and whether those changes have already been committed. Only committed changes can be pushed. -
git add .— Tells Git to include all changed files in the next commit. -
git commit -m "..."— Creates the checkpoint (commit) with a message. -
git log— Displays a list of all commits. It displays who made the change, when, and the commit message. -
git showorgit show <commit-id>— Shows the actual lines that were added or removed. It is useful when you want to understand what changed. -
git restore filename(e.g.notes.txt) — Reverts the file back to the last saved commit. It is useful if you made a mistake and want to undo it. -
git checkout <commit-id>(e.g.a1b2c3d) — Lets you look at an older version of the project without deleting your work. It is useful when learning. -
git checkout main— Lets you return to the latest version. -
git restore filename— Lets you undo changes to a file (i.e. go back to last saved version).
Push
Push means sending your saved commits from your computer (local repository) to GitHub (remote repository). When you push:
- Your work and changes are uploaded to GitHub.
- They are backed up online.
- They become available for sharing or collaboration. If you don’t push, your work remains only on your computer and isn’t visible or backed up on GitHub.
Here are some commands to keep in mind:
If it is your first time pushing a repository, you may need:
git push -u origin main(Replace main with master if your branch is named master).
Use git branch(or git status) if you want to check which branch you are currently working on.
If you want to switch to main branch, use:
git branch -M main command.
After your first push, you can just use git push.
You should also note that before pushing, changes must be saved as commits using git add and git commit. When you push, your local commits are uploaded to GitHub so they are stored online, backed up, and available for others to see.
Pull
Pull means downloading the latest commits from GitHub (remote repository) to your computer (local repository).
This is important when:
You work on multiple computers and need the same files everywhere.
You collaborate with others and want their latest changes. For example, group or teams projects.
Updates were made directly on GitHub and you need them on your local machine.
Here are some commands to keep in mind:
-
git pull- Allows you to download the latest commits from GitHub and updates your local files. -
git fetch- Checks for updates without installing them. This command lets you download updates from GitHub without changing your local files. It simply checks for new commits and brings that information into your local repository so you can see what has changed. Unlikegit pull, fetching does not automatically update your working files. This makes it useful when you want to review updates first or confirm that changes exist before applying them. -
git merge- Lets you now combine the updates fetched(git fetch) with your files.
There are other command prompts, such as git pull --rebase, git restore, git reset --hard, which will be covered later in the series.
What Actually Happens at Each Stage
When you are working with Git, your files move through a few simple stages. Once you understand these stages, many Git commands start to make much more sense.
Working Directory - Where changes live.
This is your project folder on your computer. Any time you open a file and make changes, those changes happen here first.
At this point, Git can detect that something has changed, but nothing has been saved yet.
Staging Area - How changes move.
When you run git add, you move specific changes into the staging area. It states: “These are the changes I want to include in my next save.”
Do not panic, you’re still in control it is only that the changes you add get staged.
Local Repository (Commits) - How Git stores history
When you run git commit, Git takes everything in the staging area and saves it as a permanent checkpoint in your local repository (aka. your computer).
At this point, your work is safely saved on your computer, but it hasn’t been sent online yet.
Remote Repository (GitHub) - How local and remote copies relate
When you run git push, Git sends your local commits to GitHub.
You can now breathe because this is when your work is backed up online and becomes visible to others.
Pulling Updates from GitHub
When you run git pull, Git downloads the latest commits from GitHub and applies them to your local project.
The Git Workflow Cycle
After pulling, you’re back in the working directory, ready to continue editing files. From here, the same cycle repeats:
edit files → stage → commit → push → pull → repeat
Once you understand these stages, Git commands start to make a lot more sense.
A Practical Example: Tracking Changes and Pushing to GitHub and Pulling from GitHub (Pending)
Now that we understand what version control, push, and pull mean, let’s walk through a simple example to see how these commands work together in practice in Part 4 of the series, where we will also look into additional Git commands.
As always, feel free to comment below. I welcome feedback and discussion in the comments.
Top comments (0)