Basic Feature Development Flow with GitHub

When developing with GitHub, you usually do not edit the main branch directly. You create a working branch, make changes, commit them, push the branch to GitHub, open a Pull Request (PR), receive review, and then merge the approved change into main.

This page uses a small feature, adding a bio field to a profile page, to explain the full flow from branch creation to PR merge.

What You Will Learn

• The difference between local branches and remote branches
• How to name branches
• The flow of implementation, staging, commits, and push
• How to create a PR, respond to review, and merge into main
• Basic commands to check when you get lost

Overall Flow

A basic GitHub feature development flow looks like this:

Update main
  ↓
Create a working branch
  ↓
Develop or modify the feature
  ↓
Stage the changes
  ↓
Commit the changes
  ↓
Push to a remote branch
  ↓
Create a Pull Request
  ↓
Receive review and make fixes
  ↓
Merge into main after approval

The purpose of this flow is to avoid putting unreviewed changes directly into main. By separating work in progress, reviewing it, and running checks before merging, the team can understand both the intent and quality of each change.

Local Branches and Remote Branches

Branches can exist on your computer or on GitHub.

Type	Location	Role
Local branch	Your computer	Where you implement and edit code
Remote branch	GitHub	Where you share the work and create a PR

For example, if you create a branch named feature/add-profile-bio on your machine, that branch does not yet exist on GitHub. It appears on GitHub only after you push it.

git checkout -b feature/add-profile-bio
git push -u origin feature/add-profile-bio

The -u option connects your local branch to the remote branch. After that, you can usually push future changes with just git push.

Step 1: Update main

Before starting work, update your local main branch. If you create a branch from an old version of main, conflicts are more likely later.

git checkout main
git pull origin main

At this point, your local main should match the main branch on GitHub.

git pull fetches remote changes and applies them to your current branch. In team development, someone else may have merged changes before you start, so this is a useful habit.

Step 2: Create a Working Branch

Next, create a branch for this feature.

git checkout -b feature/add-profile-bio

git checkout -b creates a new branch and switches to it.

How to Name Branches

A branch name should make the purpose of the work clear.

feature/add-profile-bio
fix/profile-bio-validation
docs/update-github-flow-guide
refactor/profile-form

Common prefixes include:

Prefix	Use	Example
feature/	Add a new feature	feature/add-search
fix/	Fix a bug	fix/login-error
docs/	Change documentation	docs/update-readme
refactor/	Restructure code without changing behavior	refactor/profile-form
chore/	Maintenance or configuration work	chore/update-dependencies

If there is an Issue number, include it in the branch name:

feature/42-add-profile-bio

Short names using lowercase letters and hyphens are usually easiest to handle.

Step 3: Develop or Modify the Feature

Edit code on the working branch.

In this example, the change adds a bio field to a profile page.

Example changes:
- Add a bio input field to the profile form
- Add maximum length validation
- Show the saved bio on the profile page

While working, check the repository state often:

git status

git status shows changed files, staged files, and untracked files.

Step 4: Stage the Changes

Before committing, choose which changes should be included in the next commit. This is called staging.

git add src/components/ProfileForm.tsx
git add src/pages/profile.tsx

You can also stage everything at once:

git add .

For beginners, it is better to run git status before git add . so you can confirm that temporary files or unrelated changes are not included.

Think of staging as selecting the changes that go into the next commit. Editing a file does not automatically mean that Git will include it in a commit.

Step 5: Commit the Changes

Commit the staged changes as a saved point in history.

git commit -m "feat(profile): add bio field"

A commit is not only a save point. It is a record that explains what changed and why. The message can be short, but it should make the change understandable.

Commit Message Examples

feat(profile): add bio field
fix(profile): validate bio length
test(profile): add bio form tests
docs(git): update pull request workflow

If the work is large, do not put everything into one commit. Split it into meaningful units.

git add src/components/ProfileForm.tsx
git commit -m "feat(profile): add bio input"

git add src/lib/validation.ts
git commit -m "fix(profile): validate bio length"

This makes review easier because each commit has a clear purpose.

Step 6: Push to a Remote Branch

After committing locally, the change still exists only on your computer. To create a PR on GitHub, push the working branch to the remote repository.

git push -u origin feature/add-profile-bio

After the first push, later pushes can usually be:

git push

Once pushed, GitHub has a remote branch named feature/add-profile-bio. The repository page may show a “Compare & pull request” button.

Step 7: Create a Pull Request

A Pull Request means: “Please review this branch before it is merged into main.”

When creating a PR, make these points clear:

Item	What to Write
Title	What changed
Summary	Main points of the change
Reason	Why the change is needed
Verification	How you checked the behavior
Related Issue	The Issue number, if any

Example PR description:

## Changes
- Added a bio field to the profile page
- Added maximum length validation for the bio

## Reason
This allows users to show a short introduction on their profile.

## Verification
- Confirmed that a bio can be entered on the profile page
- Confirmed that the saved bio is displayed
- Confirmed that an error appears when the text exceeds the length limit

## Related Issue
Closes #42

If you write Closes #42, GitHub closes Issue #42 automatically when the PR is merged into main.

Step 8: Receive PR Review

After creating a PR, ask a reviewer to check it. Reviews usually focus on:

- Whether the change satisfies the requirement
- Whether existing behavior is affected
- Whether the code is readable
- Whether tests or manual checks are sufficient
- Whether there are security or permission concerns

A GitHub PR usually has these tabs:

Tab	What You See
Conversation	PR description, comments, and review results
Commits	Commits included in the branch
Checks	Automated tests and lint results
Files changed	Code diff

Even when reviewing your own work, start with Files changed. Reading the diff helps catch unrelated changes, debug logs, and leftover comments.

Step 9: Address Review Comments

If a reviewer requests changes, edit the same local branch.

# Confirm that you are on feature/add-profile-bio
git branch

# After editing files
git status
git add src/components/ProfileForm.tsx
git commit -m "fix(profile): handle empty bio"
git push

Pushing to the same branch updates the existing PR automatically. You do not need to create a new PR.

After fixing the comments, reply where needed and resolve completed conversations so the reviewer can check the remaining items easily.

Step 10: Merge the PR into main

After approval and required checks pass, merge the PR into main.

GitHub commonly offers these merge methods:

Method	Behavior
Merge commit	Keeps the branch commits and creates a merge commit
Squash and merge	Combines the branch commits into one commit
Rebase and merge	Replays commits into a linear history

For beginner teams, Squash and merge is often the easiest starting point. It keeps small work-in-progress commits out of main and makes one feature appear as one clear history entry.

After merging, delete the remote working branch on GitHub.

Delete branch

If the local branch is no longer needed, update main and delete it locally:

git checkout main
git pull origin main
git branch -d feature/add-profile-bio

The feature development flow is complete.

Common Commands

Goal	Command
Switch to main	git checkout main
Update main	git pull origin main
Create a branch	git checkout -b feature/add-profile-bio
Check status	git status
Stage changes	git add <file>
Commit changes	git commit -m "feat: add profile bio"
Push to remote	git push -u origin feature/add-profile-bio
Push after the first time	git push
List local branches	git branch
List remote branches too	git branch -a
Delete a merged local branch	git branch -d feature/add-profile-bio

What to Check When You Get Lost

When you feel lost in the GitHub workflow, check these five points:

1. Which branch am I on?
2. Which files did I change?
3. Are those changes staged?
4. Did I create a commit?
5. Did I push that commit to GitHub?

The basic commands for this are git status and git branch. When something is unclear, checking these two commands first usually makes the situation easier to understand.

Summary

GitHub feature development usually follows this order: update main, create a working branch, implement the change, stage it, commit it, push it, open a PR, receive review, and merge it.

The important point is not memorizing every command. It is understanding whether your change is still local, already pushed to GitHub, or ready for review in a PR.

Start with a small feature. Once you move one change through the full flow, Git and GitHub terms become much easier to connect to real work.

See the references for the external specifications and background sources used on this page.[1][2]

References

1. Git, Reference
2. GitHub, GitHub Docs