The only assumption here is that Git is the version control system in use and so terms like branch, commit, tag, merge etc are to be interpreted in the Git jargon.
Instead you have complete freedom in defining your own and below you can find some useful considerations to do so. Nyx can support any strategy so you’re not constrained at all into one strategy or another. No need to fall into one of these two categories but this helps clarifying what a typical workflow may be depending on the project type and the organization processes.
#Gitlab branching strategy code#
There are some original thoughts in there that may help you deciding which strategy to adopt, like integration oriented patterns and path to production oriented patterns, the former being generally suitable for code development and the latter for operations. Moreover you probably may find interesting the Patterns for Managing Source Code Branches by Martin Fowler, which is not a workflow model but probably the most extensive collection of branch patterns available. This set of rules is often called in many different ways, like branching strategy, branching pattern, git worlflow. Even when you have never thought about a branching model you’re actually using one.
In version control, this means you have rules and semantics in place to track your code changes consistently. Whether the project is developed by a team or you are the sole contributor you soon need to define your workflow. Development driven and Operations driven branching models.
0 kommentar(er)
