Skip to content

roy-pon/guidelines-git-branching

 
 

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

44 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

Bugs Code Smells Duplicated Lines (%) Maintainability Rating Reliability Rating Security Rating Technical Debt Vulnerabilities

Pon guideines for git branching

A visual storyline is shown here.

Branching, merging and tagging

Main branch

The main branch contains tested prodcution ready code, releases are tagged on main.

Sprints

Each sprint has its own branch

Features

Eeach feature (and bugfix) has its own branch.

Branching

Branching is done from the main branch to the sprint branches, after coding and testing sprint branch is merged to main.

Distinguish between "small" and "large" projects

If you are the only developer it is oke to setup one sprint branch to work on sequentially, there is no need to setup separate feature branches

General

Branches

Branch names clearly communicate purpose and should contain a reference to issue tracking system if relevant

Squashing or merging

Merging is preferred (merging "unless" policy)

Forced commits

These guidelines should not impede the handling of emergencies. Forced commits are allowed by exception only and branch(es) must be fixed at the firs available opportunity.

About

No description, website, or topics provided.

Resources

License

Stars

Watchers

Forks

Releases

No releases published

Packages

 
 
 

Contributors

Languages

  • JavaScript 90.5%
  • HTML 9.5%