Most workflows are described informally, using the authors’ preferred terms. This makes understanding and comparison of workflows difficult.
We have defined a common framework for defining workflows. Once expressed in the framework, workflows can be easily compared and contrasted.
Part of the framework definition are the different lines of development commonly seen in software development projects. Such development lines are presented in the following table:
| Id | Development line type | Description | Branches commonly associated with this line |
|---|---|---|---|
| i. | Main | Contains all the changes associated with the last stable release | Master, Trunk, Baseline |
| ii. | Integration | Allows the integration of multiple changes that are not yet ready to be released | Develop, Development |
| iii. | Change | All work associated with the development of a new feature | Feature, Topic, Epic |
| iv. | Release | Isolates all changes for a particular version in preparation for its launch | Production, Latest |
| v. | Validation | Work associated with testing, verification and approval of development work not necessarily ready for deployment | QA, Candidate, Pre-production, Staging |
| vi. | Fix | Development work needed to correct bugs and other emergency fixes | HotFix, BugFix |
The framework is composed by rules that indicate how a specific characteristic of the development is defined for a Git workflow. Such rules are classified according to the general aspect of the development process they are associated with. In the following table, 4 categories encompass the rules extracted from the workflows’ descriptions. These rules are associated to development lines (from previous table) and have predefined values against which Git repositories will be evaluated to determine the degree of compliance to a given workflow.
| Category | Workflow characteristic |
Related line type |
Allowed rule values or line type |
|---|---|---|---|
| 1. Setup | a) Repository creation | A) Clone, B) GitHub-style Fork | |
| b) Branch role assignment | i., ii., iii., iv., v., vi. | A) Master, B) Develop, C) Development D) Feature, E) Topic, F) Production, G) Release, H) Baseline, I) Gen- eration, J) Next, K) Fix, L) HotFix, M) BugFix, N) Epic, O) Latest, P) Pre-production, Q) Candidate, R) QA, S) Staging, T) Synchronize | |
| c) Development environment | i., ii., iii., iv., v., vi. | A) Central repo, B) Local repo, C) Forked repo | |
| 2. Branching strategy |
a) Event to create a new branch | ii., iii., iv., v., vi. | A) To work on a new feature, B) To create a fix, C) To prepare a release, D) To integrate work, E) To test/validate work |
| b) Parent branch | ii., iii., iv., v., vi. | i., ii., iii., iv., v. | |
| c) Broken code is not allowed | i., ii., iii., iv., v., vi. | ||
| d) Production-ready | i., ii., iii., iv., v., vi. | ||
| e) Lifetime | i., ii., iii., iv., v., vi. | A) short-lived, B) long-lived | |
| f) Delete branch after | i., ii., iii., iv., v., vi. | A) Integration completed, B) Additional tasks done | |
| 3. Code integration strategy |
a) Event for code integration | i., ii., iii., iv., v., vi. | A) End of working day, B) Every <n> weeks, C) On work completed, D) After rebase, E) After code review, F) After passing tests in Dev, G) After passing tests in QA/Test, H) After passing tests in Prod, I) To update target branch, J) As frequently as possible |
| b) Main integrated into | ii., iii., iv., v., vi. | A) Upstream, B) Downstream | |
| c) Integration integrated into | i., iii., iv., v., vi. | ||
| d) Change integrated into | i., ii., iii., iv., v., vi. | ||
| e) Release integrated into | i., ii., iii., v., vi. | ||
| f) Validation integrated into | i., ii., iii., iv., vi. | ||
| g) Fix integrated into | i., ii., iii., iv., v. | ||
| h) Code integration mechanism | i., ii., iii., iv., v., vi. | A) fast-forward merge, B) non-fast-forward merge, C) rebase, D) cherry-pick, E) fetch with rebase and merge, F) fetch and merge, G) bot or webhook | |
| i) Merge options | A) force, B) force-with-lease, C) no options | ||
| j) Code review approach before integrating from | i., ii., iii., iv., v., vi. | A) Staged, B) At central repository, C) Through pull/merge request, D) Rebase before pull/merge request, E) Rebase after pull/merge request | |
| 4. Development conventions |
a) Commit messages guideline | A) GitHub convention | |
| b) Naming convention | i., ii., iii., iv., v., vi. | A) Semantic versioning, B) production, C) develop, D) feature/*, E) users/<username>/*, F) skdy/<username>/*, G) release-*, H) release/* I) v*, J) releases/M<sprint>, K) QA, L) candidate, M) hotfix-*, N) bugfix-*, O) fix-*, P) hotfix/* | |
| c) Tags used | i., ii., iii., iv., v., vi. | ||
| d) Release mechanism | A) New release based on previous, B) New standalone release | ||
| e) Version bump used | |||
| f) Version stored in file VERSION | |||
| g) Feature toggles/flags used | |||
| d) Issue tracker used |
The objective of defining such framework to characterise Git workflows is to provide a consistent representation of workflow definitions that may be otherwise specified using heterogeneous or proprietary terminology.
For instance, the following guideline extracted from the specification of the GitFlow workflow: “We consider origin/master to be the main branch where the source code of HEAD always reflects a production-ready state.” can be mapped in our framework to rule 2.d.i, in other words, the branching strategy [2] for this workflow requires always having in production-ready state [d] (containing only code that compiles, with all tests passing, and fully integrated) the main development line [i]. The workflow can then be characterized by following the afore-mentioned mechanism for all the statements in the workflow’s specification. It is important to consider that not all guidelines can be mapped into a rule that can be later used to evaluate such workflow, as sometimes these guidelines may reflect subjective notions or conditions that can only be fulfilled under a specific environment.
Additionally, an enforcement level is assigned to each of the rules mapped, to specify if such rule is described in the workflow’s description as either a requirement (REQ), a recommendation (REC), a prohibition (PRO), or as an existing role-branch relation ( ✓ ).
The proposed framework can be used to characterize and compare workflows to determine how closely a given repository follows the expected guidelines or, at the beginning of the development process, to identify the Git workflow that better suits the requirements and objectives of the current project.
A practical example of the framework can be accessed at the following link: https://docs.google.com/spreadsheets/d/1SQFZMlPFqCuO0Ker82HD-kaC6pHrh2p8yQ5YQvHNQZU/edit?usp=sharing