Drag steps to the numbered slots on the right, or tap a step then tap a slot.
Steps
Order
1Step 1
2Step 2
3Step 3
4Step 4
5Step 5
mediumDrag & DropObjective-mapped
200-901 Practice Question: Drag and drop the steps to use Git to commit and…
Drag and drop the steps to use Git to commit and push code changes to a remote repository into the correct order.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Stage changes, commit changes, pull the latest changes from remote, resolve any merge conflicts, then push.
The correct Git workflow for committing and pushing code changes is to first stage your changes, then commit them locally. Next, pull the latest changes from the remote repository to sync with upstream work. If there are any merge conflicts, resolve them during the pull or after. Finally, push your commits to the remote repository. This order ensures that your local repository is up-to-date and minimizes merge conflicts.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Stage changes, commit changes, pull the latest changes from remote, resolve any merge conflicts, then push.
Why this is correct
This is the correct order because it follows the standard Git workflow: first stage and commit locally, then sync with the remote by pulling to integrate any upstream changes, resolve conflicts if they arise, and finally push your commits.
- ✗
Commit changes, stage changes, pull from remote, push, then resolve conflicts.
Why it's wrong here
This order is incorrect because committing before staging is not possible in Git; you must stage changes first. Additionally, resolving conflicts after pushing is wrong because conflicts should be resolved locally before pushing.
- ✗
Pull from remote, stage changes, commit changes, push, then resolve conflicts.
Why it's wrong here
This order is incorrect because pulling first without local commits can lead to conflicts during the pull, and resolving conflicts after pushing is also wrong. The standard workflow is to commit locally before pulling to ensure a clean state for merging.
- ✗
Stage changes, commit changes, push, pull from remote, then resolve conflicts.
Why it's wrong here
This order is incorrect because pushing before pulling may cause your push to be rejected if the remote has new commits. You should always pull first to integrate remote changes and resolve conflicts before pushing.
Visual reference
Go deeper
Related to this question
About these practice questions
One of 989 original 200-901 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This 200-901 practice question is part of Courseiva's free Cisco certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the 200-901 exam.