DEV Community

Discussion on: What git strategies does your company use?

Collapse
 
munawwar profile image
Munawwar • Edited

Two main branches, 3 main environments.
develop branch - for development

master branch is post production/stable branch which all current dev branches should be based/rebased from

environments are develop, beta and prod

all feature/bug branches merges to develop first, which is immediately deployed to develop environment (CI)
if branch needs to be reverted, recreate develop branch based off master with only good/working branches merged. This is done through a bash script.

This also means no direct commits to develop branch should be done.. since recreation of develop will throw it away. All features/bugs need to have their own branches, so that re-creation is possible.

This is much less messy-er than git reverts (did you know that reverting a merge can only be undone with reverting the revert? and that merging again does nothing?)

Take the same commit and deploy to beta. jenkins automatically adds a git tag with beta-date-time format

again if revert is needed, do that on develop branch and redeploy to develop and beta.

once testing is done take same commit and deploy to prod. jenkins adds prod-date-time git tag. merge develop to master to make it the new post production/stable branch. rebase ongoing development branches with new master.

also for this process to work, force push on master branch should be disabled. deleting tags with prod-* or beta-* must be disabled as well.

This evolved from the famous gitflow workflow.


about commit message, nothing enforced at the moment since we're just 2 devs in this startup. But in prev company with much larger team, we enforced that ticket ID be there in every commit. If there is no ticket, then create one!


about hooks, submodules etc..

Well, JS linting hook will be enforced in future.

code reuse is better preferred with package managers of your respective language.. npm for node etc