Why workflow agreement matters in Git - Why It Works

Introduction

When a team works together on code, everyone needs to follow the same steps to avoid confusion and mistakes. Workflow agreement means agreeing on how to use Git so that changes fit well and the project stays organized.

When multiple developers are working on the same project and need to share code safely

When you want to avoid conflicts and lost work during code updates

When you want clear rules on how to add, review, and merge code changes

When you want to keep the project history clean and easy to understand

When onboarding new team members who need to follow the team's Git process

Commands

This command copies the project code from the shared repository to your local computer so you can start working on it.

Terminal

git clone https://github.com/example-org/my-app.git

Expected Output

Cloning into 'my-app'...

remote: Enumerating objects: 10, done.

remote: Counting objects: 100% (10/10), done.

remote: Compressing objects: 100% (8/8), done.

remote: Total 10 (delta 1), reused 10 (delta 1), pack-reused 0

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

Resolving deltas: 100% (1/1), done.

This creates a new branch called 'feature-login' where you can safely add your changes without affecting the main code.

Terminal

git checkout -b feature-login

Expected Output

Switched to a new branch 'feature-login'

→

-b - Creates and switches to a new branch in one step

This stages all your changed files, telling Git you want to include them in the next snapshot (commit).

Terminal

git add .

Expected Output

No output (command runs silently)

This saves your staged changes with a message describing what you did, making it easier to track history.

Terminal

git commit -m "Add login feature with validation"

Expected Output

[feature-login abc1234] Add login feature with validation

 3 files changed, 45 insertions(+), 2 deletions(-)

→

-m - Adds a commit message inline without opening an editor

This uploads your branch and commits to the shared repository so others can see and review your work.

Terminal

git push origin feature-login

Expected Output

Enumerating objects: 5, done.

Counting objects: 100% (5/5), done.

Delta compression using up to 4 threads

Compressing objects: 100% (3/3), done.

Writing objects: 100% (3/3), 1.23 KiB | 1.23 MiB/s, done.

Total 3 (delta 1), reused 0 (delta 0), pack-reused 0

remote: Resolving deltas: 100% (1/1), done.

To https://github.com/example-org/my-app.git

 * [new branch]      feature-login -> feature-login

Key Concept

If you remember nothing else from this pattern, remember: agreeing on a clear Git workflow keeps team work smooth and avoids lost or conflicting code.

Common Mistakes

Not creating a new branch and committing directly to main

This can cause conflicts and unstable code in the main project that affects everyone.

Always create a feature branch for your changes and only merge to main after review.

Pushing incomplete or broken code without testing

It can break the project for others and slow down progress.

Test your changes locally before committing and pushing.

Not pulling the latest changes before starting work

Your work may conflict with others' updates, causing merge problems.

Always pull the latest main branch before creating your feature branch.

Summary

Clone the shared repository to get the latest project code.

Create a new branch to work on your feature safely.

Stage and commit your changes with clear messages.

Push your branch to the shared repository for review and integration.

Practice

1. Why is having a workflow agreement important when using git in a team?

easy

A. It helps prevent conflicts and keeps the code organized.

B. It makes the code run faster on all machines.

C. It automatically fixes bugs in the code.

D. It allows unlimited access to the repository without rules.

Solution

1. Step 1: Understand the purpose of workflow agreement

   A workflow agreement sets clear rules for how team members use Git, helping avoid confusion.

2. Step 2: Identify the main benefit

   By following agreed rules, conflicts are reduced and code stays organized, improving teamwork.

3. Final Answer:

   It helps prevent conflicts and keeps the code organized. -> Option A

4. Quick Check:

   Workflow agreement = prevent conflicts and organize code [OK]

Hint: Workflow agreement = clear rules to avoid conflicts [OK]

Common Mistakes:

• Thinking workflow speeds up code execution
• Believing workflow fixes bugs automatically
• Assuming workflow removes access controls

2. Which of the following is the correct way to start a new branch following a team workflow?

easy

A. git branch -m feature/login

B. git checkout -b feature/login

C. git push origin feature/login

D. git merge feature/login

Solution

1. Step 1: Identify the command to create and switch to a new branch

   git checkout -b branch-name creates and switches to the new branch in one step.

2. Step 2: Check other options

   git branch -m renames a branch, git push uploads changes, and git merge combines branches.

3. Final Answer:

   git checkout -b feature/login -> Option B

4. Quick Check:

   Create and switch branch = git checkout -b [OK]

Hint: Create and switch branch with git checkout -b [OK]

Common Mistakes:

• Using git branch -m to create a branch
• Trying to push before creating the branch
• Merging before creating or switching branches

3. Given this team workflow: always pull before pushing. What will happen if you run these commands in order?

git push origin main
git pull origin main

medium

A. Pull will overwrite remote changes without warning.

B. Push will succeed even if remote has new commits.

C. Push and pull commands do nothing without commit.

D. Push will fail if remote has new commits; pull updates local branch.

Solution

1. Step 1: Understand push behavior when remote has new commits

   If remote has new commits, git push will be rejected to avoid overwriting others' work.

2. Step 2: Understand pull updates local branch

   git pull fetches and merges remote changes into local branch, updating it.

3. Final Answer:

   Push will fail if remote has new commits; pull updates local branch. -> Option D

4. Quick Check:

   Push fails if remote ahead; pull updates local [OK]

Hint: Always pull before push to avoid conflicts [OK]

Common Mistakes:

• Assuming push always succeeds
• Thinking pull overwrites remote
• Believing push/pull do nothing without commits

4. A team member forgot to pull before pushing and got this error:

! [rejected] main -> main (fetch first)

What should they do to fix this?

medium

A. Delete the local branch and create a new one.

B. Run git push --force to overwrite remote changes.

C. Run git pull origin main then resolve any conflicts before pushing again.

D. Ignore the error and try pushing again immediately.

Solution

1. Step 1: Understand the error meaning

   The error means remote has new commits; local branch is behind.

2. Step 2: Correct fix is to pull and merge changes

   Running git pull origin main updates local branch; conflicts can be resolved before pushing.

3. Final Answer:

   Run git pull origin main then resolve any conflicts before pushing again. -> Option C

4. Quick Check:

   Pull first to sync before push [OK]

Hint: Pull and fix conflicts before pushing [OK]

Common Mistakes:

• Using git push --force without caution
• Deleting branches unnecessarily
• Ignoring errors and retrying push

5. Your team agreed on a workflow where all feature branches must be reviewed before merging into main. Which Git command sequence best supports this workflow?

hard

A. Create feature branch, push to remote, open pull request, merge after approval.

B. Commit directly to main branch without branches or reviews.

C. Merge feature branch locally and push to main without review.

D. Delete main branch and work only on feature branches.

Solution

1. Step 1: Identify workflow steps for review

   Creating a feature branch and pushing it allows others to review changes before merging.

2. Step 2: Use pull requests for review and controlled merging

   Opening a pull request enables team review; merging happens only after approval.

3. Final Answer:

   Create feature branch, push to remote, open pull request, merge after approval. -> Option A

4. Quick Check:

   Feature branch + PR + review = safe merge [OK]

Hint: Use pull requests for review before merging [OK]

Common Mistakes:

• Committing directly to main branch
• Merging without review
• Deleting main branch accidentally