Exam AWS Certified Data Engineer - Associate DEA-C01 topic 1 question 138 discussion

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

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.

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

Answer is C

Option C: git rebase maste