Introduction
A friend of mine asked me on one of the meetup, how frequently we are releasing the features on production. I said 3 week once. ie. every end of sprint 😊
He was surprised and asked me how many people working on the product, I said it was 14, all the 14 will code 👨💻
Then my friend surprisingly asked how are we managing code conflicts ⌛ as many developer working on same codeline with different multiple features , bugfix
oh Yeah... In this blog post I will share you the most successful ⭐ codeline strategy we using for past 4 years.
This will be useful for people managing multiple repositories 🤝, And also for new product development ☑️.
Git Codeline process
a picture is worth a thousand words
develop holds all completed feature branches and reflects the latest development code. Continuous builds run on this branch.
main - only stable code is merged from the develop branch. Nightly / Publish builds run on this branch.
release/* branches - branched out of the main branch, for every release. Tagged for each release.
Pull Request denied, if PR-Merge-build fails
feature/* branches - branched out of the develop branch. usually short-living - when a feature is ready it is merged back to develop and the branch is closed.
manual pull should be fetched/refreshed to consecutive feature branch
Will run on develop branch, so that each developer commit is responsible for success/failure
Pull Request Merge build will certify before integrate into main or release branch. This process involves merging the source branch i.e. develop or hotfix branch, into the target branch i.e main or release branch, with out committing into main
E2E test will runs on main branch. Any failure should be treat as blocker.
E2E test will runs on release branch. Any failure should be treat as blocker.
Advantages
- Developer will always work on successful builds⌛
- No
conflicts. - Merge will be reviewed 👁️🗨️ by peers
- Saves more time 🕒
Top comments (0)