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.
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.
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.
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.
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?
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.
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.
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.
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
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?
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
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".
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 ...
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.
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.
@@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.
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!
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.
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
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!
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?
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.
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.
@@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.
@@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.)
@@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.
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.
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.
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)
@@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.
@@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.
@@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.
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?
@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.
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.
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.
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.
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?
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.
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.
