Understanding Git conceptually is useful, but the workflow becomes much clearer when you use it on a real repository.
In this guide, you will copy the GitHub repository created earlier in the series to your computer, edit a file in Visual Studio Code, record the change with Git, and send the new commit back to GitHub.
The complete workflow is:
Clone → Edit → Check status → Review changes → Stage → Commit → Push
You will also make a small change on GitHub and use git pull to bring it back to your local repository.
This tutorial uses a WSL terminal and a project stored inside the Linux file system. The Git commands themselves also apply to macOS and Linux. Windows PowerShell users can follow the same Git workflow, although paths and terminal setup will differ.
Version note: GitHub authentication screens, credential methods, and repository menus can change. Before publication, compare account and authentication steps with the current official Git and GitHub documentation.
What You Will Learn
By the end of this guide, you should be able to:
- check whether Git is installed;
- configure your Git author name and email;
- clone a GitHub repository;
- inspect the repository with
git status; - review file changes with
git diff; - stage a specific file with
git add; - create a commit with
git commit; - inspect recent history with
git log; - send commits to GitHub with
git push; - retrieve remote changes with
git pull; - recognize common beginner errors.
This article assumes that you already have:
- Visual Studio Code;
- WSL with a Linux distribution such as Ubuntu;
- the official VS Code support for WSL;
- a GitHub account;
- a GitHub repository containing a README.
The example repository name is:
vibe-coding-practice
Replace the username and repository name in examples with your own values.
Check Whether Git Is Installed
Open your WSL terminal.
You can use the standalone Linux terminal or the integrated terminal in a VS Code window connected to WSL.
Run:
git --version
A successful result should resemble:
git version 2.x.x
The exact version will differ.
This confirms that the git command is available inside the current Linux environment.
Remember that software installed on Windows is not automatically installed inside WSL. If Git works in PowerShell but not in the WSL terminal, you may need a separate Linux installation.
On an Ubuntu-based WSL environment, Git can commonly be installed with:
sudo apt update
sudo apt install git
The first command refreshes Ubuntu’s package information.
The second installs Git from the configured package repositories.
After installation, run the version check again:
git --version
Do not continue until the terminal recognizes the command.
Configure Your Git Identity
Every Git commit contains author information.
At minimum, Git needs:
- an author name;
- an author email address.
This information becomes part of the commit metadata.
Set your name with:
git config --global user.name "Your Name"
For example:
git config --global user.name "Alex Kim"
Set your email with:
git config --global user.email "your-email@example.com"
Use an email strategy that matches the privacy settings selected in your GitHub account.
If you chose a GitHub-provided no-reply address, use that exact address instead of your personal email.
The --global option applies the setting to repositories used by your current Linux account.
Check the values:
git config --global user.name
git config --global user.email
Git should print the configured name and email.
You can also review the complete global Git configuration:
git config --global --list
Do not publish terminal output containing private email addresses without reviewing it first.
Global Versus Repository-Specific Identity
A global identity applies broadly.
Some developers use a different identity for a specific project, such as a work repository.
Inside that repository, a local setting can be configured without --global:
git config user.name "Work Name"
git config user.email "work-email@example.com"
The repository-specific value overrides the global value for that repository.
For this personal tutorial project, the global configuration is sufficient.
Move to Your Projects Directory
In the earlier WSL guide, we created:
~/projects
Move into that directory:
cd ~/projects
Confirm the location:
pwd
The result should resemble:
/home/your-username/projects
List the existing folders:
ls
Before cloning, confirm that a folder with the same name as the GitHub repository does not already exist.
If vibe-coding-practice already exists, do not immediately delete it. Check whether it contains work you need.
Copy the Repository URL
Open your repository on GitHub.
Find the repository’s clone or code menu.
GitHub commonly offers more than one connection method, including HTTPS and SSH. This beginner tutorial uses HTTPS because it requires less initial key configuration.
Copy the HTTPS repository URL.
It should follow a pattern similar to:
https://github.com/your-username/vibe-coding-practice.git
Confirm that:
- the domain is GitHub;
- the username is correct;
- the repository name is correct;
- you are copying your intended repository.
Avoid pasting credentials, tokens, or private URLs into screenshots or public articles.
Clone the Repository
In the WSL terminal, run:
git clone https://github.com/your-username/vibe-coding-practice.git
Replace the example URL with the one copied from GitHub.
The clone command creates a local copy of the repository and its available Git history.
A successful result usually shows messages about:
- cloning into the repository folder;
- receiving objects;
- resolving files.
After the command completes, list the directory contents:
ls
You should now see:
vibe-coding-practice
Move into the repository:
cd vibe-coding-practice
Confirm the location:
pwd
The path should resemble:
/home/your-username/projects/vibe-coding-practice
List the files:
ls
You should see the files already stored on GitHub, such as:
README.md
Open the Repository in VS Code
From inside the repository folder, run:
code .
The period means the current directory.
VS Code should open the complete repository as a WSL workspace.
Verify the setup:
- the Explorer shows
vibe-coding-practice; - the lower-left connection indicator shows WSL;
- the integrated terminal opens in the repository folder;
README.md appears in the Explorer.
Inside the VS Code terminal, run:
pwd
The result should match the repository’s Linux path.
Then run:
git status
A clean newly cloned repository should normally display a message indicating that:
- you are on the default branch;
- the local branch is synchronized with its remote counterpart;
- there is nothing to commit;
- the working tree is clean.
The exact wording and branch name may differ.
Understand What Clone Configured
Cloning did more than copy files.
It also configured a connection to the GitHub repository.
Check the configured remote:
git remote -v
The output should show a remote named origin with a URL for fetching and pushing.
For example:
origin https://github.com/your-username/vibe-coding-practice.git (fetch)
origin https://github.com/your-username/vibe-coding-practice.git (push)
origin is the conventional name Git gives the remote repository created during cloning.
Check the current branch:
git branch --show-current
The command should print the active branch name.
You do not need to change branches in this tutorial.
Edit the README
Open README.md in VS Code.
Add a section such as:
## Local Git Practice
This repository is now connected to a local WSL development environment.
The current workflow includes:
- reviewing changes;
- staging selected files;
- creating small commits;
- pushing verified commits to GitHub.
Save the file.
At this point:
- the file is saved;
- Git detects a modification;
- no new commit exists yet;
- GitHub has not received the change.
Run:
git status
Git should report that README.md has been modified.
This is the working-directory state described in the previous article.
Review the Change Before Staging It
Before staging a file, inspect what changed.
Run:
git diff
Git should display the difference between the current working file and the version in the last commit.
Added lines are commonly marked with +.
Removed lines are commonly marked with -.
The output may use a terminal viewer. Press q to exit when necessary.
Review the diff and ask:
- Did only the intended file change?
- Is the new content correct?
- Did any private information enter the file?
- Did the editor alter unrelated formatting?
- Does the change belong in one commit?
This review habit becomes essential when AI tools begin editing multiple files.
Check a Specific File
To review only README.md, run:
git diff README.md
This is useful when several files have changed.
Stage the File with git add
Stage README.md:
git add README.md
This selects the current saved version of the file for the next commit.
Run:
git status
The file should now appear under a section similar to:
Changes to be committed
The change is staged, but it has not yet entered permanent commit history.
Review the Staged Version
Run:
git diff --staged
This displays the changes currently prepared for the next commit.
This review is different from plain git diff.
git diff shows unstaged working-directory changes.git diff --staged shows changes selected for the next commit.
For a small workflow, review the staged diff before every commit.
Be Careful with git add .
You may see tutorials use:
git add .
The period tells Git to stage changes under the current directory.
This is convenient, but it can also stage files you did not intend to include.
For beginners, staging specific files is often safer:
git add README.md
Use git add . only after checking git status and understanding every listed file.
Create the Commit
Create a commit with:
git commit -m "Document local Git practice workflow"
The -m option supplies the commit message directly.
A successful result should display information such as:
- the branch;
- an abbreviated commit identifier;
- the commit message;
- the number of files changed;
- the number of inserted or deleted lines.
Now run:
git status
The working tree should be clean again.
The change has been recorded in your local Git history.
It has not necessarily reached GitHub yet.
Inspect the Commit History
Run:
git log
Git will display commit information, including:
- commit identifiers;
- authors;
- dates;
- messages.
The newest commit should appear first.
Press q to leave the log viewer.
For a shorter format, run:
git log --oneline
The result may resemble:
8f3a21d Document local Git practice workflow
2bc45ef Update README with repository status
91d2a07 Initial commit
Each line represents one commit.
The short identifier can be used to reference a particular point in history.
Why the Commit Is Still Local
A commit records history inside your local repository.
Git does not automatically send the commit to GitHub.
This separation allows you to:
- work without an internet connection;
- create several commits before sharing;
- review local history;
- test changes before publishing them.
The next step is pushing the commit to the configured remote.
Push the Commit to GitHub
Run:
git push
Because the repository was cloned from GitHub, the current branch should already know which remote branch it tracks.
Git may ask you to authenticate.
Depending on the current GitHub and credential configuration, authentication may involve:
- a browser window;
- a credential manager;
- a personal access token;
- another currently supported sign-in method.
Do not enter your normal GitHub password into an authentication prompt unless the current official GitHub documentation explicitly requires that method. Git hosting authentication practices can change, and standard account passwords are not always accepted for Git operations.
Do not paste tokens into:
- source-code files;
- shell scripts;
- screenshots;
- AI prompts;
- public terminal logs.
After authentication, a successful push should show that Git sent the new commit to the remote repository.
Open the repository page on GitHub and refresh it.
You should see:
- the updated README;
- the new commit message;
- a newer repository history entry.
Your local and remote repositories are now synchronized.
Check Synchronization with git status
Return to the terminal and run:
git status
Git should report that the local branch is up to date with its remote tracking branch and that the working tree is clean.
You can also run:
git log --oneline
Compare the newest local commit with the latest commit displayed on GitHub.
The identifiers should refer to the same commit.
Make a Remote Change on GitHub
To practice retrieving remote changes, edit the README through GitHub’s web interface.
Add a small section:
## Remote Update
This line was added through the GitHub web editor.
Use a commit message such as:
Add remote update note
Commit the change through GitHub.
The GitHub repository now contains a commit that your local repository does not have.
Return to the WSL terminal.
Run:
git status
Git may still report a clean working tree because it has not yet checked the latest remote state.
A clean working tree means there are no uncommitted local file changes. It does not always mean the remote repository has no newer commits.
Retrieve the Remote Change with git pull
Run:
git pull
Git should contact the remote repository, download the new commit, and update the local branch.
For this simple case, the update should complete without a conflict because the local repository had no competing change.
Open README.md in VS Code.
The section added through GitHub should now appear locally.
Run:
git log --oneline
The remote commit should appear at the top of the local history.
Your local repository has caught up with GitHub.
The Complete Daily Workflow
A basic Git session can follow this sequence.
1. Enter the Repository
cd ~/projects/vibe-coding-practice
2. Retrieve Remote Changes
git pull
Pull before beginning when the repository may have changed elsewhere.
3. Inspect the Current State
git status
4. Edit and Save Files
Use VS Code or another editor.
5. Review the Changes
git diff
6. Stage Specific Files
git add README.md
7. Review the Staged Changes
git diff --staged
8. Create a Commit
git commit -m "Describe the completed change"
9. Verify the Repository
git status
git log --oneline
10. Push the Commit
git push
This workflow is compact, repeatable, and suitable for small AI-assisted tasks.
Common Git Problems
fatal: not a git repository
This means the current directory is not inside a Git repository.
Check your location:
pwd
List the files:
ls
Move into the cloned repository:
cd ~/projects/vibe-coding-practice
Then run:
git status
The Clone Folder Already Exists
Git may refuse to clone when a nonempty folder with the target name already exists.
Do not delete the folder blindly.
Check its contents:
ls -la ~/projects/vibe-coding-practice
Determine whether it is:
- an earlier clone;
- a manually created folder;
- a project containing uncommitted work.
If it is already the correct Git repository, enter it and run:
git status
Git Does Not Know Your Identity
A commit may fail if user.name or user.email is missing.
Configure them:
git config --global user.name "Your Name"
git config --global user.email "your-email@example.com"
Then try the commit again.
The Wrong Email Appears in the Commit
Check the current configuration:
git config user.email
git config --global user.email
A repository-specific value may override the global value.
Correct the configuration before creating future commits.
Changing author information in existing history is a separate task and should not be attempted casually in a beginner workflow.
git push Requests Authentication
Follow GitHub’s current approved authentication process.
Verify:
- you copied the correct repository URL;
- you are signed in to the intended GitHub account;
- your account has permission to push;
- your credential method is current;
- an expired token is not being reused.
Never publish authentication tokens.
git push Is Rejected Because the Remote Has New Work
This usually means GitHub contains commits that are not yet in your local branch.
Start with:
git pull
Read the output carefully.
If Git reports a conflict, do not repeatedly run random commands. Inspect which files conflict and resolve the differences deliberately.
Conflict resolution will be covered separately when the workflow requires it.
A File Does Not Appear in git status
The file may be:
- outside the repository;
- ignored by
.gitignore; - unchanged;
- saved under a different name;
- created in another environment or folder.
Check:
pwd
ls -la
git status
Also confirm that VS Code and the terminal are using the same project folder.
Too Many Files Were Staged
If you accidentally staged files, do not create the commit yet.
Review:
git status
Use a non-destructive unstaging command appropriate to the current Git version and repository state, then stage only the intended files.
For example, Git commonly supports:
git restore --staged filename
After unstaging, the file remains in the working directory. Its content is not deleted.
Verify the result with:
git status
The Terminal Shows a Long Screen of Output
Commands such as git log and git diff may open a pager.
Press:
q
to exit and return to the terminal prompt.
Practical Git Habits for AI-Assisted Development
Before asking an AI coding tool to modify a project, run:
git status
The cleanest starting point is a message indicating that the working tree is clean.
If uncommitted changes already exist, decide whether to:
- review and commit them;
- leave them intentionally;
- stage only part of them;
- postpone the AI task.
Do not ask a coding agent for a large change when you do not know what is already modified.
After the AI finishes:
git status
git diff
Review every changed file.
Then stage specific verified files:
git add path/to/file
Review again:
git diff --staged
Only then create the commit.
This process turns Git into a review boundary:
Known state
→ AI change
→ Inspect
→ Test
→ Stage
→ Commit
The goal is not to commit every AI output. The goal is to commit only the output you have verified.
Verify Your Git Workflow
Before moving to the next article, confirm that you can:
- run
git --version; - verify your Git name and email;
- clone a GitHub repository;
- open it in a WSL-connected VS Code window;
- use
git status; - edit and save
README.md; - inspect changes with
git diff; - stage the file with
git add; - inspect staged changes with
git diff --staged; - create a commit;
- inspect history with
git log --oneline; - push the commit to GitHub;
- retrieve a GitHub web edit with
git pull; - explain the difference between saving, staging, committing, and pushing.
The essential sequence is:
git status
git diff
git add README.md
git diff --staged
git commit -m "Describe the change"
git push
At the start of a later session, include:
git pull
Conclusion
The basic Git workflow moves changes through several deliberate stages.
git clone creates a local repository from GitHub. git status shows the current state. git diff reveals what changed. git add selects changes for the next checkpoint. git commit records that checkpoint locally. git push sends the commit to GitHub, while git pull retrieves remote changes.
The important lesson is not memorizing every command. It is understanding what state the project is in before and after each command.
That awareness becomes especially valuable when AI tools begin editing the repository. Before accepting generated code, you need a reliable way to see what changed, test it, and preserve only the result you trust.
The next article will introduce GitHub Copilot inside Visual Studio Code. We will install the official extension, review sign-in and subscription requirements, try small contextual tasks, and examine AI suggestions before accepting them.
Frequently Asked Questions
Should I use git add . or add files individually?
Adding files individually is safer for beginners because it makes the next commit more deliberate.
Use git add . only after reviewing git status and confirming that every listed change belongs in the commit.
Does git commit upload my code to GitHub?
No.
A commit records changes in the local repository. Use git push to send local commits to the connected GitHub repository.
Should I run git pull before every coding session?
It is a useful habit when the repository may have changed on GitHub, another computer, or through another collaborator.
Before pulling, check that you do not have confusing uncommitted local changes.
Comments
Post a Comment