Interesting! I have seen this at one company I worked at. We were trying to put all changes to the database in git. Main and develop always got out of sync though as we weren’t deploying from the code in source control.
We do GitHub flow and we publish with each commit to main (creating a docker image), but we only automatically deploy to a dev environment. Production deployment is done by hand, and not every version number is deployed there.
Dude, you nailed it! Great content. I request more Git goodies ... Not sure if this is in your wheelhouse, but if it is, help us all become Git masters. There is a lot of content out there, but there are also a ton of gaps past the beginner and intermediate levels. Good luck w/ the channel! Subscribed
We use github flow, and it's sooo good compared to other teams using gitflow. We're much faster rolling out changes to prod, and since we have unit + integration tests running on our branch pipelines, we're normally sure the branch is safe to be merged to master
But you didn’t talk about the difference between a version and a release, because you could create a new version without creating a release, can you give an explanation about this case please ? Thank you
Actually i had doubt Aex , does the source control branches remains same regradless of the platform , suppose lets say we have 5 branches in Git , will the same be present in bitbucket and other platforms Thanks in advance!
Yes they work across platform as they are just a function of git. It is possible to mirror repositories from GitHub to Bitbucket but I haven’t done it myself before.
It depends on the company but places I have worked great them as the following: DEV: Every commit to develop gets deployed here. Can be unstable mainly used for developer testing. SANDBOX: I worked in payments so the sandbox environment was also open to the public to use for testing. We treated this as a pre production environment and only production ready releases went here.
My previous state owned company introduced scrum but teams weren't cooperative and nobody used Git properly, so the new scrum master was always bouncing from team leader to team leader asking for progress 😂
I have never been able to comprehend why git flow has two different release branches. Development/trunk/whatever? Sure. Feature branches? Sure. Release branch? Sure. And then you have the main/master/whatever, which seems to exist only for the sake of existing. It's a pointless ritual and no one ever seems to quite know what's in there. No wonder it appeals to teams using scrum! Individual developers know what's in their own feature branches. The lead developer / whoever does the integrations and pull requests knows what's in the development branch. The testers know what's in the release branch. And absolutely no one knows what's in main/master.
I think eventually we'll just discard all the agile/ scrum/ sprint nonsense and base development around git or github practises. ie no stupid daily standup and scrum master, just a merge meeting between a branch/ main master and people working on a feature branch or soemthing like that. That way you can define best practises but actually tie them down to something tangible without needing endless books on project management buzzwords.
![I.N "HALLUCINATION" | [Stray Kids : SKZ-PLAYER]](http://i.ytimg.com/vi/n5B5q1Hwt_U/mqdefault.jpg)
![Blox Fruits Dragon Rework Update [Full Stream]](http://i.ytimg.com/vi/EqDAp8udhm0/mqdefault.jpg)
At my company, we use "Git Flow except everyone forgot the main branch exists and not everyone understands what a feature branch is"
Interesting! I have seen this at one company I worked at. We were trying to put all changes to the database in git. Main and develop always got out of sync though as we weren’t deploying from the code in source control.
We do GitHub flow and we publish with each commit to main (creating a docker image), but we only automatically deploy to a dev environment. Production deployment is done by hand, and not every version number is deployed there.
thanks for the video! *and the bloopers section is great!)))
Dude, you nailed it! Great content. I request more Git goodies ... Not sure if this is in your wheelhouse, but if it is, help us all become Git masters. There is a lot of content out there, but there are also a ton of gaps past the beginner and intermediate levels. Good luck w/ the channel! Subscribed
Thanks! Yes I will definitely do some more content on Git in the future, there is a lot to cover there.
We use github flow, and it's sooo good compared to other teams using gitflow. We're much faster rolling out changes to prod, and since we have unit + integration tests running on our branch pipelines, we're normally sure the branch is safe to be merged to master
Excellent info on these branching strategies. Thanks.
Thank you. Glad it was helpful!
Thank you Alex for great lecture. This video is most helpful 🙂.
Read your post on HN. Great post, and best of luck on your RUclips odyssey!
Thank you very much!
Those bloopers are what triggered my subscribe click :D Awesome-sauce.
🤣 I should make that a regular thing. Wasn’t sure anyone watched until the end!
thank you very much, it helped to understand the difference..
You’re welcome. I am glad it was helpful.
Great content. It does really help me a lot
Great video, Alex. Thanks.
Thanks Joe, I am glad you liked it.
What about having main (prod), dev (used for qa too) and feature branches (1 by dev feature) ?
thank you very much it was very clear !
You’re welcome, I am glad it was helpful!
Thank you. Is the Github flow same based trunk based branching strategy?
But you didn’t talk about the difference between a version and a release, because you could create a new version without creating a release, can you give an explanation about this case please ? Thank you
Do you rebase any of these?
Actually i had doubt Aex , does the source control branches remains same regradless of the platform , suppose lets say we have 5 branches in Git , will the same be present in bitbucket and other platforms
Thanks in advance!
Yes they work across platform as they are just a function of git. It is possible to mirror repositories from GitHub to Bitbucket but I haven’t done it myself before.
@@alexhyettdev tqsm 😁
What is the diffrence between dev andsandbox system ? Kindly can you tell if you have a idea
Thanks in adavance
It depends on the company but places I have worked great them as the following:
DEV: Every commit to develop gets deployed here. Can be unstable mainly used for developer testing.
SANDBOX: I worked in payments so the sandbox environment was also open to the public to use for testing. We treated this as a pre production environment and only production ready releases went here.
@alexhyettdev thank you Alex 😊
My previous state owned company introduced scrum but teams weren't cooperative and nobody used Git properly, so the new scrum master was always bouncing from team leader to team leader asking for progress 😂
🧠obrigado irmão!
A subscriber from hackernews
👋 Thanks for subscribing!
I have never been able to comprehend why git flow has two different release branches.
Development/trunk/whatever? Sure. Feature branches? Sure. Release branch? Sure.
And then you have the main/master/whatever, which seems to exist only for the sake of existing. It's a pointless ritual and no one ever seems to quite know what's in there. No wonder it appeals to teams using scrum!
Individual developers know what's in their own feature branches. The lead developer / whoever does the integrations and pull requests knows what's in the development branch. The testers know what's in the release branch. And absolutely no one knows what's in main/master.
I think eventually we'll just discard all the agile/ scrum/ sprint nonsense and base development around git or github practises. ie no stupid daily standup and scrum master, just a merge meeting between a branch/ main master and people working on a feature branch or soemthing like that. That way you can define best practises but actually tie them down to something tangible without needing endless books on project management buzzwords.
Sounds like sponsored video of GitLab
Haha if @GitLab wanted to sponsor me that would be awesome. I just think it is call that you can have your self hosted Git setup.