Hi, I don't think there can be any other easier explanation to teach this. You nailed it. Can you make more videos like this? It will surely help a lot of people. We have different branch strategies you can make on those, on trunk based.
Fantastic video - thank you for this. I've been looking for exactly this for the past 5 years. It's the perfect illustration. Much appreciated. Would love to see more :)
The bit that had me coming out in hives was where the hot fix branch went back to master then down to develop branch…the very place the bug came from that needed the hot fix. Would not fancy trying to implement this with an inexperienced team.
Release branch is an optional part of the Gitflow. The fundamental part is making feature branches and rebasing the current devlop branch to be up to date.
One of the best video on Gitflow! Thanks much for sharing! Can you explain how many test environments are needed for testing these features/HFs/releases etc? Looks like we need many. Please explain.
Hi, In principle you only need one, but you would need to share the environment if you want to test multiple branches. Another solution would be to test on a local machine. But the key is to script the deployment and to consider deployment scripts as part of the code, so each branch can be deployed at all times...I think it might require a whole new video explaining how all this can be achieved...
@@devchild9404 Thanks for your prompt response! I understand a little bit, but it would be really helpful if you can upload a separate video on it.. In my team, either due to bad coding or not following the best practices, we can't use the same environment for testing multiple branches as there are some dependencies like migration scripts would fail or data would get wiped off if we do reset etc.. hope you can understand what I'm trying to say.. Thanks in advance!
Hello, thanks for the video! It was very well done. For the next part can you do a video about how to accomplish each step with Git commands? I'm a little lost on how to integrate a branch into two others. Thanks!
Really nice explanation, thanks! One comment, though: I don't think that any merge into develop branch should be merged instantly into feature branches. In fact, there is no need in my opinion to merge to feature branches at all. Maybe just once before you try to merge the feature branch back to develop. I don't see it realistic that if I'm working on a feature branch I should be aware of any other feature branches/hotfix brances/release branches merging into develop. But maybe I'm wrong.
Yes, that's correct...you don't have to merge on every commit in dev or master... but eventually you will have to. Merging often will save you from having to solve complicated merge conflicts. Some systems allow you to automate the merge whenever a commit happens upstream.
Great! Can anyone recommend materials for what to do when working with a service-oriented architecture and multiple repositories? Would love it if there was clear extension of this workflow to the multi-repo situation. Thanks in advance.
Hi @Devchild awesome video! Could you please explain what does it mean the last green arrow at 2:24 from feature 2 to develop? if that's the end of the feature2 shouldn't the green line stop there and remove the branch? (like feature1). Thanks in advance.
Hi, Yes you are correct, after integration you can safely remove the feature branch, so yes the green line should have stoppen in the video. But it's not a strict requirement, you could decide to integrate multiple times from the same branch, although from a maintenance perspective it's better to delete the branch after integration.
Easy and nice! Thank again. I'm a little confused by the last green line from the branch "Feature/F1" to the branch "Develop". What is it for? Or is it just a continuation of the work? :)
Hi, it can become nasty in these kinds of scenario's, features should be independent developments, if your features require common (unstable) functionality then it might indicate that your features are too small. You could decide to merge F1 into F2 and continue development on F2 and call it a single feature. To handle this cleanly, you would first have to merge F2 into F1 and then the other way around (F1 into F2). If this isn't an option, you could also cherrypick the common code. A last option you can consider is modify the common code in its own feature branch and follow the gitflow strategy, I hope this helps... ;)
What if Feature 1 is merged back to Develop branch, and also Feature 2 is merged back to Develop. But only Feature 2 is going to be released to Production? How are you going to remove Feature 1?
Thank you for the video. How to approach separate code bases for the feature/story? Back-end is in .NET and front-end is based on React. Each resides in it own repo. If the feature requires changes in both repos (so 2 feature branches), I guess best would be to merge both into each develop at the same time in order to have working feature as a whole. Please share your opinion.
When to integrate into the develop branch is more a question of quality than it is of dependency. Make sure your new feature does not fail when the required dependency isn’t finishes in time. I would suggest using feature toggles for this, it requires a bit of development effort, but you get a lot of flexibilty for it in return.
Depends on your process, if you have a testteam or tester, testing a full release, then testing based on a release branch is the way to go...if you have a tester, testing individual features, then testing based on feature branches works best.
I hate my company for using this complicated workflow. I still have no idea how exactly to merge back the dev branch into my feature branch so I always have merge conflicts when I try to merge my feature branch into dev branch my colleagues have to solve for me
Hi Khalid, it's an animation, so unfortunately there's no image of this. You might be able to take a screenshot of one of the last frames, but it doesn't look that good on print then, I think..
I've never felt such emotion watching a git tutorial before. The background music made me think about life.
😂
I want a hug after listen to this
It made me think about chickens
@@boggledeggnoggler5472 chickens???? :)
yes
First time watching a release management video with zero anxiety
This still serves one of the best illustrative video for learning gitflow. Thanks for making this. Much appreciated, Cheers!
This 5 mins video was better than many 15 mins videos I watched. all my questions were answered without a single word being spoken! 👍
This is one of the best that I've seen. Expecting few more from your end. Kudoss . . . .
Best video on GIT FLOW..You explained everything without saying a word in less than 3minutes..Kudosss..You just nailed it
Hi, I don't think there can be any other easier explanation to teach this. You nailed it. Can you make more videos like this? It will surely help a lot of people. We have different branch strategies you can make on those, on trunk based.
excelent! ... In your video I learned more than in a video of 20 minutes.
Beautiful! Concise, Simple and Efficient. Pat on the back for creating this, thank you.
Just to reiterate previous comments but I feel compelled to do it. Thank you for a great video. It is soo good! Just excellent.
One of the best git tutorials & very easy to understand. Appreciated your efforts.
Very nice way to explain what is git-flow, I really like it!
Very easier explanation within 5 minutes you nailed it, appreciated keep it up.
Thank you man, you make me have any idea of how works git workflow in less of 3 minutes.
Thank you!! So glad I found your beautiful and simple explanation! and this calming soundtrack!
Long live Devchild. Thank you.
I really liked that. That was done very well.
Excellent illustration, thank you!
Beautiful video and music, thanks for creating
Fantastic video - thank you for this. I've been looking for exactly this for the past 5 years. It's the perfect illustration. Much appreciated. Would love to see more :)
I got this video referred to me by some org. Well done. awesome information,
This man deserves your upvote and sub.
Awesome video. Just answered all the questions I had in just less than 3 mins.
Thanks much! That's a quiet simple and to-the-point explanation.
anybody who knows deeper understanding can summarize it best. this is it.
This was incredibly helpful to me. Thank you sooo much! :)
Concise and straight to the point. Nice.
That line from develop branch to feature branch giving me anxity 😵💫
The bit that had me coming out in hives was where the hot fix branch went back to master then down to develop branch…the very place the bug came from that needed the hot fix. Would not fancy trying to implement this with an inexperienced team.
please make more videos, you explained so nicely
This is so perfect....wow..thanks for explaining it like this!!! God bless you!!
Release branch is an optional part of the Gitflow. The fundamental part is making feature branches and rebasing the current devlop branch to be up to date.
Thank you.. this video can explain better than others
Pretty simple and enough, Now I'm going to understand it
I never ever watched such a cool video !! Awesome ..
Wow Short & Sweet clear explanation
Best explanation ever
a good explaination, well done.
Please upload more like this 🙏🏼
This is so clean. Thanks!
Exellent, simple and to the point !
Great video; topics pleasantly presented and relaxing to watch. Thanks!
Well that was extremely helpful and also... weirdly beautiful. Thanks for that.
Awesome explanation! Thanks!
Nice video!!! Congrats.
please make more videos, this was super helpful
Great tutorial
clean, clear, simple👍
awesome drawing awesome explanation. awesome video
excellent video devchild
One of the best video on Gitflow! Thanks much for sharing!
Can you explain how many test environments are needed for testing these features/HFs/releases etc? Looks like we need many. Please explain.
Hi, In principle you only need one, but you would need to share the environment if you want to test multiple branches. Another solution would be to test on a local machine. But the key is to script the deployment and to consider deployment scripts as part of the code, so each branch can be deployed at all times...I think it might require a whole new video explaining how all this can be achieved...
@@devchild9404 Thanks for your prompt response! I understand a little bit, but it would be really helpful if you can upload a separate video on it..
In my team, either due to bad coding or not following the best practices, we can't use the same environment for testing multiple branches as there are some dependencies like migration scripts would fail or data would get wiped off if we do reset etc.. hope you can understand what I'm trying to say..
Thanks in advance!
Thank you for the easy example 😎😎
to the point. Thanks for making this video.
Hello, thanks for the video! It was very well done. For the next part can you do a video about how to accomplish each step with Git commands? I'm a little lost on how to integrate a branch into two others. Thanks!
Excellent vidéo 👌👌👌👌👌👌👌👌
Thank you soooooooo much
Good explanation 👍
thank you , Sir ! very easy to understand
really such a great explanation !!
bro, this is great thank you
Great video!
Great video
This is very useful , thanks :D
I know this concepts are confused, but if you can organize you team, believe me, you will get an step up.
Great vid!
Really nice explanation, thanks! One comment, though: I don't think that any merge into develop branch should be merged instantly into feature branches. In fact, there is no need in my opinion to merge to feature branches at all. Maybe just once before you try to merge the feature branch back to develop. I don't see it realistic that if I'm working on a feature branch I should be aware of any other feature branches/hotfix brances/release branches merging into develop. But maybe I'm wrong.
Yes, that's correct...you don't have to merge on every commit in dev or master... but eventually you will have to. Merging often will save you from having to solve complicated merge conflicts. Some systems allow you to automate the merge whenever a commit happens upstream.
@@devchild9404 yep this will avoid any unintended surprises. This generic practice will avoid any problems ever
This is a great video, thanks
🔥🔥🔥Super, thanks a lot
Awesome vidéo, congrats !
Very well done! I wish you would have created more videos. But, if you are going to create just one, it might as well be perfection.
thanks for the illustration.
...exactly what i needed! i feel like Neo in The Matrix lol
More Please!
It is an awesome video to know about gitflow
Great!
Can anyone recommend materials for what to do when working with a service-oriented architecture and multiple repositories? Would love it if there was clear extension of this workflow to the multi-repo situation.
Thanks in advance.
Great content!
Thank you 😊❤️
muy buen video, es bastante simple
Hi @Devchild awesome video!
Could you please explain what does it mean the last green arrow at 2:24 from feature 2 to develop? if that's the end of the feature2 shouldn't the green line stop there and remove the branch? (like feature1).
Thanks in advance.
Hi,
Yes you are correct, after integration you can safely remove the feature branch, so yes the green line should have stoppen in the video. But it's not a strict requirement, you could decide to integrate multiple times from the same branch, although from a maintenance perspective it's better to delete the branch after integration.
Cool video mate
Easy and nice! Thank again.
I'm a little confused by the last green line from the branch "Feature/F1" to the branch "Develop". What is it for? Or is it just a continuation of the work? :)
The best educational.
Frecking Awesome!
Thanks!!
simple explanation
Awesome explanation! What should I do if FEATURE/F2 needs some code in unfinished FEATURE/F1 ??
Hi, it can become nasty in these kinds of scenario's, features should be independent developments, if your features require common (unstable) functionality then it might indicate that your features are too small. You could decide to merge F1 into F2 and continue development on F2 and call it a single feature. To handle this cleanly, you would first have to merge F2 into F1 and then the other way around (F1 into F2). If this isn't an option, you could also cherrypick the common code. A last option you can consider is modify the common code in its own feature branch and follow the gitflow strategy, I hope this helps... ;)
What if Feature 1 is merged back to Develop branch, and also Feature 2 is merged back to Develop. But only Feature 2 is going to be released to Production? How are you going to remove Feature 1?
Great vídeo !
awesome vidoe!!
Music name? It's so chill and relaxing
Great video! Can you hint how did you create it?
Hi, I used videoscribe and a lot of sweat :) to create this video. I hope it helps ...
Credit for the music? Lovely track :)
What tools/apps did you use to draw these nice plots?
Excelent! 2 mins!
nice and fastest one
very helpful!
Thank you for the video.
How to approach separate code bases for the feature/story? Back-end is in .NET and front-end is based on React. Each resides in it own repo. If the feature requires changes in both repos (so 2 feature branches), I guess best would be to merge both into each develop at the same time in order to have working feature as a whole. Please share your opinion.
When to integrate into the develop branch is more a question of quality than it is of dependency. Make sure your new feature does not fail when the required dependency isn’t finishes in time. I would suggest using feature toggles for this, it requires a bit of development effort, but you get a lot of flexibilty for it in return.
Anybody can say, from which branches the tester or QA will test ?
Depends on your process, if you have a testteam or tester, testing a full release, then testing based on a release branch is the way to go...if you have a tester, testing individual features, then testing based on feature branches works best.
@@devchild9404 got it. thanks
I hate my company for using this complicated workflow. I still have no idea how exactly to merge back the dev branch into my feature branch so I always have merge conflicts when I try to merge my feature branch into dev branch my colleagues have to solve for me
hi, devchild, thanks for such nice video for git. Can you tell me which tool have you used to create such animation in this video?
Can you please share the final image for print if it's ok?
Hi Khalid, it's an animation, so unfortunately there's no image of this. You might be able to take a screenshot of one of the last frames, but it doesn't look that good on print then, I think..
You need to branch out from master only for hotfix release
thanks! i cried