Git Workflow for Beginners

A visual, beginner-friendly guide to cloning a repo, working on a branch, opening a pull request, merging safely, and dealing with simple conflicts.

3/23/2026

Beginner friendlyVisual walkthroughSafer shipping

The simple version

Clone the repo, make your change on a branch, open a PR, get it checked, then merge safely.

That really is the whole thing. Git gives you some breathing room. You can make a change, check it, and only bring it back into the shared codebase once it has had a proper look from people and from the usual automation.

Why Git

You can experiment without breaking everyone else's work.

Why branches

Each change stays isolated until the team is happy with it.

Why PRs

Reviews, tests, scans, and AI comments can all happen before merge.

Workflow snapshot

+1. Clone the repo

+2. Create or switch to your branch

+3. Make the change

+4. Commit and push

+5. Open a pull request

+6. Review, fix, merge

If you are new to Git, this is the mindset shift that helps most:

You are not editing the shared codebase directly.

You are making a safe copy of the current state, doing your work on your own branch, and only asking to merge it back once it has been checked.

Why teams work this way

Without a process

People can overwrite each other.
It is harder to understand what changed and why.
Risky code can land without review.
There is no obvious pause for tests, scans, or discussion.

With branches and PRs

Changes are isolated until they are ready.
Teammates can review the diff and suggest fixes.
Automated checks can run before merge.
Extra review layers such as CodeRabbit or Devin-style PR review can join the process too.

That is why PRs matter. They are not just some GitHub ceremony people go through because "that is the process." They are the handoff point between "I changed something" and "this now belongs in the main codebase."

The workflow at a glance

flowchart LR
  A["Clone repo"] --> B["Create branch"]
  B --> C["Make changes"]
  C --> D["Commit + push"]
  D --> E["Open PR"]
  E --> F["Review + checks"]
  F --> G["Merge"]
  F --> H["Fix feedback"]
  H --> D

Step 1: Clone the repo

This gives you a local copy of the project on your machine.

Step 1

Clone the repository

$git clone https://github.com/your-team/project-name.git

$cd project-name

Cloning into 'project-name'...

remote: Enumerating objects: 428, done.

Receiving objects: 100% (428/428), done.

You only need to clone a repo once per machine. After that, you just pull the latest changes.

At this point, nothing fancy has happened. You just have the project on your machine.

Step 2: Switch to a branch for your work

Branches let you work on your own copy of the code history without disturbing main.

Step 2

Create a branch for your change

$git switch -c fix-homepage-cta

Switched to a new branch 'fix-homepage-cta'

$git status

On branch fix-homepage-cta

nothing to commit, working tree clean

Why branch first?

Your work stays separate from the shared branch.
If you make a mess, the mess stays on your branch.
When you open a PR, GitHub can compare your branch against main clearly.

Branch names are usually short descriptions of the work, for example `fix-login-copy` or `add-pricing-faq`.

If your team already made changes since you last synced, pull the latest main before you begin.

Step 3: Make your change and save it

Now you do the actual work: edit files, test locally, and check what changed.

Step 3

Work locally and inspect the change

Your loop

Edit the file.
Refresh the app or run the relevant command.
Check that the change behaves the way you expected.
Run git status to see what Git noticed.

$git status

On branch fix-homepage-cta

Changes not staged for commit:

modified: src/components/hero.tsx

modified: src/app/globals.css

Run your app or tests here if the project has them. The goal is to catch obvious mistakes before you involve the rest of the team.

This part is a bit boring, and honestly that is good. Most healthy Git workflows are made up of small, understandable changes.

Step 4: Commit and push your branch

A commit is a saved checkpoint with a message explaining what changed.

Step 4

Save a checkpoint, then push it to GitHub

$git add src/components/hero.tsx src/app/globals.css

$git commit -m "Improve homepage CTA clarity"

[fix-homepage-cta 8d21f7a] Improve homepage CTA clarity

$git push -u origin fix-homepage-cta

Branch 'fix-homepage-cta' set up to track 'origin/fix-homepage-cta'.

Think of commits as named save points. The PR is the conversation around those save points.

Once the branch is pushed, GitHub has something to compare against main.

Step 5: Raise a pull request

This is the review stage. You are basically saying, "Here is my branch. Can someone compare it with main and tell me if this is ready to merge?"

Step 5

What a healthy pull request is doing for you

2 approvalsCI checks passingSecurity scan completeCode review notes addressed

PR title

Improve homepage CTA clarity

Reviewers

Teammates check the code, the screenshots, and the reasoning.

Automation

Tests, linting, scans, and AI review tools can all comment here.

Why PRs help

Someone else can spot bugs or edge cases you missed.
Automated checks can block obvious breakage.
Security and code scanning tools get a defined place to run.
AI review tools can highlight risky diff patterns early.
The team gets a clear record of why the change happened.

The PR is where process protects the codebase: reviews, tests, scans, and discussion all happen before merge.

Examples of checks around a PR:

a teammate reading the diff
automated tests and linting
security scanning
code quality tools
AI review systems such as CodeRabbit or Devin-style PR review interfaces

The exact tools vary from team to team, but the point stays the same. The PR is the safety checkpoint.

GitHub Desktop is genuinely useful

If you do not enjoy the command line, that is fine. A lot of people find GitHub Desktop much easier when they are getting started.

It is especially helpful for:

seeing changed files without memorising commands
reviewing diffs in a calmer way
creating branches without worrying about syntax
committing and pushing without hopping between tabs
resolving simple conflicts with a more guided interface

The CLI is still worth learning over time because it gives you the most flexibility. But you do not need to prove terminal toughness to work well with Git. If GitHub Desktop helps you stay consistent and less stressed, use it.

You can automate a lot of this with agents

This is the part that has changed a lot recently.

If you give an agent access to git and the gh CLI, a big chunk of the mechanics can be handled for you:

creating or switching branches
checking git status
staging and committing changes
pushing the branch
opening a PR with gh pr create
checking comments, reviews, and CI status with gh pr view

That does not mean "let the agent merge anything it wants." The useful pattern is usually:

let the agent handle the repetitive Git and GitHub steps
let humans review the actual change
keep merge permission and final judgment in the loop unless you really trust the automation

In practice this means the annoying parts can be mostly automated while the important decision-making still gets a proper review.

If you work this way, Git starts to feel less like a chore and more like a shared log of what changed, why, and what still needs a second pair of eyes.

Step 6: Merge the PR

Once the reviews are complete and the checks are green, the PR can be merged into main.

Step 6

Merge when the branch is ready

Before merge

Make sure the PR is targeting the correct base branch and all required checks passed.

At merge

GitHub combines your branch into main, preserving the review history and discussion.

After merge

Pull the latest main locally before starting your next piece of work.

After merge, many teams delete the branch because the work is now part of the shared history.

What about merge conflicts?

Conflicts happen when Git cannot safely combine two sets of edits by itself.

It sounds worse than it usually is. The basic version is normally this:

you changed a line
someone else changed the same line
Git needs a human to decide which version should win

Conflicts

How a simple conflict looks

<<<<<<< HEAD
<button>Start free trial</button>
=======
<button>Book a demo</button>
>>>>>>> origin/main

What this means

HEAD is your version.
origin/main is the incoming version.
You pick the right final text, then delete the conflict markers.

The only real job here is to decide what the final content should be, then mark the conflict as resolved.

A simple conflict-fix flow

Conflict fix

Resolve, test, continue

$git fetch origin

$git merge origin/main

Auto-merging src/components/hero.tsx

CONFLICT (content): Merge conflict in src/components/hero.tsx

1. Open the file and remove the conflict markers.

2. Keep the final version you actually want.

3. Test the result.

$git add src/components/hero.tsx

$git commit

If you are unsure which version is correct, stop and ask. Guessing is worse than pausing.

If your team prefers rebasing instead of merging, the commands will look a bit different. The beginner-friendly idea stays the same: bring in the latest shared work, fix the conflicting file, then keep going.

The cheat sheet

Goal	Command or action
Clone the repo	`git clone <repo-url>`
Enter the project	`cd <repo-folder>`
Create and switch branch	`git switch -c <branch-name>`
See what changed	`git status`
Stage files	`git add <files>`
Save a checkpoint	`git commit -m "message"`
Push branch to GitHub	`git push -u origin <branch-name>`
Open PR	Usually done in GitHub after pushing
Bring in latest `main`	`git fetch origin` then `git merge origin/main`

Final takeaway

Git is not there to make life harder. It is there to stop a shared codebase from turning into guesswork.

The shape is simple:

Clone the repo.
Create a branch.
Make your change.
Commit and push.
Open a PR.
Let people and tools check it.
Merge when it is ready.

That little bit of process is what lets teams move quickly without turning the codebase into chaos.