Good video. One thing that could improve this video is having the lifecycle of the branches represented by drawing the lines of the branches shorter. Doing so helps one understand that in most cases branch is created only when you need it, then delete it when it is complete.
@MB-Kajtech3 жыл бұрын
"Hopefully not usually."
@abernardo Жыл бұрын
We use the github flow strategy for 20 years now, in CVS. I'm switching to git just because it's more modern and has some advantages in speed and moving folders. Anyway I find it so funny that with some time and experience many including Atalassian have come to the conclusion that less is more and avandoned Git Flow! Thanks for the clear explaination! Great video!
@wieslawsamushonga44442 жыл бұрын
Thanks for the short and concise explanation. Keep coding. Stay Beastly!!
@vgavrilyuk3 жыл бұрын
I would not be so sure of safety of GitHubFlow, e. g. simply rollback might be not enough. Sometimes a buggy feature can make multiple changes in application data that would be incorrect and would need to be manually adjusted. Hense we use GitFlow + feature toggles. We get nice controlled releases of say 5 features and if 1 of them misbehaves we simply turn it off and let release be on prod - full spead ahead, no rollbacks!
@BooklyCrashCourse9 ай бұрын
Very well explained! Nice job and thanks for the video
@diego_samano3 жыл бұрын
The big challenge with branching workflows is your deployment/release process and of course the development lifecycle. Any approach lacks when for some reason (business rules, deprecation of any library, framework or technology, etc.) a feature needs to be rolled out or delay.
@JayTheKing1113 жыл бұрын
your branching strategy shouldn't prevent you form making feature role outs. that would indicate you don't use feature flags for delaying release of features. your branching strategy shouldn't be tied to your release model, it's intended for managing code. how you manage features to be done separately. For example, a company may merge and deploy features multiple times a day, that doesn't mean those features are "released" yet. they are "released" once beta or acceptance testing is complete, you then enable the feature for general use by all users. Another approach is to release to % of users at a time.
3 жыл бұрын
man, you're help me and my team a lot with your videos
@melissaaidee9003 Жыл бұрын
Thank you for posting this content!
@georgehelyar3 жыл бұрын
Where I work, we use trunk based development (continuous integration), not feature branches. People create short-lived branches (branches only exist locally for a few hours, and only exist remotely during the pull request), make some changes, and commit them to the main branch through a pull request. The main branch is always in a state where it can be deployed, because new features are hidden behind things like feature flags or endpoints that just aren't being called yet, and every commit into the main branch runs the automated test suite for that repository - if the tests don't pass, the pipeline does not output anything that can be deployed. When it comes time to actually release, we tag with a version number and it gets deployed to staging and then to production (we aren't quite at the stage of full continuous deployment yet)
@pilotboba3 жыл бұрын
You just described GitHub flow.
@georgehelyar3 жыл бұрын
@@pilotboba The important distinction is that there are no feature branches, and the trunk (e.g. master/main) is always deployable. Features don't have to be complete before merging into the trunk. They can still be deployed if another feature is ready to go, because they are disabled in some way. This is called trunk based development, and it enables continuous integration. One difference from the GitHub flow is that you can't deploy any branch other than the trunk into production. Those ephemeral branches might not even be up to date with the trunk if someone else has recently merged their changes into trunk. The real problem with feature branches is not branching, it's merging. The channel Continuous Delivery has some good videos on this.
@pilotboba3 жыл бұрын
@@georgehelyar Semantics. "Short Lived Branch" as you call it is nothing more than Feature Branch by another name. It's still the same branching strategy even though your commit to release workflow is a bit different. We use gitflow and we also use feature flags. All that work goes into our develop branch. You can use feature flags with either of these branching strategies. We used to use, branch for release. So each release had a branch. All the work was done on the branch and it lived for ever. This allowed us to separate the work by release. There's so many ways to skin the cat. They each have pro's and con's.
@georgehelyar3 жыл бұрын
@@pilotboba the difference is the content of the branch and the amount of time that the branch exists. A feature branch usually exists for longer, and has multiple people committing into it over at least several days, and doesn't get merged back into trunk until the feature is complete. With continuous integration, branches exist for less than a day; usually no more than a few hours, and can be merged back into trunk before the feature is complete. The branches only exist for the purposes of code reviews and running automated pre-merge checks. This stops the branches from diverging too far from each other, and reduces merge conflicts. It also makes that feedback loop faster.
I see a lot of videos being made about Git flow and Github flow, but not enough quality content on Trunk based development in conjunction with feature flags. I would love to see you do a video on this topic.
@sagi33delriego82 Жыл бұрын
Hi Nick Good Video, Now I can anderstand Git Flow Thanks so much 🙌
@mr_phamtastic2 жыл бұрын
Thanks for this video! Interesting to hear about github flow!
@renends76152 жыл бұрын
Great content, clarified my doubts!
@michael_scarn_2 жыл бұрын
Thank you Nick 🙂
@everettscott47452 жыл бұрын
Excellent explanation. Many thanks.
@tobiaskolb79033 жыл бұрын
We also evaluated GitFlow for our process but GitFlow does not handle multiple versions in the wild out of the box. One active version might work with App development but not with some desktop applications where customers do not use the latest version, because they just not bought it and are mostly fine with the previous version. But they also require bug fixes so multiple versions have to be in focus in the flow. So we adapted GitFlow to our needs, which involves picking fixes to other releases and of course develop(ment) branch.
@ecblanco Жыл бұрын
This is where the tags part applies, that's exactly the problem i'm trying to solve in my company. Tags makes sense at this point, depending of how you're handling fixes for paid/non paid customers.
@yuri4n3 жыл бұрын
I was just talking about this with a colleague right now. Universe scares me.
@mehranlabour Жыл бұрын
awesome like always!
@joelporona2 жыл бұрын
Fantastic and super educational way for explaining the differences, cons and pros! I like using GitFlow when there's no maturity or understanding from the organization on how to work with repositories and enterprise applications, but I do see the point for GitLab Flow also for some other cases.
@humairahmujawar6 ай бұрын
thank you for the explanation!
@tabliqatchi66962 жыл бұрын
Thanks, I only wish you'd shown this through a simple example too, can you please make another video and show this in action?
@eccololo8 ай бұрын
Thank you very much. This video is really helpful 🙂.
@cathalsurfs Жыл бұрын
Excellent info thanks!
@shakthifuture2 жыл бұрын
Thank you for the excellent explanation.
@balamurugansanthanaraj86422 жыл бұрын
Why we need master branch in git flow? When we release, we shall tag in git release summary from release branch and then later when incident happens, again we shall create a hot fix branch from release tag
@ryan-heath3 жыл бұрын
What I don’t like of gitflow are the multiple merge commits. This can lead to different code in the branches if the merges are not done consistently. For instance the merge of the hotfix into main can been done differently as the merge to develop. Now your main and develop are different while from the history tree it would seems as if they would be the same.
@jagannathsahu10873 ай бұрын
very clear.thanks
@a5ync3 жыл бұрын
Good content man!
@pwchr3 жыл бұрын
please elaborate for github flow when you say push to qa/preproduction. If multiple features in parallel; do you mean have a qa/preprod shared branch?
@mastermax7777 Жыл бұрын
5:10 why dont u explain why we need to merge main back to develop? It shouldnt be different since there were no commits added to Release, right? Or are you assuming there were some commits like fixes
@MrRaydedon Жыл бұрын
@nickchapsas can you please explain how will testing happen in githubflow. and where will it happen? on which branch will it happen. on which environment will it happen.
@erickgarciacosta9 ай бұрын
Excellent video!
@RohitMoni3 жыл бұрын
Thanks for the video, hadn't heard of github flow before but can definitely agree it makes a lot of sense for smaller / more isolated codebases with quicker release cycles (like microservices). On viability for different types of projects, I have a question for you: I've found that git flow (and github flow too) both work very well for a lot of products but both make the assumption that your product has a single active release stream. Some products might actually have multiple release streams going at the same time, potentially for different platforms, or operating systems, or simply because users use your product as the base for their work and don't want it changing too much underneath them. How would you modify your git branching to accommodate that?
@JayTheKing1113 жыл бұрын
you wouldn't really. git branching shouldn't be tied to how you release software. For example, we have multiple merges to master per day from features and push to production with those merges. A release only happens once a month via enabling/disabling feature flags. In your examples mentioned, releasing for different platforms can be achieved by creating github releases/tags for a point in time version of the code that is easily referenced when checking out. for those releases you create the target platform binaries or artifacts.
@kiransaravade51272 жыл бұрын
good explained
@RoboChickenAnimation3 жыл бұрын
Managed trunk based is the way to go...
@jasonfreeman80223 жыл бұрын
Git flow is helpful when you have features that may have dependencies between them. We have been using GitHub flow (also known as Git Feature Flow) but it implicitly creates an ordering problem. If feature 2 depends on feature 1 then you have to merge in a specific order. It can also create problems when QA becomes backed up. We have had features with a PR wait for literally months due to QA scheduling issues. The longer the delay, the more painful the merge and its conflicts become. This is all resolved by Git Flow (sort of). The problem in Git Flow now isn't dependencies because these are handled through the Develop branch. Now you have a problem choosing features for a release. If you have features 1, 2 and 3 in develop but only want to release 1 and 3, how do you create a release branch that only contains those features? I would love to see a discussion on how either or both of these problems are resolved.
@JayTheKing1113 жыл бұрын
This is not an attack, but probably need to solve the QA issue from the very beginning of that feature development. Involve QA as soon as possible in the workflow, get there thoughts and input. Second, dont use gitflow for feature release with CI/CD. it's crap for this use case. speaking from experience. Feature flags, feature flags, feature flags. Use them. Don't create dependencies with your feature work that slows down merging and deploying. Use feature flags to manage features and dependencies. Tie your releases to feature flags and not how you manage code. Get used to the idea of merging features into master/main but not necessarily "releasing" it to your userbase by using feature flags.
@jasonfreeman80223 жыл бұрын
@@JayTheKing111 Actually this was helpful. Thanks for the feedback.
@JayTheKing1113 жыл бұрын
@@jasonfreeman8022 No worries. 😎
@RazBuchnik8 ай бұрын
Great, but I didn't understand where staging deployment is done using the github flow. The code is merged to the main, then it's in production by automated continued delivery pipeline, or, it goes to staging and only then to production by a manual command?
@stratoschatziioannou Жыл бұрын
very interesting, man... thanx
@BGivo Жыл бұрын
Can you clarify please what you said about "main" being more inclusive? What are you including with it?
@herrwolken3 жыл бұрын
Awesome video!
@maxwilsonpereira2 жыл бұрын
Thanks a lot! Very nice!
@wahoobeans Жыл бұрын
There are two things about git flow that has been bothering me and I haven’t really found a definitive solution online yet, so any opinions help. 1. When release branch is started, should the team implement a code freeze on develop? I think no more feature branches should be merged into develop. Only merge backs from the release branch (ie bugfixes) to develop are allowed. Because if another feature branch is merged into develop after release branch has been forked, a future merge back from release branch to develop branch is going to be very messy. Ie Merge conflicts or reverting intentional changes in develop. 2. When deploying, is there a difference if we create tag from the final commit on the release branch or create a tag from master after the release branch is merged to master?
@IanWilkinson-SgtWilko3 жыл бұрын
Would be good to see a comparison to the Release flow that Microsoft use with azure. They have a blog describing the issues with GitHub flow and why they use release flow.
@AlbertoPNeto3 жыл бұрын
Hello, new here. I do not quite understand, how does the QA fit in these lifecycles? Do they simply pull the feature branches and analyze them locally? Thx for any clarification
@ddanielsandberg2 жыл бұрын
A late, quite preaching, answer because of the prevailing misconceptions and beliefs in the software industry. In general: 1. The only thing that should be tested are versioned/tagged builds coming from mainline. Do not deploy things coming from a dev/feature branch (release branches are exempt). 2. Testing should not be a separate "team" or department that gets batches of "stuff" handed to them to check. 3. Testers do NOT approve of a change. Testers should be a function of the team providing feedback so that the entire team can make an informed decision if it's good enough. Quality is not testers responsibility - it's everybody responsibility. 4. Test-automation is the responsibility of the entire team, and primarily the programmers job. 5. Quality does not come from "inspection". Or in the famous words of Deming: "Cease reliance on mass inspection to achieve quality. Eliminate the need for inspection on a mass basis by building quality into the product in the first place. Inspection does not improve the quality, nor guarantee quality. Inspection is too late. The quality, good or bad, is already in the product." 5b. Oh, I'm placing asynchronous PR/code reviews into the definition of "inspection".
@eugenepark4 ай бұрын
Release branch is cut from master HEAD commit?
@kotha168 ай бұрын
what devices you use to draw on the whiteboard?
@tanangamultiplayer20852 жыл бұрын
Great video :)
@Philinnor3 жыл бұрын
Could you do a video on Kafka or other similar tech in the context of decoupling microservices from a monolith database?
@typingcompetition3 жыл бұрын
Do you have any good strategy for Breaking Changes while using Github Flow?
@sps0143 жыл бұрын
Github Actions next please
@reddevils74243 ай бұрын
can any one explain to me why do we need to merge the main branch back to the dev branch after release merge? the main branch was literally merged way back from dev to release to main.
@michelchaghoury8703 жыл бұрын
can you make a playlist about Data Structure & Algorithms in C#
@adriansieradzan83473 жыл бұрын
We were using Github Flow for 1 year and it complicates ours work a lot in bigger ENV, we working in SCRUM. Now we are returning back to Gitflow.
@brunoccs2 жыл бұрын
Ignoring hotfixes for a second, if everything that ends up in main flows from develop, why do we need to merge main back into develop?
@elcharlydev45193 жыл бұрын
Hi Nick, I see in your videos that you use many development tools, do you have a video where I explain some of them.
@santhoshn37663 жыл бұрын
06:11 here, development branch should be merged from hotfix or master branch.? If from hotfix branch any reason for that..
@pilotboba3 жыл бұрын
Completion of a hotfix merges to Master and Develop. Completion of a release merges to Master and Develop. The only difference is a hotfix is created from Master and a release is created from develop. In both cases, once the release or hotfix branch is created, any reworks/returns for that specific planned "release/hotfix" are fixed on that branch (or PRed into that branch). This is why, when the release/hotfix is completed it is merged into both develop and master.
@lucutes29362 жыл бұрын
So how do you use the features
@ivanc.606411 ай бұрын
WHich workflow do u use dear sir?
@nielsSavantKing8 ай бұрын
@Nick. Nice explanation. But you mean with pre-production at 4:35 a test environment or an aceeptance environment?
@Lythowastaken3 жыл бұрын
One thing I hate about git is rebasing :D Especially while having a PR into "upstream/dev" and I want to rebase "upstream/dev" into my feature. Sometimes I end up with double commits or an auto merge commit like `merging feature into dev`. But sometimes this dont happen and still dont know why. I mean why does rebase creates a merge commit? Shouldn't rebase exactly don't do this?
@upgradeplans7773 жыл бұрын
You might want to check your pull behavior and remember the exact commands you want to use for that. "git pull" is a jack of all trades, it fetches, fast-forwards, merges, and rebases, depending on the situation, your config, and preferences. (I tend to avoid using git pull unless I know that it does exactly what I want at that moment.) Everything that git pull does is possible with other commands that do it one step at a time. If you just want to have an up-to-date tracking branch (what you called "upstream/dev"): you only need to run "git fetch upstream dev". If you want to rebase from the tracking branch ("upstream/dev", perhaps you know that it is up-to-date): you can use "git rebase upstream/dev". If you want to do both at the same time, then you can use: "git pull --rebase upstream dev". If you want to create merge commits manually: "git merge" I suspect that you have both a tracking "upstream/dev" branch and a local "dev" branch. What probably happens is that you sometimes do a git pull when you have your local "dev" branch checked out, but that you sometimes also do this when you have your feature branch checked out. The default behavior of pull is to do a fast-forward, with a merge as fallback. This means you can end up with merge commits in your feature branch. If you normally use fast-forwards in combination with rebases, this is likely the reason things go wrong in the way that you describe. A simple solution to prevent mistakes is adding "--ff-only" to your pull commands. This prevents the default fallback to merges and gives an error. That means you can figure out if you have the correct branch checked out, without ending up with a merge commit unexpectedly. Another, bit more difficult option is to manage your local branches differently, so that you don't have this problem. Are you doing anything useful with your local "dev"? If you need to rebase often, are your feature branches too long-lived? If you have to merge often, what can be improved in your project architecture to better separate concerns? Etc.
@georgehelyar3 жыл бұрын
If you're actually rebasing, it doesn't create a merge commit, it rewrites history. However, I think if you use a tool to commit your pull request, it might merge multiple commits into a single commit in the target branch. Rebasing is great, as long as you're the only person working on a particular branch. You shouldn't rewrite the history of a shared branch. I use rebasing when I have submitted one pull request for review, and the next change depends on it. I create a branch, work on it, submit the pull request, then branch off it again locally, and keep working on it. Once the first pull request has been accepted, I use an interactive rebase (git rebase -i) to drop the commits from the first branch, and only keep the commits from the second branch, and then when the second branch is ready, I submit a pull request for the second branch, which only contains those commits. Doing it this way never creates a nasty merge commit, where it starts tracking changes to files that I haven't even touched. If there are any conflicts, you resolve them during the rebase, and they get written into those commits directly.
@georgehelyar3 жыл бұрын
@@Lythowastaken actually, what you're describing does ring a bell. I have seen this before when people have accidentally committed something into their local copy of the base branch, and then couldn't push it because of a remote policy, so put it in the right branch but never removed it from their local copy of the base branch. Try something like git fetch git checkout dev git reset --hard upstream/dev git checkout yourbranch git rebase -i dev git push -f You could also try git fetch upstream dev:dev before rebasing as your standard procedure. I alias these two together (except I generally have origin/master not upstream/dev). You can view the branch tree as a graph with: git log --graph --oneline --decorate --branches --tags (I alias this to "git graph") If you can try to keep this to a single vertical line for the base branch, plus a line for your local branch, it will be easier to work with git.
@upgradeplans7773 жыл бұрын
@@Lythowastaken "git rebase" never creates a merge commit. What can happen is that you get a rebasing conflict, but you should get a quite clear message telling you what you need to do in that case. If you didn't run git pull or git merge, then git is unlikely to have created a merge commit. (I can think of a few convoluted ways to create merge commits without pull or merge, but those are probably not what you are doing here.) If you make sure to never run git pull without "--ff-only", then you will not have unexpected merge commits. It might give you errors when you don't expect them, but that also means you will have found the source of the problem. (A rebase can reorder commits if there are duplicates, meaning that a merge commit could rise to the top of your history when it was wasn't near the top previously. But if the merge isn't created in the first place, then this won't happen either.)
@ryan-heath3 жыл бұрын
@@Lythowastaken you need to push the 17 other commits too, they were not in your feature branch yet. That’s why you see them too, although you didn’t created them.
@elita1852 жыл бұрын
Great video! We are looking to implement GitFlow on our frontend project. In general, where do you suggest to implement PR's? In your video you talked about using a PR to merge a feature branch into develop, but are there other places you think it would be good to do this? For example for merging the release branch into master/main?
@CripplingDuality2 жыл бұрын
This is what we do in my team . I like it but it does slow things down. You have to decide what is valuable to your organization. For us, as a bank, velocity is not as important as compliance, so it's okay to slow things down a bit.
@JohnnyYeip2 жыл бұрын
Great video! Does anyone know what. software is being used to draw the diagrams?
@ecblanco Жыл бұрын
Microsoft Whiteboard.
@Sebastian-zs8cp2 жыл бұрын
what types of flows are there in total ?
@WorthyVII2 жыл бұрын
Wait, what you descibed at the beginning with 2 people commiting to one branch like that, is exactly what Continous Integration is....
@onlypiku3 жыл бұрын
Immensely helpful. Thank you! But I have a confusion. Is it called Git or is it called Git?
@pilotboba3 жыл бұрын
It's Git. {(wha???)
@SaudBako11 ай бұрын
That's just one way to do it.
@catafest-work3 жыл бұрын
good video tutorial, If you want my opinion another good video tutorial is arrays in C# - many changes for one version to another and new features like ArrayList ...
@metaltyphoon3 жыл бұрын
Git rebase master race ! Hate that GitHub rewrites your hashes even tho you told it FF only.
@msal2 жыл бұрын
What's funny is we started off with Git Flow and then slowly moved more into GitHub Flow without realizing it 😂
@ddanielsandberg2 жыл бұрын
"If we use a complex branching/merge/release process it means we are professional, right? RIGHT?"
@utkaldiary396 Жыл бұрын
Hi
@christerjohanzzon2 жыл бұрын
Real programmers and developers commit straight to main! ;)
@sumabich721 Жыл бұрын
Don't you love how this inclusive language actually makes our language more exclusive and requires disclaimers so learners don't get confused? Sure is inclusive though.
@henson2k2 жыл бұрын
In GitHub flow there is a struggle when to commit feature to main. It's either too early (before going to production) or too late (after going to production). It seems like there is NEVER a good moment to do that.
@mac19999x3 жыл бұрын
main? You mean master?
@harag93 жыл бұрын
No, it was renamed last year to main as the default now, to get away from all that "slave/master" type of look. It's also known as trunk in SVN.
@mac19999x3 жыл бұрын
@@harag9 was it? Must have not stuck cause im still seeing master around github, bitbucket, and azure devops repos and marketing material.
@Denominus3 жыл бұрын
@@mac19999x Github and Gitlab have transitioned to main as a default (but can be overridden), they are using their influence to force the issue. Existing repos remain unchanged. The Git CLI still uses "master" as the default (an option was added to change the default) and many Git related tools still use master. This is a breaking change, so wherever it lands, it is going to take time to stabilize.
@humbertocontreras3 жыл бұрын
Fortunately, renaming your master branch to main branch is optional. I have no issues by using "master" and I'll keep using it until they allow it.
@MobiusCoin3 жыл бұрын
Github Flow seems like it just does away with the dev branch.
@maskettaman14883 жыл бұрын
"main" will always be a sad joke. Excellent video though
@clearlyunwell3 жыл бұрын
👍🏽
@billrob4583 жыл бұрын
What is this "main" shit? Where did master go?
@dziurkas242 ай бұрын
wow, you talk so fast xd Like-saying-the-whole-sentence-as-one-word.