GIT Branching Strategy for Enterprise project

GIT Branching Strategy for Enterprise project | what worked for me

Рет қаралды 1,705

19 күн бұрын

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!

Пікірлер: 17

@HowPortal 17 күн бұрын

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.

@RusiruNethmina-jb6zl 17 күн бұрын

thank you

@ransandu 17 күн бұрын

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

@krish 17 күн бұрын

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

@kalingaranasinghe8601 17 күн бұрын

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

@krish 17 күн бұрын

thank you sharing the idea. will do an other video regarding feature rolleouts

@kalingaranasinghe8601 16 күн бұрын

@@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.

@vivekagrawal5608 17 күн бұрын

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.

@krish 17 күн бұрын

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"

@vivekagrawal5608 17 күн бұрын

@@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.

@vipulgulhane4934 17 күн бұрын

What is branching staragey for everyday release

@krish 17 күн бұрын

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?

@vipulgulhane4934 16 күн бұрын

@@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.

@kalingaranasinghe8601 13 күн бұрын

This guy deletes my comments :D, seem not ready for feedback

@krish 12 күн бұрын

i did not delete comments. you can see many negative feedback comments on videos. i didn’t delete those

@krish 12 күн бұрын

i just checked. i can see your comment in this video and also I have replied to it. why you say its deleted?