Difference between revisions of "RidgeRun Developer Manual/Methodologies/Gitflow"
m |
(→About Gitflow Methodologies) |
||
Line 4: | Line 4: | ||
− | ==About Gitflow Methodologies== | + | == About Gitflow Methodologies == |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
+ | A "gitflow" methodology is no more than a set of practices that defined the workflow for software development involving a version control system like git. RidgeRun follows a gitflow 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. | ||
+ | *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. | ||
+ | *Development isolation. Each developer works on its branch and does not affects the development of other branch 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. | ||
+ | == Some particular considerations on the feature branch model == | ||
+ | === Rebasing branches === | ||
<noinclude> | <noinclude> | ||
{{RidgeRun Developer Manual/Foot|Methodologies|Methodologies/Project Cycles}} | {{RidgeRun Developer Manual/Foot|Methodologies|Methodologies/Project Cycles}} | ||
</noinclude> | </noinclude> |
Revision as of 09:48, 3 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 |
Methodologies |
Design Patterns |
Testing |
Build Systems |
Contact Us |
About Gitflow Methodologies
A "gitflow" methodology is no more than a set of practices that defined the workflow for software development involving a version control system like git. RidgeRun follows a gitflow 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.
- Development isolation. Each developer works on its branch and does not affects the development of other branch 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.
Some particular considerations on the feature branch model
Rebasing branches