Version management (rules)

author:Albert

Forks, Clones & Branches

Elke apprentice maakt zijn eigen copie op de (bitbucket) server (een fork) en kopieert die “persoonlijke” repro naar haar/zijn computer (een clone). Daar worden alle veranderingen gemaakt. Als nodig in meerdere (locale, named) Branches.

Commit, Pull & Push

Elke verandering in de code, of de documentatie, wordt natuurlijk opgeslagen (save) en getest. Af en toe wordt een “tussen-versie” lokaal bewaard in de repro (commit). Na een aantal van die iteraties zal ‘t “af-ig” zijn. Dan is het tijd om dat te delen; door een push naar de eigen repro. In de fork staan dan alle veranderingen (elke commit), maar pas nadat het een zekere (informele) status heeft.

Warning

Only source

This a about source version control; not about asset management. When a (professional) developer speaks about “all files”; (s)he doesn’t really means all file, only all sources.

So, no downloaded stuff, no libs (.ddl, *.lib *.so file etc); no *generated files in general.

A ‘source file’ is a file that is needed to build the product. And typically typed by you or one of your fellow developers. So, it is hardly over a few KBytes big and in readable text format. Like code (*.py, *.c/c#/c++), textual-doc (*.rst, *.md, *.troff), and build-instructions or configuration (Makefiles, shell-scripts, ini-files) etc.

Please do not (hg) add other files, unless consulted with you trainer (beforehand). Also, NEVER add/commit files that is copyrighted (“nor yours”). This kind of flaws are very hard to fix. It basically means we have to abandon (delete!) your repro, as well as all that have ‘merged’ you mistakes.

This has happend once (my fault), lets learn from it: Only source!

Het delen van die files (“kennis” & structuur) gebeurd in twee stappen. Bovenstaande push is de eerste stap; die maakt de files beschikbaar voor anderen. Het overnemen gebeurd door een pull; waarbij we de veranderingen in de repro van een ander lezen naar de eigen PC. Vaak zullen die veranderingen geïntegreerd moeten worden met de eigen veranderingen. De veranderingen worden dan weer gesaved, ge-commit en uiteindelijk ge*pushed* naar de eigen repro op de server.

Deze cycle kan/moet iedereen naast –maar niet na– doen. Conceptueel kan iedereen wel de veranderingen van een ander lezen, maar alleen schrijven naar de eigen repro’s. (zowel op de PC als op de server)!

Pull-Request

Na een intergratie, zal er vaak behoefte zijn om die nieuwe versie te delen op de “master-repro” (https://bitbucket.org/ALbert_Mietus/pathways-extensions-training); dit gebeurd met een pull-request. Dit is een verzoek aan eigenaar van een andere fork, om de fork van de aanvrager te pullen, te integreren en te pushed naar zijn (master) server-repro. In veel teams gebeurd door die persoon aan te spreken, te bellen of te mailen. Of door dit verzoek op bitbucket-server te doen; voordeel is dat dan dat alle details automatisch bekend zijn; ook werkt dat handig als de betrokken mensen elkaar nooit zien/spreken.