4.1 Version Control
Version control is a big part of the project. All of the source for the project is version controlled by git. There is no strict workflow implemented for the project since it's a one man team however there were some rules when working with the code.
masterbranch always represented a stable, functioning application at any point in time (merge commits only). The
developbranch represents the application at any state during development. You can expect to find a buggy app where somethings may be broken and other unfinished.
Branching for new features or refactors.
For each new feature, a new branch is created under the feature name. All code for that feature is contained within that branch. Sometimes some features cannot be developed in isolation, if that is the case a new branch is to be created from
developand merged into
developon completed, then merged into the blocked feature branch. It is often hard to describe the scope of a feature so this is entirely left up to the developer.
Detail the commit logs.
The commit messages should contain enough detail for anyone browsing the history to understand what was updated or added in the changes. This sometimes became tedious and when it did, it breaking the commit up into smaller chunks and committing more often.
The entire codebase is hosted on Github. This served as a backup for the repository and facility for third party services to interact with the project. Gitbook, the software that built this book takes the
report/ directory from Github, compiles the book and puts it online for anyone to read. Codeship, the continuous integration service, uses the Github API to listen for commits and run the projects tests automatically. This is detailed further in the Continous Integration section of the Testing chapter.
These are some statistics on the repository pulled from Github.
Notable Commit Logs
Throughout the history of the project, there were some milestones achieved that really helped motivate the development.
commit 89e0700cede400fe2570943a27567810c13987bf Author: Adrian Cooney <email@example.com> Date: Fri Mar 25 17:42:36 2016 +0000 Migration with new inheritance based model. This converts all existing questions in the database to the new entity model. It does the following things: 1. Drop all foreign keys reference the questions table (including circular keys). 2. For each question, create an entity. 3. If the question has a parent, find the parent entity id and set it. 4. Recreate all foreign keys.
commit 414747241536ff3db0746a877a45b43c9e1ae244 Merge: 54ebcc4 6fdb0df Author: Adrian Cooney <firstname.lastname@example.org> Date: Thu Jan 28 14:51:05 2016 +0000 Merge branch 'redux'. Finally confident enough with Redux to use it as the library behind the app for managing data. Although it requires a lot of boilerplate and some, at times, frustrating logic it's extremely robust and to the very core, simplistic.
commit 50bad3b898fae55aa354720dd2b227e55de8947b Author: Adrian Cooney <email@example.com> Date: Thu Jan 21 17:50:38 2016 +0000 Better styling system with SASS and new global, colors, fonts SCSS. Introduced a new styling system where (if preferred), components can be styled by creating a SCSS file under the package name. e.g. If we had the components: src/error/ErrorMessage.jsx src/error/Error404.jsx Each still have their own class `.ErrorMessage` and `.Error404` (if a component in their own right) but we create a single file called `Error.scss`, which is the name of the folder. This file is then placed in the corresponding style directory where the `error` folder would appear. In this case, it would be `style/Error.scss` since the `error` directory is at the root of the source. I also created the following files: * `Global.scss` - For style tags, wildcards etc. * `common/Colors.scss` - For holding the colors of items. * `common/Fonts.scss` - Describe the fonts for items. * `common/Spacing.scss` - (Experimental) Global spacing style.
commit a0db2d317210ca1b0020aef725ab43f527222d03 Merge: 927d098 b78d44c Author: Adrian Cooney <firstname.lastname@example.org> Date: Wed Feb 24 21:05:01 2016 +0000 Merge branch 'the-big-refactor' into develop. This was a HUGE refactor that took the guts of an hour combing through EVERY FILE in the project. All because of one silly global in JS called `module` that clashed with our version of a "module" e.g. CT475. This merge removes all instances of the `module` and it's variants and replaces it with **Course**. Since the database was altered, it was easier to recreate all the data from scratch the run migrations in alembic.
This refactor renamed "module" to "course" throughout the entire app. (link)