Difference between revisions of "RidgeRun Developer Manual/Methodologies/Gitflow"
(→About Gitflow Methodologies) |
(→About Gitflow Methodologies) |
||
| Line 10: | Line 10: | ||
*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. | ||
*Feature branches allow to implement pull requests. | *Feature branches allow to implement pull requests. | ||
| − | *Development isolation. Each developer works on its branch and does not | + | *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. | ||
Revision as of 09:50, 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 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.
Some particular considerations on the feature branch model
Rebasing branches
