There's general best practices of working with git on a team (such as the popular gitflow), but things are always more complicated in practice! Let's talk about how our git workflow is designed in our workplace or team, including but not limited to:
- Branching strategies used
- How mistakes in git are addressed
- How commit messages are formatted
- Any advanced concepts employed (configs, hooks, submodules, trees)
- Anything else!
Feel free to add how your experience has been with your company's workflow. What have you learned? Anything you would change?
Top comments (1)
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