Git Rebase vs Merge Before Pull Request

Orchestrate data pipelines.

Answer Correct answer: C — The developer should run git rebase master to integrate the latest changes from the master branch into Branch B, ensuring a linear history and minimizing future merge conflicts.

Two developers are working on separate application releases. The developers have created feature branches named Branch A and Branch B by using a GitHub repository’s master branch as the source. The developer for Branch A deployed code to the production system. The code for Branch B will merge into a master branch in the following week’s scheduled application release. Which command should the developer for Branch B run before the developer raises a pull request to the master branch?

git diff branchB master
git pull master
git rebase master Correct Answer
git fetch -b master

Community Votes

100%

100% of anonymous learners picked answer C. Votes are pick records left by other test-takers — they are not the verified answer.

Community Insight

The core concept tested is branch synchronization strategy; the common trap is confusing 'git pull' with 'git rebase' or misunderstanding how each affects commit history and conflict resolution.

This question tests best practices for integrating feature branches into a shared master branch using Git. The correct approach is to rebase the feature branch onto the latest master to ensure a clean, linear history before submitting a pull request.

Many learners choose B (git pull master) because it is the standard way to update a local branch with remote changes. However, 'git pull' creates a merge commit, which can clutter the project history with unnecessary merge nodes, whereas rebasing keeps the history linear.

Community Discussion (5 comments)

simon2133 👍 1 Selected: B

B It's considered the general default option for a few reasons (1) it includes git fetch and (2) you won't get a merge conflict if there happens to be a branch C spawned off after A was merged, you won't need to use --force (3) related to (2) you're less likely to be clobbering commit history

AgboolaKun 👍 4 Selected: C

The correct answer is C. Here is why: Rebasing Branch B onto the updated master branch ensures that Branch B incorporates all the recent changes from the master branch (including the changes from Branch A that were deployed to production). It helps maintain a linear, clean history by placing Branch B's commits on top of the latest master branch commits. This approach reduces the likelihood of merge conflicts when the pull request is eventually merged into master. It makes the code review process easier as all the changes in the pull request will be relevant and up-to-date. By using git rebase master, the developer ensures that Branch B is up-to-date with all changes in the master branch, including those from Branch A, before creating the pull request. This approach helps maintain a clean, linear history and reduces the likelihood of conflicts during the merge process.

mzansikiller 👍 3

Rebasing In Git, there are two main ways to integrate changes from one branch into another: the merge and the rebase. In this section you’ll learn what rebasing is, how to do it, why it’s a pretty amazing tool, and in what cases you won’t want to use it. The Basic Rebase If you go back to an earlier example from Basic Merging, you can see that you diverged your work and made commits on two different branches. Answer C

aragon_saa 👍 2 Selected: C

Answer is C

matt200 👍 2 Selected: C

Option C: git rebase maste

Comments & Corrections

No comments yet — spotted an error or have a note? Share it below.

Expert Analysis

Why the Answer Is Correct

Rebasing Branch B onto the updated master branch ensures that Branch B incorporates all the recent changes from the master branch (including the changes from Branch A that were deployed to production). It helps maintain a linear, clean history by placing Branch B's commits on top of the latest master branch commits. This approach reduces the likelihood of merge conflicts later during the actual pull request review and results in a more readable project history.

Why the Other Options Are Wrong

Option A (git diff) only shows differences but does not apply them, leaving the branch outdated. Option B (git pull master) performs a fetch followed by a merge, which creates a new merge commit object. While safe, this often leads to a non-linear history with many merge bubbles, which is generally discouraged for feature branches intended for clean integration. Option D (git fetch -b master) is syntactically incorrect; 'git fetch' does not take a '-b' flag to specify a branch name in this manner.

Community Comment Notes

Community consensus strongly favors C, with most users noting that rebasing provides a cleaner history. One user noted that rebasing places commits on top of the latest master, reducing conflicts. Another user highlighted that while merging is a default option, rebasing is preferred for maintaining a linear timeline in feature branches.

Exam Strategy

When integrating feature branches, prefer rebasing over merging if you want a linear history and are sure no one else is working on your feature branch. Always rebase against the latest master to catch any potential conflicts early, before raising a pull request.

Frequently Asked Questions

Why not use git pull instead of git rebase?

Git pull creates a merge commit, which can clutter the history with non-linear merge nodes. Rebasing moves your commits to the tip of master, keeping history linear.

What is the risk of using git rebase?

Rebasing rewrites commit history. If others have cloned your feature branch, their local copies will diverge, requiring force pushes and causing collaboration issues.

More DEA-C01 FAQ →

Related Analysis

Practice All DEA-C01 Questions

Access 100 questions with complete answers and detailed explanations.

View Full DEA-C01 Practice Test →

← Back to DEA-C01 Study Guide