Most teams will have a git(or any source control) workflow that they follow. Detailing the workflow that we follow in my team at PayPal. We have a team of 8 engineers working on multiple apps at the same. Over time we have created this process detailed below:
Development Process
- We have 3 main branches
develop
,release
andmaster
. All of them are protected such that no one can directly push commits to these branches. The code has to be added only through PR's.
-
develop
is our working branch and everyone creates a new branch fromdevelop
and then creates a PR to it once they are done. On a side note, we follow the commitizen of writing commit messages. This helps to automate changelogs. - We have a CI pipeline that runs the code against
tests
,eslint
etc. Every PR is reviewed by a couple of engineers. - Once PR is approved and passed the CI its merged. We use the
Squash and Merge
option. We thendelete
the feature branch. - Once the PR is merged we build and deploy the code to a staging environment to be tested. This is where we can do manual testing and end to end testing.
Release Process
We generally release at the end of every sprint(bi-weekly).
- When testing is done, we will create a PR from the
develop
branch to therelease
branch. We also tag this PR with arelease-candidate
tag. This helps to in case we need to go back and see what was exactly released in case of an issue. - On this PR, since we are using
commitizen
we generate the changelog using standard-version. We keep all the changes over time within theCHANGELOG.md
. - We then create a build and deploy. Sanity testing is one last time here.
- Then we use the build to deploy to production.
Patch Fixes
- Development happens from the
develop
branch, in case we need to fix an issue a new branch is cut fromrelease
. - Changes are made, reviewed and tested. Then the PR is merged to
release
. - Then the build and deploy process takes place.
- As a follow-up, we also merge the same code into
develop
to keep both branches in sync.
One thing to add here, everyone in the team has to write access to the main repo. They are free to fork the repo if they choose to. We prefer that all branches be pushed to the main repo so it's easy for anyone to contribute to an existing branch. Once any feature branch is merged, we delete
it.
Hope this helps any other team looking to get a git workflow going. Curious to see what other teams/companies follow. ๐
Top comments (0)