How do you handle hoxfix with a trunk based approach. I mean if you have the commitment of another developer which is not intended to release and you need a hotfix in the middle... I'm curious and how you will be handled
@@satisfyingly1 there are a few ways to do that. The best way is to use feature flags and always release off main. So create a hotfix branch off main branch at the head and fix it, then merge it back to main and release it. The idea with trunk based development is you are always releasing off main head.
Perfect, thanks! When the changes are tested properly in the release branch, should we deploy the new version from release or main branch? If your answer is RELEASE, what should we do for hotfix change then?
@@tham-18472 Damn, I meant no harm in my comment. Maybe if it's 100% grammatically correct english I would understand the first time. I get it now, you want to merge the main branch into feature branches periodically. Sure, that sounds like a good idea if you need that.
You mention that this process is suited to Waterfall development cycles. My team recently moved to git from TFS and this is nearly identical to our git strategy, but we're also trying to develop in Agile sprints. Do you have any resources on branching strategies that are more suited to shorter development cycles?
Your standard Feature Branch workflow is likely a good starting point for what you're asking. Here's a good resource: www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow
I'm wondering so all companies use main/master branch and then cut a feature brand? Its better to keep main branch for release and when tag created on main branch deploy. All other branches need to be cut from dev branch and dev branch get merged before release. If you do everything on one branch, the hottix will be a hell...
You must have been lobotomised, if you think trunk-based development should be a standard. It is what we were doing 30 years ago, because we had no alternative. It is bad. Your code if full of "if then else", a nightmare to read. I have seen breaking production multiple times with this approach. Feature flags are just a stupid thing. If you are not smart enough to apply GitFlow, maybe you should consider another profession.
This is education/training. Developers need to know the pro's and cons of each model. And also, you don't get to choose model when you start working somewhere. You just have to adapt to whatever is already there.
TBD or classic gitflow are specific to one or another context (company, organization, software knowledge, product releasing, chain of delivery...). Stop thinking that there is one unique solution that fits everyone, this is a beginner though.
@goteet as a so-called DevOps Engineer, I must say that TBD is crucial for modern and automated development pipelines. And because of its simplicity and ability to tweak it to solve some edge cases, it is indeed the silver bullet. Worst than Gitflow can be is only "branch per environment"
This branching keeps on being teach, while it is nowadays considered harmful. The person who popularized it even wrote about it later. This is a great video, but unfortunately does not state the disadvantages of such approach. Congrats on making it though!
You are probably one of these noobs who do trunk development, use feature flags, fill up the code with "if then else", breaks production, and make the code a nightmare to read and debug. Also, you are probably one of these "developers" who believe Scrum is good. And, most likely, you vote Democrats, you identify yourself with the pronoun he/him, because you think it matters. Substantially, you are an idiot. Sorry, someone had to tell you.
Just tried to implement it into the test repo with only two users. 2 hours later: I have main and develop branches incomparable, lol. The develop branch is always out of sync: - "This branch is 4 commits ahead of, 4 commits behind main." I can't diff develop and main to understand what was actually released. Okay, let's tryi to "PR rebasing" main into the develop, to make older days the same for both branches. And it does nothing. Now develop has 6 commits. The main has 6 the same 6 commits. All commits are different in hash, git diff is no longer informative.
Your explanations and animations are so good -- making complex topics clear, simple, and understandable in under 3 min -- amazing.
I love merge hell too
one of the best explanations ive seen yet, why so few views(
Appreciate you saying that
Gitflow is a nightmare. Trunk based is so much better. Merge early and often. Fewer bugs, less complexity, and far fewer conflicts
You are so wrong, and you show all your ignorance.
How do you handle hoxfix with a trunk based approach. I mean if you have the commitment of another developer which is not intended to release and you need a hotfix in the middle...
I'm curious and how you will be handled
@@biomorphic he’s not wrong. He is absolutely correct.
@@satisfyingly1 there are a few ways to do that. The best way is to use feature flags and always release off main.
So create a hotfix branch off main branch at the head and fix it, then merge it back to main and release it.
The idea with trunk based development is you are always releasing off main head.
@@r3jk8 how do you prevent not deploying changes that merged to main that was intended to be deployed soon.
Perfect, thanks! When the changes are tested properly in the release branch, should we deploy the new version from release or main branch? If your answer is RELEASE, what should we do for hotfix change then?
Your deployments will always be from main. Same with hotfix branches.
Why don't rebase master periodically to the feature branch
Can you explain what you mean in more detail? If you can please ask chatgpt to write grammatically correct english as well.
@randiaz95 it will go over your head even if it's correct. 😆
@@tham-18472 Damn, I meant no harm in my comment. Maybe if it's 100% grammatically correct english I would understand the first time.
I get it now, you want to merge the main branch into feature branches periodically. Sure, that sounds like a good idea if you need that.
You mention that this process is suited to Waterfall development cycles. My team recently moved to git from TFS and this is nearly identical to our git strategy, but we're also trying to develop in Agile sprints. Do you have any resources on branching strategies that are more suited to shorter development cycles?
@@heuristix77 yes! Check out trunk based development. It’s the modern and proper way to develop software within a team and sprints.
Your standard Feature Branch workflow is likely a good starting point for what you're asking. Here's a good resource: www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow
I'm wondering so all companies use main/master branch and then cut a feature brand?
Its better to keep main branch for release and when tag created on main branch deploy.
All other branches need to be cut from dev branch and dev branch get merged before release.
If you do everything on one branch, the hottix will be a hell...
Could you please make a video on stacked pull requests in gitflow
Why are you still promoting legacy branching systems? Trunk-based development must be a standard, especially among new developers.
You must have been lobotomised, if you think trunk-based development should be a standard. It is what we were doing 30 years ago, because we had no alternative. It is bad. Your code if full of "if then else", a nightmare to read. I have seen breaking production multiple times with this approach. Feature flags are just a stupid thing. If you are not smart enough to apply GitFlow, maybe you should consider another profession.
This is education/training. Developers need to know the pro's and cons of each model. And also, you don't get to choose model when you start working somewhere. You just have to adapt to whatever is already there.
TBD or classic gitflow are specific to one or another context (company, organization, software knowledge, product releasing, chain of delivery...). Stop thinking that there is one unique solution that fits everyone, this is a beginner though.
@goteet as a so-called DevOps Engineer, I must say that TBD is crucial for modern and automated development pipelines. And because of its simplicity and ability to tweak it to solve some edge cases, it is indeed the silver bullet. Worst than Gitflow can be is only "branch per environment"
This branching keeps on being teach, while it is nowadays considered harmful. The person who popularized it even wrote about it later. This is a great video, but unfortunately does not state the disadvantages of such approach. Congrats on making it though!
Is this video a parody or some kind of joke? Why is anyone promoting Gitflow or Waterfall in 2024?
You are probably one of these noobs who do trunk development, use feature flags, fill up the code with "if then else", breaks production, and make the code a nightmare to read and debug. Also, you are probably one of these "developers" who believe Scrum is good. And, most likely, you vote Democrats, you identify yourself with the pronoun he/him, because you think it matters. Substantially, you are an idiot. Sorry, someone had to tell you.
cuz $hit still happens… just because you may have a nice clean agile utopia, doesn’t mean the rest of the world does or even ever could.
Just tried to implement it into the test repo with only two users.
2 hours later:
I have main and develop branches incomparable, lol.
The develop branch is always out of sync:
- "This branch is 4 commits ahead of, 4 commits behind main."
I can't diff develop and main to understand what was actually released.
Okay, let's tryi to "PR rebasing" main into the develop, to make older days the same for both branches.
And it does nothing.
Now develop has 6 commits.
The main has 6 the same 6 commits.
All commits are different in hash, git diff is no longer informative.
Did that, it is shit.
Can anybody helps me understand, why all the hate
Git, the JS of change management.
Overly complex, often unintuitive, easy to mess things up, but we’re stuck with it.
What alternatives do you like?
@ Mercurial
it's an extremely crappy way to do development work. Git hell is what it is called.
Bullshit.
Dont so this, or will endlich in merge conflict hell
Bullshit.