gitintermediate
Git Workflow
GitFlow, rebase and cherry-pick
7 questions
By EZ4Code Team
1. What are the long-lived branches in the GitFlow workflow?
main (production) and develop (development)
Only main
Only develop
feature and hotfix
Explanation: GitFlow has two long-lived branches: main stores production code, develop stores the latest development; feature/release/hotfix are temporary branches.
2. What does rebase do?
Moves the base of the branch's commits onto the latest commit of another branch, producing linear history
Merges file conflicts
Deletes commits
Clones the repository
Explanation: git rebase <base> reapplies the current branch's commits onto base, producing linear commit history, but rewrites history; use cautiously on public branches.
3. What is the main difference between merge and rebase?
merge preserves branch history and merge points; rebase rewrites history to be linear
They are completely identical
rebase preserves merge points
merge rewrites history
Explanation: merge preserves the real branch topology (creates a merge commit); rebase linearly appends commits to the target, with cleaner history but rewritten commits.
4. What does cherry-pick do?
Applies a specified commit to the current branch (can be cross-branch)
Reverts all commits
Merges an entire branch
Renames a branch
Explanation: git cherry-pick <commit> copies the changes of a commit to the current branch, often used to apply fixes to multiple branches.
5. In Git Flow, where is a feature branch cut from?
Cut from develop, merged back to develop when done
Cut from main, merged back to main
Cut from hotfix
Cut from release
Explanation: feature branches are cut from develop for new features, merged back to develop when done; release branches are for release preparation; hotfix is cut from main.
6. What is interactive rebase commonly used for?
Squash, modify, reorder, delete commits
Clone the repository
Create a branch
Push code
Explanation: git rebase -i allows squash/reword/edit/drop operations during replay, to tidy up commit history.
7. What is the main problem with rebasing an already-pushed public branch?
Rewriting history invalidates other collaborators' local history, causing conflicts
No problem at all
Deletes the remote repository
Loses all commits
Explanation: rebase rewrites commit hashes; after a public branch is rebased, others' local branches become inconsistent with the remote, requiring force push and collaborators to reset, which is error-prone.