The Step-by-Step Workflow Before Pushing Code

Before pushing code to the remote repository, it's important to follow a structured workflow to ensure your code is tested, synchronized, and ready for review.

Following these steps helps reduce merge conflicts, improve code quality, and maintain a clean Git history.

Interview Answer

"Before pushing my changes to the remote repository, I follow a standard workflow: I verify I'm on the correct branch, pull the latest changes, run the application and tests locally, review my changes using git status and git diff, create a meaningful commit, rebase or merge with the latest base branch if required, run tests again, push the branch, and finally create a Pull Request for code review."

Advertisement

Step-by-Step Workflow

Step 1: Verify the Current Branch

Ensure you're working on the correct feature branch.

git branch

Example:

* feature/login-form

Step 2: Pull the Latest Changes

Synchronize your branch with the latest changes from the base branch.

git pull origin main

or

git pull origin develop

This helps avoid merge conflicts later.

Step 3: Run the Application and Tests

Before pushing, verify that:

• The project builds successfully.
• The application runs correctly.
• All unit and automation tests pass.

Step 4: Review Your Changes

Check which files have changed.

git status

Review the actual code modifications.

git diff

Ensure only the intended files are included.

Step 5: Stage and Commit the Changes

Stage the files.

git add .

Create a meaningful commit.

git commit -m "Added login validation - JIRA-123"

Use descriptive commit messages that clearly explain the purpose of the change.

Step 6: Rebase or Merge (Optional)

Update your branch with the latest changes from the base branch.

Using rebase:

git fetch origin

git rebase origin/main

Or using merge:

git merge origin/main

Choose the approach based on your team's Git workflow.

Step 7: Run Tests Again

After merging or rebasing:

• Build the project.
• Execute the test suite.
• Verify that no new issues were introduced.

Step 8: Push the Branch

Push your changes to the remote repository.

git push origin feature/login-form

Step 9: Create a Pull Request

Create a Pull Request in GitHub, GitLab, or Bitbucket.

Include:

• Clear title
• Description
• Jira ticket
• Reviewers

Complete Workflow

Verify Branch
      │
      ▼
Pull Latest Changes
      │
      ▼
Run Tests
      │
      ▼
Review Changes
      │
      ▼
Commit Code
      │
      ▼
Rebase/Merge
      │
      ▼
Run Tests Again
      │
      ▼
Push Branch
      │
      ▼
Create Pull Request

Benefits

Following this workflow:

• Prevents merge conflicts
• Reduces bugs
• Ensures tested code
• Maintains clean Git history
• Improves collaboration
• Simplifies code reviews

Real-Time Example

Before pushing my feature branch, I first synchronize it with the latest develop branch, execute the complete automation test suite, review the modified files using git diff, create a meaningful commit, push the branch, and raise a Pull Request. This helps ensure only tested and reviewed code reaches the shared repository.

Accidentally Committed to the Wrong Branch

Sometimes a commit is accidentally created on the wrong branch.

The recovery approach depends on whether the changes are committed or uncommitted.

Interview Answer

"If I accidentally commit to the wrong branch, I move the commit to the correct branch using git cherry-pick, then remove it from the wrong branch using git reset. If the changes are still uncommitted, I use git stash to move them safely."

Scenario 1: Commit Not Yet Pushed

Step 1: Switch to the Correct Branch

git checkout correct-branch

Step 2: Copy the Commit

git cherry-pick <commit-hash>

Step 3: Return to the Wrong Branch

git checkout wrong-branch

Step 4: Remove the Commit

git reset --hard HEAD~1

Scenario 2: Changes Not Yet Committed

Save the changes.

git stash

Switch branches.

git checkout correct-branch

Restore the changes.

git stash pop

Scenario 3: Already Pushed

If the commit has already been pushed:

• Cherry-pick it onto the correct branch.
• Carefully clean up the wrong branch.
• Use force push only if it is safe and permitted.

Workflow

Wrong Branch
      │
      ▼
Cherry-Pick Commit
      │
      ▼
Correct Branch
      │
      ▼
Reset Wrong Branch

Real-Time Example

During development, I accidentally committed an API automation change to the wrong feature branch. I used git cherry-pick to move the commit to the correct branch and removed it from the incorrect branch using git reset. Since the commit had not been pushed, no other developers were affected.

Moving Changes from One Branch to Another

The approach depends on whether the changes are already committed.

Interview Answer

"For committed changes, I use git cherry-pick to apply the commit to another branch. For uncommitted changes, I use git stash, switch branches, and restore the changes using git stash pop."

Committed Changes

Switch to the destination branch.

git checkout target-branch

Copy the commit.

git cherry-pick <commit-hash>

Uncommitted Changes

Save the changes.

git stash

Switch branches.

git checkout target-branch

Restore them.

git stash pop

Workflow

Committed?
     │
 ┌───┴────┐
 │        │
Yes      No
 │        │
Cherry   Stash
Pick     Pop

Benefits

• No duplicate work
• Preserves commit history
• Safely moves changes
• Avoids manual copying

git push Fails Due to Non-Fast-Forward Updates

A Non-Fast-Forward error occurs when the remote branch contains commits that are missing from your local branch.

Git blocks the push to prevent overwriting someone else's work.

Interview Answer

"When I encounter a non-fast-forward error, I first pull the latest changes, resolve any merge conflicts, verify the application and tests, and then push again. I avoid force pushing unless I'm working on my own feature branch and rewriting history is intentional."

Why Does It Happen?

Another developer pushed changes before you.

Your local branch is behind the remote branch.

Solution

Pull the latest changes.

git pull origin branch-name

Resolve merge conflicts if necessary.

Run tests.

Push again.

git push origin branch-name

Using Rebase

git pull --rebase origin branch-name

This keeps the history cleaner.

Important

Avoid using:

git push --force

on shared branches.

Use it only when:

• Working on a private feature branch.
• Your team approves rewriting history.

Workflow

Push
 │
 ▼
Rejected
 │
 ▼
Pull Latest Changes
 │
 ▼
Resolve Conflicts
 │
 ▼
Run Tests
 │
 ▼
Push Again

Your Code Is Broken After a Pull

Sometimes the application stops working after pulling the latest changes.

The goal is to identify what changed and resolve the issue systematically.

Interview Answer

"If my code breaks after a pull, I inspect the recent commits using git log, compare changes using git diff, verify merge conflict resolution, execute the build and test suite, and if necessary, collaborate with the teammate who introduced the changes."

Step-by-Step Approach

Review Recent Commits

git log

Compare Changes

git diff

or

git show

Verify Merge Conflicts

Check whether conflicts were resolved correctly.

Build the Project

Compile and execute the application.

Run the Test Suite

Identify failing tests.

Collaborate

If required, discuss the changes with the teammate who introduced them.

Troubleshooting Workflow

Pull Latest Code
        │
        ▼
Build Fails?
        │
        ▼
Check Logs
        │
        ▼
Review Diff
        │
        ▼
Resolve Issues
        │
        ▼
Run Tests

Precautions Before Merging

Before merging any branch into the target branch, verify that the changes are ready.

Interview Answer

"Before merging, I ensure my branch is synchronized with the latest base branch, resolve any conflicts, execute all tests successfully, review my changes, and submit the code through a Pull Request for peer review."

Best Practices

• Pull the latest changes.
• Synchronize with the base branch.
• Resolve merge conflicts carefully.
• Run all tests.
• Review the code using git diff.
• Follow coding standards.
• Obtain Pull Request approval before merging.

Benefits

These precautions:

• Reduce bugs
• Prevent merge issues
• Improve code quality
• Keep the main branch stable

Working with a Team Using Git

Git enables multiple developers to collaborate efficiently through branch-based development.

Interview Answer

"In a team environment, every developer works on a separate feature branch, commits meaningful changes regularly, synchronizes frequently with the base branch, pushes the feature branch, and raises a Pull Request for review before merging. This keeps the repository organized and prevents conflicts."

Team Workflow

Create Feature Branch
        │
        ▼
Develop Feature
        │
        ▼
Commit Changes
        │
        ▼
Pull Latest Changes
        │
        ▼
Push Branch
        │
        ▼
Create Pull Request
        │
        ▼
Code Review
        │
        ▼
Merge

Benefits

Working this way:

• Prevents overwriting teammates' work
• Improves collaboration
• Maintains clean Git history
• Encourages code reviews
• Ensures tested code reaches the shared branch

Real-Time Example

In our Scrum team, every developer worked on a dedicated feature branch. Before merging, each developer synchronized with the latest develop branch, resolved conflicts, executed automated tests, and submitted a Pull Request for peer review. This workflow helped us maintain a stable and high-quality codebase.

Frequently Asked Questions (FAQs)

1. What steps do you follow before pushing code?

Before pushing code, I:

1. Verify that I'm on the correct branch.
2. Pull the latest changes from the base branch.
3. Run the application and tests locally.
4. Review changes using git status and git diff.
5. Stage and commit with a meaningful message.
6. Rebase or merge with the latest base branch if required.
7. Run tests again.
8. Push the branch.
9. Create a Pull Request for code review.

Following these steps helps reduce merge conflicts and ensures only tested code is shared.

2. What do you do if you committed to the wrong branch?

If the commit has not been pushed:

• Copy it to the correct branch using:

git cherry-pick <commit-hash>

• Remove it from the wrong branch using:

git reset --hard HEAD~1

If the changes are uncommitted, I use git stash, switch to the correct branch, and restore the changes using git stash pop.

3. How do you move changes from one branch to another?

For committed changes:

git cherry-pick <commit-hash>

For uncommitted changes:

git stash
git checkout target-branch
git stash pop

4. What does a Non-Fast-Forward push error mean and how do you fix it?

A Non-Fast-Forward error means the remote branch contains commits that your local branch does not have.

To fix it:

1. Pull the latest changes using git pull or git pull --rebase.
2. Resolve any merge conflicts.
3. Run the application and tests.
4. Push the changes again.

Avoid using git push --force on shared branches unless absolutely necessary.

5. What do you do if your code breaks after a pull?

I:

• Review recent commits using git log.
• Compare changes using git diff or git show.
• Verify merge conflict resolution.
• Build and run the application.
• Execute the test suite.
• Collaborate with teammates if required to identify the root cause.

This systematic approach helps determine whether the issue is caused by merge conflicts, integration issues, or new code changes.

6. What precautions do you take before merging?

Before merging, I:

• Synchronize with the latest base branch.
• Resolve merge conflicts carefully.
• Run all unit and integration tests.
• Review my code changes using git diff.
• Ensure coding standards are followed.
• Raise a Pull Request and obtain peer approval.

These precautions help maintain code quality and reduce the chances of introducing bugs into the shared codebase.