ฝัง
- เผยแพร่เมื่อ 1 ก.ย. 2018
- The Gitflow Workflow defines a strict branching model designed around the project release. This provides a robust framework for managing larger projects.
More details at:
devchild.com/the-gitflow-work... - ภาพยนตร์และแอนิเมชัน
![🔴 [TRỰC TIẾP] Tứ Xuyên (Trung Quốc) VS U20 Thái Lan | Cúp VTV9 - Bình Điền 2024 | JET STUDIO](http://i.ytimg.com/vi/bguJ41PcW0c/mqdefault.jpg)
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???? :)
First time watching a release management video with zero anxiety
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.
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! 👍
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 :)
This is one of the best that I've seen. Expecting few more from your end. Kudoss . . . .
One of the best git tutorials & very easy to understand. Appreciated your efforts.
Best video on GIT FLOW..You explained everything without saying a word in less than 3minutes..Kudosss..You just nailed it
Just to reiterate previous comments but I feel compelled to do it. Thank you for a great video. It is soo good! Just excellent.
Thank you!! So glad I found your beautiful and simple explanation! and this calming soundtrack!
Very easier explanation within 5 minutes you nailed it, appreciated keep it up.
Excellent illustration, thank 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.
Thanks much! That's a quiet simple and to-the-point explanation.
Thank you man, you make me have any idea of how works git workflow in less of 3 minutes.
Awesome video. Just answered all the questions I had in just less than 3 mins.
Beautiful video and music, thanks for creating
Concise and straight to the point. Nice.
Great video; topics pleasantly presented and relaxing to watch. Thanks!
please make more videos, this was super helpful
This man deserves your upvote and sub.
Long live Devchild. Thank you.
Pretty simple and enough, Now I'm going to understand it
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.
Exellent, simple and to the point !
This is so perfect....wow..thanks for explaining it like this!!! God bless you!!
Well that was extremely helpful and also... weirdly beautiful. Thanks for that.
I never ever watched such a cool video !! Awesome ..
This is so clean. Thanks!
I got this video referred to me by some org. Well done. awesome information,
Wow Short & Sweet clear explanation
Awesome explanation! Thanks!
Thank you.. this video can explain better than others
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 video devchild
really such a great explanation !!
thanks for the illustration.
awesome drawing awesome explanation. awesome video
Nice video!!! Congrats.
thank you , Sir ! very easy to understand
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.
Awesome vidéo, congrats !
Great video!
This is a great video, thanks
bro, this is great thank you
Great content!
Good explanation 👍
This is very useful , thanks :D
Frecking Awesome!
Thanks!!
anybody who knows deeper understanding can summarize it best. this is it.
Thank you for the easy example 😎😎
Cool video mate
Great vid!
Great tutorial
It is an awesome video to know about gitflow
to the point. Thanks for making this video.
Best explanation ever
It was useful. Thank you.
Great video
very helpful!
🔥🔥🔥Super, thanks a lot
awesome vidoe!!
...exactly what i needed! i feel like Neo in The Matrix lol
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 😊❤️
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.
The best educational.
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?
More Please!
What tools/apps did you use to draw these nice plots?
muy buen video, es bastante simple
simple explanation
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.
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? :)
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.
thanks! i cried
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... ;)
thanks
Dope
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
Excelent! 2 mins!
I know this concepts are confused, but if you can organize you team, believe me, you will get an step up.
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 ...
nice and fastest one
Just one question: What to do with feature branches once they are dead? I mean, when you are sure are not going to use it anymore.
Delete them.
Music name? It's so chill and relaxing
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?
Credit for the music? Lovely track :)
I've been using this for 3 year in my previous company, unfortunately I left, and now Im in a new company and we're just 2 developers. Unfortunately, my colleague doesnt agree to this design, how can I convince? The fear is on develop branch getting messy and git might produce bugs and delete codes, I dont know how to argue with him because he has 10 years experience and I just have 6,
right now, we keep on rebasing our feature branch against master. It looks clean but if the PR are getting too many, it's kind of a hassle to rebase them everytime a new merge is done. so frustrating.
Hopefully somebody can help me. Thanks in advance for that. What if you developed an issue, put it into release, and the customer tests it and founds a bug that is pretty nasty. Because of the severity of other developed issues, you decide to go live with all of the issues...except the one that flawed! Is that possible in this workflow? I'm asking, because I am developing on an application where all previous developers moved away to other jobs. And the application is very unstable. So it is common I develop something and something else falls down because of it. Thanks all.
Hi Maarten, somehow I missed your question, I'm sorry about that...a branching strategy won't protect you against unstable applications. "A fool with a tool is still a fool" as they say, I would suggest writing unit tests for all new code you write, at least you'll have some confidence these bits won't break in the future. Also, be one step ahead of the frustration your clients might feel. Invest in features that inform you about issues instead of having to rely on users having to report issues.
Would a hotfix not need to be merged into the release branch also?
Yes, if a release branch (or multiple release branches) exists at the time of hotfixing, then you should integrate and merge with all downstream branches, that might not be that clear from the video
Devchild cool, thanks! Great video
I think, Dev Child is correct in the video. Hot fix need not be merged to release UAT test in release branch should start after QA test in DEV branch. Also UAT takes lots of time, can't take that risk during hot fix. For that we have bug fix.
You need to branch out from master only for hotfix release
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..
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
like!
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
What happns if if one of the feature get aborted,but as its merged into devlop devlopers will take that feature and devop.How to tackle this?
How do we ensure this video stays forever for future references...
1. Merging everything back to feature branches makes no sense. When you integrate a feature to the develop, you can delete the feature branch, it is no longer needed.
2. Bugfixes are done on bugfix branches which merged back to the release like the feature is merged back to the develop.