Have a good time chatting on branching strategies...
...and drink the well known "Pepsi Free"
Open Pull Request
# Fits for cases in which you deploy several times at day.
+ Simple model.
+ Easy to understand and implement
+ Widely used.
+ Easy to sync up with current master
- May be inconvenient when a lot of contributors works at the same time on multiple features.
# Freedom on versioning policy.
+ Web magic stuff (auto closing issues, etc...).
# Suitable for multiple independent teams.
+ Each new repository is completely independent.
# For projects on early state probably it's too much.
# Freedom on local branching development flow.
+ More control on privileges.
- Working with more remotes increase learning curve at the beginning.
twgit feature start PFS-279
twgit feature start PFS-350
twgit release start
twgit feature merge-into-release PFS-350
twgit feature merge-into-release PFS-279
twgit release finish
twgit hotfix start
twgit hotfix finish
# It is an enhanced mixed approach of Gitflow and Fork Workflow.
+ Automate some of maintaining chores (versions, tag,
+ multiple sequential Pull Request per feature may help reviews.
- sync up with master is no that immediate
- Doc is only in french... (Braking news! they started translating!)
- The same problems as Fork Workflow (learning curve)
- Commands are not so organized.
- When init twgit cuts off all not master branches.
+ Set of clear rule to branch
+ git plugin (ie: git flow feature start)
+ Well integrated with visual application.
- may be complicated at the beginning
- to build release changelog you have to dig in tree history to hunt for features closed.
- With Continous Delivery hotfix and release branches are useless.
+ Incredibly simple model.
+ high level of abstraction.
# Particularly useful at early stage of development.
+ keep clean the master branch history (and the repo itself)
- lose the feature branches history (can be avoided).
# Not opinionated.
+ may be used with other models at the same time.