GIT Branching Strategy for Enterprise project | what worked for me
ฝัง
- เผยแพร่เมื่อ 6 ต.ค. 2024
- In this video, I dive deep into the GitHub branching strategy for managing enterprise projects. I'll walk you through the detailed process of handling feature releases, bug fixes, and hotfixes, showcasing the strategies and best practices that ensure smooth and efficient project management. Whether you're a seasoned developer or just getting started, this tutorial will help you streamline your GitHub branching strategy and improve your team's productivity.
Don't forget to like, share, and subscribe for more in-depth tutorials and insights!
![[Live] : ONE FIGHT NIGHT 25 วันนี้!! "อเล็กซิส vs รีเกียน"](http://i.ytimg.com/vi/suVr9a6BM2g/mqdefault.jpg)
What is the best branch strategy for managing multiple versions of the same software? For example, a basic version and a pro version, where the pro version includes all the features of the basic version plus some additional features.
Thanks for sharing this.
It sounded like the flow sometimes influenced by the team structure as well.
e.g in pre-develop PRs review by tech leads and develop senior TL or architect.
Also I noticed that all the way up to release is about only the merge happened. What's your experience with rebase, squash-merged etc.. Appreciate if you can add a comment on those techniques and their usage based on your experience. Thanks again for this valuable video series. Cheers
i will explain those when I get time. yes when deal with 100+ engineers commits having prior review from a TL is helps architects as then they don’t need to deal with minor oblivious issues
thank you
Thanks for the details.
Some suggest to delete the release branch if the code is merged to master branch. Is this a good practice?
Personally I keep feature branch until its next version release to production. ex: 5.1.x feature branch stays till 5.2.x release to prod. but its personal choice. in trunk based development you can delete branches without an issue
@@krish Thanks sir.
Branching is continuous isolation, for continuous integration you should use Trunk Based Development, and use feature flags to turn off partially develop feature. Trunk Based Development is the required practice for CI/CD
thank you sharing the idea. will do an other video regarding feature rolleouts
@@krish I see lots of devs misunderstand CI/CD. CI is not entirely your build pipeline. CI is when everyone's code get merged into master/main (trunk) branch hence the term in integration. It's is recommended to merge the feature branch at least per day, hence the term continuous. so what's happen when developer code is not ready, that's ok you disable the feature and continue to merged the code master. Next come CD, so your feature disabled/enabled code continuously release to other environment. when you are ready you can simply enabled the feature. Next level is progressive delivery, you can enable the feature visible to 30% user and the measure the error rate. if no error you increase it to 50% and so on. Continuous is faster than people think here. This the modern DevOps practice. When you have separate log living branch you are doing continuous isolation(think about the time you have to spent to review code for each of these branch merges), you have build more than once. When you do Trunk Based Development you build once and deploy anywhere. When you do continuous integration and deployment this way you don't need release schedules.
We are also following the same convention. However, there are minor changes which worked for us.
All the day to day development (features) is merged to "develop" branch. The develop branch is deployed in dev env.
All the changes from develop branch gets merged into master branch every 2 weeks. This branch is deployed in qa env and all the test cases run on top of it.
Now, the production deployment happens from Master.
For any HF, the changes needs to be merged in dev and then in master. The master would get deployed in production.
We tried release tag, however, it was too much overhead to maintain 3 branches.
Thank you for sharing. yes this almost same. but better keep a tag for every release as that making sure we have "copy of the production code"
@@krish Yes sir, we need to have a tag for every release. If something needs to go immediately, then the best way is to create a branch on the release tag and deploy it to production from there.
I am a big fan of your work and really appreciate your series on microservices.
What is branching staragey for everyday release
same. create new release branch along with previous release deploys and put the commit to that. BTW what sort of usecase for daily releases? how do you manage QA / UAT sign off?
@@krishthat why I wanted how do we deal with this situation. Imagine the the use case of stock market related or zerodha kite goes every day updates in the night with release.
This guy deletes my comments :D, seem not ready for feedback
i did not delete comments. you can see many negative feedback comments on videos. i didn’t delete those
i just checked. i can see your comment in this video and also I have replied to it. why you say its deleted?