Versioning (Monperrus)
- Content
- Lecture material:
- Further reading:
- What is version control? What is version control used for? What's the history of version control?
- What is a good commit?
- atomicity: Atomic Commits with Git (N. Rambeck) Links to an external site.
- readability
- commit message
- What is code review?
- What is a pull request?
- What is a fork? a branch?
- How to connect Github and Zenodo for long-term preservation Links to an external site.?
- What is a tag? What is a merge?
- How to do it?
- Git, SVN, Bazaar, Darcs, etc.
- Github, Gitlab, Bitbucket
Grading criteria:
In Canvas, you will upload a link to a code repository. If the repository cannot be made publicly available, you will give the TA access to it.
To pass this module, you must show that you are able to:
- Setup your own repository
- Maintain a streak of 10+ high-quality commits (for groups, this is a per student requirement)
- Write a high quality README
Checks:
- the TA will check that the repository is structured with appropriate folders and contains a good README.
-
the TA will open the recent commit history, and will select a minimum of 10 commits, at random, to check that:
- every commit is an atomic bug fix or feature, with a clear commit message.
- the commit contents reflect the commit message (and vice versa)
- the TA will follow the instructions to execute the code on a simple example and assess the clarity of the setup
In order to Pass with distinction:
- the TA will check that most commits are clearly identified as feature / fix / documentation / etc, thanks to a clear commit message discipline
- the TA will check that there is documentation in the repo specifying:
- the commit conventions used in the project
- the branch conventions used in the project
- the proper configuration of continuous integration guarantees distinction
If you're already a master in versioning and you potentially feel bored by the tasks, you are asked to re-implement the system of "Verified three-way program merge" (OOPSLA'18), with the appropriate simplifications and assumptions so as to be done within one month.
Advanced topics:
Content
-
- Recap about last lecture
- What is a good commit? (atomicity, readability, commit message)
- Discussion about the exercises
- Branch engineering
- reference: Git workflows (Links to an external site.)
- no branch
- per user / per feature
- per release, long term support
- branches contain more than master
- naming convention
- visibility convention (the dashboard branch should be the most active one)
- Repository engineering
- As unit of features: https://github.com/jenkinsci/jenkins
- As unit of packaging (one repo = one binary) https://github.com/xfce-mirror/xfce4-datetime-plugin/
- As unit of build (Links to an external site.), of continuous integration (Links to an external site.)
- As unit of community (one repo = a team working together) https://github.com/google/security-research-pocs
- As unit of visibility:
- one repo = many stars = many backlinks
- one repo = many commits (Links to an external site.)
- As unit of issues / tickets: https://github.com/isaacs/github (Links to an external site.)
- As unit of care (one repo = somebody cares about it, about code review)
- As blob (monorepo (Links to an external site.))
- Preparation of a short presentation:
- Monorepos:
- Semantic versioning: https://github.com/mojombo/semver (Links to an external site.)
- How do centralized and distributed version control systems impact software changes? (Links to an external site.)
- Group RQ 1-5
- Group RQ 6-9
- Group RQ 10-12
- Signed commits (Alexander Nilsson)
- Semantic merge: Verified three-way program merge (Links to an external site.) (Maximilian Algehed)
- Recap about last lecture