Ed's Garden

Gitflows

Jun 11, 20254 min read

Flows

  • Great overviews
    • staging - almost gitflow
      • How? - great explanation
        • make feat branches from dev.
        • feat done - merge on dev doing small tests
        • dev done - merge on staging doing heavy tests
        • staging done - merge on main, if everything works, merge main to dev
      • when?
        • stability is a concern & you need releases
  • Mixed Github&gitlab - maybe think about this more before testing
    • How? - make feat branches from main
      • gitlab / if scared of downtime
        • feat done
          • make sure that dev is not behind main
          • merge on dev doing small tests
        • dev done - merge on main w heavy tests first
          • if everything works, merge main to dev
      • github / if not scared of downtime
        • feat done - merge on main w heavy tests first
          • if everything works, merge main to dev
    • dev - gitlab flow/Feature branching variant
      • How? - make feat branches from dev.
        • feat done - merge on dev doing small tests
        • dev done - merge on main, then if all is ok, merge main to dev
      • when?
        • you don’t have as many tests to excuse the creation of staging branch
    • feats - github flow/Feature branching - githubflow.excalidraw
      • How? - pull requests to merge directly to main
      • cons
        • can’t test 2 new features at the same time
  • only main - trunk based
    • How? - checkout main, push commits directly there
      • no pull requests
    • when?
      • comfortable expecting & fixing bugs w downtime
      • team is mature
      • time to deployment should be low
    • pros
      • merge conflicts are faster but smaller
      • +knowledge sharing, no problem w team changes
    • cons
      • features might need more time
        • instead of shipping unfinished stuff, use feature flags
      • bugs migth be a problem for the whole team,
      • downtime is expected because of bugs
        • canary releases (shipping only to 5% etc)
          • if they continue to crash
            • you can automate logging to disable the canary through feature flags etc
          • if they don’t
            • increase percentage
        • Tests
          • GH actions
          • integration > unit tests?
          • even with QA if needed through pre-prod
    • Imgs
      • img1
      • img2

Other

  • Great resources

  • mine

    • General info
      • every commit should follow conventional commits
        • when you close an issue, e.g.:
          • feat: connects to supabase database (#12)
      • similar rules applies to branches. E.g.
        • feat/log-in
        • fix/crash-on-mobile
      • E.g. repo that follows these conventions: here
    • branches
      • dev - make&test features (unstable)
        • if (feature is 1 commit only) directly commit to dev
          • else branch out from dev
        • if (feature is ready) merge to preview
      • staging - test features (hopefully stable)
        • if (feature is reviewed) merge to prod
      • main - stable (hopefully)
        • only reviewed merges from preview will be accepted
          • apart from hotfixes etc
    • “bad”
      • How we apply changes from one branch to the other?
      • classic merge when finished - squash for bad commits
        • command e.g.
          • HEAD is on dev branch
          • git merge analytics-feat
        • always squash if…
          • you prefer to create useless commits without following conventional commits, or using git stash. E.g.
            • “centers div to the container”
            • “changes font-family of paragraph under image”
      • we don’t use rebase unless…
      • you use it with the -i flag to squash stuff etc
        • you made too many useless branches

  • Branches explanations

    • feature
      • to add significant features to the codebase
        • Created from develop
          • Merged to when completed: develop
    • release
      • when preparing for a new release for final testing, bug fixes, and version preparation
        • Created from develop
          • Merged to when completed: master and develop
        • and a new tag is created to mark the release
    • hotfix
      • Created from master
        • Merged to when completed: master and develop
      • create branch from main to hotfix
      • merge to staging or directly on main
      • merge main to dev

  • criterias - how many CI do you want? - do you do releases? - hotfixes? - how fast are you at fixing and how much of downtime can you have?

  • Archived - bad explanations

      • models
        • Github flow - main branch and feat/bugfix branches
        • GitFlow - main, dev and feat/bugfix branches
    • gitflows - better
      • master
      • develop
      • feature
      • hotfix
      • staging
    • github flow
      • master
      • feature
    • gitlab flow
      • master
      • feature
      • feature
      • production
      • identycal to gitflow but

Graph View

Backlinks