DevOps

Basic Git Workflow Cheatsheet

Complete beginner-friendly guide to basic Git workflow including the four Git areas, essential commands (init, add, commit, push, pull, fetch), and practical workflow examples for daily development.

Perfect for developers managing projects on VPS servers and collaborating remotely.

#git #workflow #version-control #beginner #tutorial #github

Free account required

1. What is Git Workflow? 2. The Four Areas of Git 3. Initializing a Repository 4. Working Directory → Staging Area 5. Staging → Local Repository 6. Local → Remote Repository 7. Remote → Local Repository 8. Complete Workflow Example 9. Common Workflow Patterns 10. Best Practices

What is Git Workflow?

A Git workflow is the process of how you use Git to accomplish your work. It defines how changes move through different stages from your local files to remote repositories shared with your team.

Understanding the basic Git workflow is essential for effective version control. It helps you track changes, collaborate with others, and maintain a clean project history. Whether you're deploying applications to a VPS provider or collaborating with a distributed team, mastering Git workflow is essential for modern development.

💡 Key Concept: Git workflow revolves around four main areas where your code can exist, and understanding how to move code between these areas is fundamental to mastering Git.

The Four Areas of Git

Git workflow involves moving your code through four distinct areas. Each area serves a specific purpose in the version control process:

1 Working Directory

Your local filesystem where you create, edit, and delete files. This is where you do all your actual coding work. Changes here are not tracked by Git until you stage them.

2 Staging Area (Index)

A preparation area where you group changes before committing. Think of it as a "draft" of your next commit. You can selectively add changes here using git add.

3 Local Repository

Your local Git database stored in the .git folder. When you commit, staged changes are permanently recorded here with a unique identifier (commit hash).

4 Remote Repository

A Git repository hosted on a server (GitHub, GitLab, Bitbucket). This is where you share your code with others and collaborate. Push your commits here and pull others' changes. Common remote hosting services run on powerful server infrastructure—learn more about VPS performance that powers development platforms.

Initializing a Repository

Before you can start tracking changes, you need to initialize a Git repository. This creates the necessary Git infrastructure in your project.

Initialize a new Git repository in your project directory

$ git init

Creates a hidden .git folder that stores all Git metadata and history.

Clone an existing repository from a remote URL

$ git clone https://github.com/username/repository.git

Downloads the entire repository history and creates a working directory.

Working Directory → Staging Area

After making changes in your working directory, you need to stage them before committing. Staging allows you to selectively choose which changes to include in your next commit.

Stage a specific file

$ git add file.txt

Adds the specified file to the staging area.

Stage multiple files

$ git add file1.txt file2.txt file3.txt

Stage multiple specific files at once.

Stage all changes in the current directory

$ git add .

Stages all modified, new, and deleted files in the current directory and subdirectories.

Stage all changes in the entire repository

$ git add -A

Stages all changes from the repository root, including deletions.

Interactively stage changes (patch mode)

$ git add -p

Allows you to review and stage changes chunk by chunk - useful for staging only parts of a file.

Check the status of your working directory and staging area

$ git status

Shows which files are modified, staged, or untracked.

Staging Area → Local Repository

Once you've staged your changes, you commit them to your local repository. A commit creates a snapshot of your staged changes with a unique identifier and commit message.

Commit staged changes with a message

$ git commit -m "Update login functionality"

Creates a commit with a descriptive message. Always write clear, meaningful commit messages.

Commit with a detailed multi-line message

$ git commit

Opens your default text editor for writing a longer, more detailed commit message.

Stage and commit all tracked modified files in one command

$ git commit -am "Fix navigation bug"

Combines git add and git commit for tracked files (doesn't work for new files).

Amend the last commit (add changes or edit message)

$ git commit --amend -m "Updated commit message"

Modifies the most recent commit. Useful for fixing typos or adding forgotten files.

⚠️ Best Practice: Write clear, descriptive commit messages that explain WHAT changed and WHY. Use present tense (e.g., "Add feature" not "Added feature"). Keep the first line under 50 characters.

Local Repository → Remote Repository

After committing changes to your local repository, you push them to a remote repository to share with your team or backup your work.

Add a remote repository

$ git remote add origin https://github.com/username/repository.git

Links your local repository to a remote one. "origin" is the conventional name for your main remote.

Push commits to remote repository

$ git push origin main

Uploads your local commits to the "main" branch on the remote repository.

Push and set upstream branch (first time)

$ git push -u origin main

The -u flag sets up tracking, so future pushes can use just git push.

Push to remote with tracking branch already set

$ git push

Simplified push command after upstream is configured.

Push all local branches to remote

$ git push --all origin

Uploads all your local branches to the remote repository.

Remote Repository → Local Repository

To synchronize your local repository with changes from the remote (made by you on another machine or by collaborators), you use fetch and pull commands.

Fetch changes from remote (doesn't merge)

$ git fetch origin

Downloads commits, files, and refs from remote but doesn't merge them into your working directory. Safe operation for reviewing changes first.

Pull changes from remote (fetch + merge)

$ git pull origin main

Downloads and automatically merges remote changes into your current branch. Equivalent to git fetch followed by git merge.

Pull with tracking branch already set

$ git pull

Simplified pull from the tracked upstream branch.

Pull with rebase instead of merge

$ git pull --rebase origin main

Applies your local commits on top of the remote commits, creating a cleaner linear history.

Fetch vs Pull - What's the difference?

git fetch: Downloads changes but leaves your working directory unchanged. Safe for reviewing what others have done.
git pull: Downloads and immediately merges changes into your current branch. Quick but can lead to unexpected merge conflicts.

Complete Workflow Example

Here's a complete example showing a typical daily Git workflow from start to finish:

Scenario: Adding a new feature to a project

Step 1: Initialize or clone repository

# Clone an existing repository
$ git clone https://github.com/username/myproject.git
$ cd myproject

Step 2: Check current status and pull latest changes

$ git status
$ git pull origin main

Step 3: Make changes to files in working directory

# Edit files using your text editor
# Create new file: feature.js
# Modify existing file: index.html

Step 4: Check what changed

$ git status
$ git diff

Step 5: Stage your changes

$ git add feature.js
$ git add index.html
# Or stage all changes at once
$ git add .

Step 6: Commit changes to local repository

$ git commit -m "Add new feature for user authentication"

Step 7: Push to remote repository

$ git push origin main

✅ Success! Your changes are now in the remote repository and available to your team.

Common Workflow Patterns

Here are some common Git workflow patterns you'll use frequently:

Daily Development Workflow

# Start of day - get latest changes
$ git pull

# Work on your code...
# Edit, create, delete files

# Stage and commit
$ git add .
$ git commit -m "Implement feature X"

# Push to remote
$ git push

Working on a Feature Branch

# Create and switch to new branch
$ git checkout -b feature/new-login

# Work on feature, stage and commit
$ git add .
$ git commit -m "Add new login page"

# Push feature branch to remote
$ git push -u origin feature/new-login

# After review, merge to main
$ git checkout main
$ git merge feature/new-login
$ git push

Quick Fix Workflow

# Make quick changes to tracked files
# Stage and commit in one command
$ git commit -am "Fix typo in homepage"

# Push immediately
$ git push

Checking Before Committing

# Check what changed
$ git status

# Review specific changes
$ git diff

# Stage selectively
$ git add specific-file.js

# Review staged changes
$ git diff --staged

# Commit
$ git commit -m "Update validation logic"

Best Practices

Follow these best practices to maintain a clean Git workflow:

Commit Often

Make small, focused commits frequently. It's easier to understand and revert small changes than large ones.

Write Clear Messages

Use descriptive commit messages. Explain what and why, not how. Use imperative mood: "Add feature" not "Added feature".

Pull Before Push

Always pull the latest changes before pushing to avoid conflicts and merge issues.

Review Before Staging

Use git status and git diff to review changes before staging.

Use .gitignore

Don't commit temporary files, build artifacts, or sensitive data. Use .gitignore to exclude them.

Use Branches

Create branches for new features or experiments. Keep main branch stable and deployable.

Research Before Committing

Just like comparing VPS providers, research and test before making major Git workflow decisions.

⚠️ Things to Avoid

Don't commit directly to main if you're working in a team
Never commit sensitive data (passwords, API keys, tokens)
Avoid large commits with unrelated changes
Don't use vague commit messages like "fix" or "update"
Don't force push to shared branches

Compare VPS Performance with Real Benchmarks

Discover the best VPS hosting providers with our comprehensive benchmark database. Compare CPU, disk I/O, and network performance across hundreds of providers.

View Benchmarks More Cheatsheets