RidgeRun Developer Manual/Methodologies/Gitflow: Difference between revisions
No edit summary |
|||
Line 6: | Line 6: | ||
== About Gitflow Methodologies == | == About Gitflow Methodologies == | ||
A "gitflow" methodology is no more than a set of practices that define the workflow for software development involving a version control system like git. RidgeRun follows a | A "gitflow" methodology is no more than a set of practices that define the workflow for software development involving a version control system like git. RidgeRun follows a "homegrown" methodology based on the [https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow feature branch] model. This model has several advantages: | ||
*It is very well suited for project scheduled on release cycles. | *It is very well suited for project scheduled on release cycles. | ||
*Allows to maintain a stable code base for all developers involved after each release, which synergizes very well with continuous integration practices. | *Allows to maintain a stable code base for all developers involved after each release, which synergizes very well with continuous integration practices. | ||
Line 12: | Line 12: | ||
*Feature development isolation. Each developer works on its branch and does not affect the development of other branches by other developers. | *Feature development isolation. Each developer works on its branch and does not affect the development of other branches by other developers. | ||
*There are very well defined roles for a git branch, for example, there is the development branch, the master branches, the hotfix branches, etc. | *There are very well defined roles for a git branch, for example, there is the development branch, the master branches, the hotfix branches, etc. | ||
=== Overview === | |||
The RidgeRun git worflow can be summarized in the figure below: | |||
[[File:Ridgerun-gitflow.png|frameless|center|600px]] | |||
The process goes as follows: | |||
#The project starts with a single commit in the '''main''' branch, from where the develop branch is started. | |||
#From the '''develop''' branch, developers branch out '''features''' , which eventually get merged back into '''develop'''. | |||
#Eventually, when the time comes, a new '''release''' branch is branched out from '''develop'''. The release branch is tested thoroughly and, when ready, is merged into '''main''' and into '''develop'''. | |||
#The merge into '''main''' is considered a release and must be tagged accordingly. | |||
#The process repeats from point 2. | |||
#If eventually a critical issue is found on the '''main''' branch, a '''hotfix''' is branched out from it, fixed, and merged back into '''main''' and '''develop''' . | |||
=== Concepts === | |||
==== Main ==== | |||
*Formerly called "master". | |||
*It is '''always''' stable, aka: should always build and run. | |||
*Never do a commit directly | |||
*Never allowed to do forced push (<code> git push -f </code>) on it. | |||
==== Initial commit ==== | |||
*The content is typically a README.md containing a description of the project. | |||
*The typical commit message is: | |||
Initialize project. | |||
[[File:Initial-commit.png|frameless|center|600px]] | |||
==== Initial develop commit ==== | |||
*Purely aesthetic. | |||
*Created with: | |||
git commit --allow-empty -m "Initialize develop" | |||
[[File:Initial-develop-commit.png|frameless|center|600px]] | |||
== Some particular considerations on the feature branch model == | == Some particular considerations on the feature branch model == |
Revision as of 15:22, 5 November 2020
WORK IN PROGRESS. Please Contact RidgeRun OR email to support@ridgerun.com if you have any questions. |
RidgeRun Developer Manual |
---|
Coding Styles |
Development Tools |
Editors |
Debugging Tools |
|
Profiling Tools |
Methodologies |
Design Patterns |
RidgeRun Developer Manual/Testing |
RidgeRun Developer Manual/Build Systems |
Contact Us |
About Gitflow Methodologies
A "gitflow" methodology is no more than a set of practices that define the workflow for software development involving a version control system like git. RidgeRun follows a "homegrown" methodology based on the feature branch model. This model has several advantages:
- It is very well suited for project scheduled on release cycles.
- Allows to maintain a stable code base for all developers involved after each release, which synergizes very well with continuous integration practices.
- Feature branches allow to implement pull requests, a type of code review.
- Feature development isolation. Each developer works on its branch and does not affect the development of other branches by other developers.
- There are very well defined roles for a git branch, for example, there is the development branch, the master branches, the hotfix branches, etc.
Overview
The RidgeRun git worflow can be summarized in the figure below:
The process goes as follows:
- The project starts with a single commit in the main branch, from where the develop branch is started.
- From the develop branch, developers branch out features , which eventually get merged back into develop.
- Eventually, when the time comes, a new release branch is branched out from develop. The release branch is tested thoroughly and, when ready, is merged into main and into develop.
- The merge into main is considered a release and must be tagged accordingly.
- The process repeats from point 2.
- If eventually a critical issue is found on the main branch, a hotfix is branched out from it, fixed, and merged back into main and develop .
Concepts
Main
- Formerly called "master".
- It is always stable, aka: should always build and run.
- Never do a commit directly
- Never allowed to do forced push (
git push -f
) on it.
Initial commit
- The content is typically a README.md containing a description of the project.
- The typical commit message is:
Initialize project.
Initial develop commit
- Purely aesthetic.
- Created with:
git commit --allow-empty -m "Initialize develop"
Some particular considerations on the feature branch model
Rebasing feature branches
Let's assume this scenario, person A and person B are working in parallel each one on individual feature branches that diverged from the same commit in the development branch. Now, let's assume person A got his/her feature branch approved first than person B. Once person A merges the feature branch in the development branch, person A should tells person B that he/she needs to rebase his/her feature branch, so person B can follow these commands:
git fetch # update you local repo from the remote repo git checkout develop git pull git checkout feature/person-b-feature git rebase develop # This may arise merge conflicts that have to be solved
The following figure illustrates this process:
But why rebasing features branches is required? There are several reasons to it:
- Makes it easier to track issues in the development branch, since this branch will have clear points where the feature branches where merged (see Merging feature branches).
- Each developer will have the latest code base in its local repo which implicitly allows for testing the feature that was originally developed in another system. Sometimes this helps find issues.
Merging feature branches
git checkout develop git merge --no-ff feature/awesome-feature # Creates merge commit