Based on the experience developing the first version of the framework to characterize Git workflows, and on the analysis of 26 different workflows, we developed an improved version of the framework that is now using feature-based modeling to represent the guidelines extracted from the workflows’ descriptions.
This new version of the framework considers the following branching roles that represent the multiple development lines used in the workflows’ descriptions studied:
| Id | Branching role | Description | Development lines commonly associated with this role |
|---|---|---|---|
| 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 |
This version of the framework also takes into account the different types of repositories (R) participating in the development process, according to the following table:
| Id | Repository type | Description |
|---|---|---|
| R0 | Reference | Source repository from which the developers and other participants to a software development project get their working copy. Is normally protected against direct changes from the project participants |
| R1 | Validator | Repository used to validate the work of multiple integrators or contributors before applying these changes into the reference repository: Also known as: Dictator |
| R2 | Integrator | Repository used for integrating the repositories of multiple contributors just before validating any changes. Also known as: Lieutenant |
| R3 | Contributor | Working repository of a developer or tester on which the tasks associated with the development project are performed. Also known as: Developer |
| Rn | Undefined | Other type of repository |
The framework is composed of features that indicate how a specific characteristic of the development is defined for a Git workflow. Such features are classified according to the general aspect of the development process they are associated with. In the following table, 6 categories encompass the features extracted from the 26 workflows’ descriptions. These features are associated with branching roles (from the previous table) and have their values assigned depending on the workflow to characterize. In this version, the variable information for each guideline is modeled as attributes (marked as: <attribute>). For instance, R<rr> indicates the repository (or repositories) associated with a feature.
| Category | Feature / Sub-feature | Role | Values / Options | |
|---|---|---|---|---|
| 0. Framework setup | a. Category selection | 1. Repository setup and initialisation, 2. File management, 3. Syncing, 4. Branching strategy, 5. Code integration strategy, 6. Additional features | ||
| b. Role assignment | i., ii., iii., iv., v., vi. | A. Master, B. Develop, C. Development, D. Feature, E. Topic, F. Production, G. Release, H. Pre-production, I. Candidate, J. QA, K. Staging, L. Synchronize, M. Next, N. Epic, O. Latest, P. DE Baseline, Q. Generation, R. Fix, S. HotFix, T. BugFix | ||
| 1. Repository setup and initialisation | a. Copy | A. Clone R<rr>, B. GitHub-style fork R<rr> | ||
| b. Repository type | A. Official/reference R<rr>, B. Developer/contributor R<rr>, C. QA/Validation/Lieutenant R<rr>, D. Integrator/Dictator R<rr>, E. Other <type> R<rr> | |||
| c. Add remote | A. {R<rr1>…R<rrn>} | |||
| 2. File management |
a. Add |
i., ii., iii., iv., v., vi. | A. <Git command options> | |
| b. Remove |
||||
| c. Commit |
||||
| d. Tags |
||||
| e. Reset |
||||
| f. Stash |
||||
| 3. Syncing |
a. Push |
i., ii., iii., iv., v., vi. |
A. <Git command options> |
|
| b. Pull (fetch and merge) |
||||
| c. Pull request |
||||
| d. Direction |
I. Upstream |
i., ii., iii., iv., v., vi. |
i. Main R<rr>, ii. Integration R<rr>, iii. Change R<rr>, iv. Release R<rr>, v. Validation R<rr>, vi. Fix R<rr> |
|
| II. Downstream |
||||
| 4. Branching strategy |
a. Create when |
i., ii., iii., iv., v., vi. | A. To work on a new feature, B. To generate a fix, C. To prepare a release, D. To integrate work, E. To test/validate work |
|
| b. Create from |
i., ii., iii., iv., v., vi. | i., ii., iii., iv., v., vi. | ||
| c. Remove when |
i., ii., iii., iv., v., vi. | F. After integration was completed, G. After additional tests were completed, H. After code review/validation was completed, I. If an incorrect branch was created | ||
| d. Remote tracking |
i., ii., iii., iv., v., vi. | i. Main R<rr>, ii. Integration R<rr>, iii. Change R<rr>, iv. Release R<rr>, v. Validation R<rr>, vi. Fix R<rr> |
||
| e. Branch lifetime | I. Short-lived |
i., ii., iii., iv., v., vi. | A. <max. days for short-lived branch> |
|
| II. Long-lived |
i., ii., iii., iv., v., vi. | A. <min. days for long-lived branch> |
||
| 5. Code integration strategy |
a. Integrate when |
i., ii., iii., iv., v., vi. | A. End of working day, B. Every <n> weeks, C. When work completed, D. After rebase, E. After code review completed, F. After tests passing in Dev Env., G. After tests passing in Test/QA/Stage, H. After tests passing in Production, I. To update the target branch, J. As frequently as possible |
|
| b. Integrate into |
i., ii., iii., iv., v., vi. |
Main R<rr>, ii. Integration R<rr>, iii. Change R<rr>, iv. Release R<rr>, v. Validation R<rr>, vi. Fix R<rr> |
||
| c. Code review mechanism |
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 |
||
| d. Code integration mechanism |
i., ii., iii., iv., v., vi. | A. fast-forward merge <Git command options>, B. non fast-forward merge <Git command options>, C. rebase <Git command options>, D. cherry-pick <Git command options>, E. fetch with rebase and merge <Git command options>, F. through bot or webhook |
||
| e. Integration strategy |
i., ii., iii., iv., v., vi. |
A. Recursive, B. Resolve, C. Octopus, D. Ours, E. Subtree |
||
| 6. Additional features |
a. Development conventions |
I. Commit messages |
i., ii., iii., iv., v., vi. | A. GitHub, B. Chris Beams, C. Tim Pope, D. Conventional commits |
| II. State of the development line |
i., ii., iii., iv., v., vi. | A. Production-ready and broken code not allowed, B. Not production-ready and broken code not allowed, C. Broken code allowed |
||
| III. Release mechanism |
A. New release based on previous, B. New release standalone | |||
| b. Branching naming conventions |
i., ii., iii., iv., v., vi. |
A. semantic versioning (semver), B. <development line>, C. <development line>/*, D. <development line>-*, E. */<user name>/*, F. v*, G. Version stored in VERSION file |
||
| c. Supporting tools/mechanisms |
A. Version bump, B. Feature toggles/flags, C. Issue tracker |
|||
The aim of this version of the framework is to characterize Git workflows in a consistent way with a homogeneous structure and 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 new version of the framework to feature 6.a.II.i.A, in other words, as an additional feature [6] and development convention [a] for this workflow is to always have the state of the development line [II] corresponding to the main branching role [i] in a production-ready state where broken code is not allowed [A]. Using this mechanism, the workflow can then be characterized by translating the guidelines in the workflow’s specification to their corresponding features.
It is important to consider that not all guidelines can be mapped into a feature 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, in these cases an attribute can be indicated to reflect the specific feature value for a particular development project.
In this new version, we can also model other relations between the features, such as the hierarchical relation between, for example, a category (e.g., 2 – File management) and a feature that belongs to such category (e.g., 2.a – Add); and the constraints that prevent or allow a feature based on another feature (e.g., the remote tracking feature between two branching roles —4.d— is only enabled once the remote repository is defined in feature 1.c –Add remote).
To reflect how restrictive or lenient a guideline is, an enforcement level is assigned to each of the features mapped, to specify if such feature is described in the workflow’s description as either a requirement (REQ), a recommendation (REC), a prohibition (PRO), an allowed feature (ALL), or as feature selection ( ✓ ).
The proposed new version of the 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 is available here.