Report#
1. Draw your final hand-written git history graph including commit messages and use it to answer the following questions:
2. In your subteam workflow, what was the practical difference between a commit and a push? Describe it using one concrete moment from your activity.
A commit saved the local notebook/README changes as a snapshot on our branch. A push published those local commits to GitHub so others could review them in a pull request. For example, after finishing a base function notebook, it should be committed locally first and only after that pushed so that the other subteams could see the changes and review them.
3. Your team did not work directly on main (except when first setting up the repository). Explain how this branch-based approach helped your subteam work in parallel.
Each team worked on its own feature branch, so changes did not immediately interfere on main. This allowed parallel development and review before integration. Only reviewed work was merged into main via PRs.
4. What role did the pull request play beyond “merging code” in your process?
The PR was the collaboration checkpoint: it enabled discussion, required reviews, and documented testing evidence before merge.
5. Why did your final history contain multiple branch lines instead of one linear sequence? Give an example based on your git history graph.
Because teams developed separate tasks simultaneously on different branches. Parallel commits naturally create multiple lines that later merge. An example is the first branches being created for the base functions, which were later merged into main after review.
6. Your README conflict was intentional. Explain exactly why Git could not merge automatically in that moment.
Multiple branches edited the same README lines in different ways. Git could not decide which version to keep, so it marked a merge conflict for manual resolution.
7. Describe how your team resolved that conflict? Did you resolve it in a branch before final merge to main? Indicate the relevant parts of your git history graph in your answer.
You compared both edits, combined/selected the final text, removed the conflict markers, and committed the resolution on the branch. It was not strictly necessary to do this in a branch as the conflict in readme doesn’t break the code and there were no external users. However, it is a good practice to resolve conflicts in a branch to avoid breaking main and to allow for review before merging.
8. Why did you have to clear notebook outputs before committing?
Notebooks are JSON-structured and include metadata/outputs which can change with every run. Committing outputs would create unnecessary noise in the history, and even more frustrating, could lead to unintended merge conflicts. Clearing outputs ensures only the source code is versioned.
9. Identify a merge commit in your hand-draw git history graph. What tells you it should be identified as a merge commit?
Any commit that has two parent commits is a merge commit. It represents the point where a feature branch was integrated into main (or main merged into another branch).
10. Did you do a merge of main into one of the feature branches? If so, indicate it and explain what it did. If not, explain why it was not needed.
To resolve the merge conflicts, you’ve probably merged main into the feature branches. This allowed you to incorporate the latest changes from main and resolve conflicts before merging back into main.
By Tom van Woudenberg, Delft University of Technology. CC BY 4.0, more info on the Credits page of Workbook.