Difference between revisions of "RidgeRun Developer Manual/Methodologies/Gitflow"

From RidgeRun Developer Connection
Jump to: navigation, search
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




Previous: Methodologies Index Next: Methodologies/Project Cycles





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

Previous: Methodologies Index Next: Methodologies/Project Cycles