there is a "Rebase" feature in git that updated your feature branch up to date with main branch. there is no need to merge incomplete Feature branch to Main
@a-rezhko the difference is, I want to integrate "incomplete features" to get fast feedback (on the integrated code) but of course without breaking any existing feature
good luck convincing management on this approach lol.... just work on a different branch and frequently pull in changes from the master to main to avoid merge conflict headaches down the road...
@underflowexception I believe branching strategy should be decided by the team, not by management. and the issue with "pull frequently" is: if everyone in the team only merges rarely back to "master" then there is nothing to pull frequently, right?
Aside from the clear benefits of inserting a feature toggle, I can't seem to understand why CI/CD is a problem with feature branches, why feature branches are a problem? You would still need to create branches for the granular changes you are making to the code base right? Anyway, the approach looks interesting, my only fear being that it would introduce too much redundant work, slow down the process etc In a scrum setting for example, what do you do? Create many small tickets for each step of the way? When are testers involved? Do you merge the small changes to the development branch without having your code tested? outside of unit tests ofc Am I asking the wrong questions? 😅
@ionuttiplea4666 CI on feature branches is by definition not a CI - as the code is not integrated 😉 (see martinfowler.com/articles/continuousIntegration.html) Personally I work on "master" when ever possible, submitting all small steps I do (no squashing). As to my experience this is not slowing down but speeding up the process as integration and collaboration with team is improved (more frequent merges). regarding scrum: not sure what exactly you mean - the number of commits is not related to work items from my perspective
@AboutCleanCode Yeah ... My understanding of CI was basically wrong So I get your points Hmm, directly on master, eh? Feels kind of risky, I mean how feasible is it to keep the code ready for deployment at all time? 😁 Aaand the part about scrum, well, my guess now is that the way you define the work and the process will naturally change when going for CI
While I'm all for trying different things, this approach sounds like a nightmare in practice. It's quite rare that a change is as simple as "replace this module with another module". Like, have you seen an actual production codebase?
@Mekuso8 as said in the end of the video: working without (feature) branches is my favorite way of working - the biggest code base i contribute is ~7 mio LoC 😉 see also: trunkbaseddevelopment.com
so at core, this is like trunk-based development combined with feature-flagging (?) to make the feature flag easier we use common interface that can be decoupled from implementation correct?
@m.iqbalmaulana7328 i would say: if you want to do trunk-based dev this pattern (branch by abstraction) helps making large-scale changes incrementally without breaking other functionality
@krccmsitp2884 let's assume there was no need for it in the past - and unnecessary abstractions often contribute to complexity. What I also see sometimes is that interfaces exist but those do not properly abstract the implementation details of a module
I have use this approach for really latge and complex updates. It works. Actually, there was novody among ~1000 engineers who would agree to merge huge feature into master in single merge. Even if all tests are green. So 👍
this sounds more like architecture than version control? they are not competing goals. I use hexagonal architecture (or at least my own interpretation of it). my modules are defined largely by dependency and each one already has an abstraction/logic layer that is the core of the module. the dependency or UI layers can be freely swapped out (or I can have more than one) if I needed to for each one. I do not remove the abstraction/logic layer, that is the core of each module. none of this has anything to do with git or version control though. you still use feature branches. just rebase and/or merge often to keep things up to date.
@Ashalmawia sounds like you have a clean code base and nice and modular architecture 👍😉 sounds also like you actually don't need feature branches and can easily do trunk-based development (trunkbaseddevelopment.com/) 👍😉
What scale of a code base are you working on that things are that simple? In 20 years of experience, those simple "just change a to b" literally never worked. Any worthwhile refactoring requires a breaking API change. Otherwise, it's nothing but aesthetics and preference. "I like my code in one file, it's easier to follow" vs "I like my code in multiple files, it's easier to follow."
@rumisbadforyou9670 i am working in multiple projects - the biggest one has ~7 mio LoC 😉 "replacing A with B" in the end is always easy - the hard work is getting the abstraction right. It depends how we define "breaking change", of course i am changing APIs but every submission to version control is in itself consistent, means non-breaking, means could be released.
I don't see the point in insisting on CI. Nor do I see how CI reduces the chances for conflict. If feedback from other developers on the team is the goal of CI, sounds like a waste of the other developers' time which can be better left to a feature branch pull request. Also, I would hate to be the one to deal with a merge history that is difficult to walk back in.
@YourComputer to goal of CI is that you get fast and frequent feedback from tests on the integrated code but also from your colleagues. that will be feedback on code and design when u practice code review or even feedback from your product owner when demo the partial feature being integrated in the app
@@AboutCleanCode That sounds like trying to implement Scrum on a code level rather than keeping it restricted it to a project level. Sounds like there would be less code writing and too many meetings. I find it hard to see how this would generate more productivity and not be just a greater waste of developers' time.
@YourComputer not sure how you derive that from my previous answer, it is actually the other way round: if we integrate very frequently, we get feedback very fast, can detect issues very early on and resolve them cheaper. that clearly improves productivity. for in-depth evaluation of "true CI" i recommend martinfowler.com/articles/continuousIntegration.html
@@AboutCleanCode Repeating your assertions (hype) is unconvincing to me. The notion of immediate feedback would suggest that the changes being committed are of insignificant size, otherwise you make little to no distinction from the typical feature-branch workflow. And in order for feedback to be in any way meaningful, you would have to halt all productivity until feedback is received before acted upon. Which comes off as identical to a typical scrum meeting, of which during that time you could have just continued being productive. If CI is to make itself distinct from a feature-branch workflow, the changes being made would have to be significantly smaller than those found in a typical feature branch. But to interject the notion of immediate feedback is to imply a drastic wasting of developer time. So, not only do you have scrum meetings outside of code, you also have scrum meetings inside of code (which is unsurprising considering the link you provide). Let's be honest. This has nothing to do with productivity or high-quality code, but everything to do client reassurance. The whole point of pushing changes quickly is not for the sake of other developers but for the sake of businesses giving their clients the impression that progress is being made (though it's possible that progress has only begun). But CI is being sold to developers, when developers care more about being productive than being people-pleasers. To give the impression that this benefits development is misleading. It arguably benefits how clients perceive the company, but it would be a mistake to argue that this benefits developers.
@@AboutCleanCode This video is not about git. It is about a method to split up larger changes into more granular ones which can combine with any workflow around source control. Read part of the linked article. Think of feature branches as follows: it is the local state of a project for a developer. It should not be worked on by multiple developers at once (though can be handed over). The CI on the feature branch is just the test that a developer in "real CI" would do locally before the merge. Similarly, before a merge a developer should pull in (either via merge or rebase) the latest changes on main. Then if all tests pass it can be fast-forward merged to main (just move the branch pointer). Probably it will get tested again but it needn't be, as the "local" tests are identical to the "main" ones. What feature branches allow and a pure CI workflow doesn't is committing WIP code. Furthermore, that WIP code can be handed over to another developer to work on if circumstances demand (though that should be heavily discouraged). It allows multiple eyes to review the code before it gets into main. And to make clear that the method you describe does not depend on workflow, it can also be facilitated by feature branches. The "feature"s are then just "create abstraction layer", "implement module B to be used by module X" ..., "add feature toggle for module A/B", ... .
@noname13345 😂 interested in some more background info? www.amazon.com/Continuous-Delivery-Deployment-Automation-Addison-Wesley/dp/0321601912/ref=sr_1_1 😉
Adding abstraction for the sake of avoiding source control? 🤢 1. Stop calling them feature branches. We use story branches now 2. Stop bs marketing that running CI against a branch isn’t testing it integrated. CI/CD runs on the trunk branch once the feature is integrated 3. Allow self approvals for PR’s. We should be able to integrate our changes before someone else reviewing it. No blockers Trust developers by having code review a part of the process developers are responsible for doing 4. Bad changes to trunk is ok. Not ideal. But ok. There should be mechanisms to identify and prevent it from going out 5. Squash when PR completes - clean history in trunk that maintains a full history Branches are a lightning fast way we can squash hundreds of micro-commits into one easy to see change
@jrgalyen thx for sharing your perspective 👍 i have two questions: 1. do you run tests on your story branches as well? 2. Where do you perform code reviews - the squashed commit on trunk or the micro-commits on the story branch? PS: I like point 3. 👍😉
Branches also organize the development, each new feature is clearly separate from others and commits don't pollute and mix with others on the main branch. Also merging PRs to separate branches can be done more easily with self approvals.
@AllanSavolainen I have 2 questions: how often do you merge/integrate with your team? Do you delete the "feature branch" after the feature is completed?
@@AboutCleanCode merges happen when the devs think the new feature wont break things too badly, so it varies from couple days to couple weeks. Branches are never deleted.
@mattymattffs you are right, this pattern is not Git specific BUT I do see the behavior of creating a branch "by default" esp. in the context of git (git flow, PRs, etc). With TFS for example this behavior is much more rare, as to my experience.
@mattymattffs and this is where I disagree. A branch is neither necessary nor a good solution in many cases, from my perspective - reasons given in the video 😉
@AboutCleanCode yeah, but you're just unequivocally wrong. You understand the branch just exists so you can work in isolation from other changes, right? People who work on teams don't have everyone working on master, because generally they're not complete idiots. Branches also allow for much simpler cleaner code review as well as pipelines. You're explaining a basic programming concept, an abstract internal API, and compounding that with a code merge strategy present in git. Your accent says German, so maybe you're struggling with some of the words I'm using. I'll gladly explain in German why you're wrong.
@mattymattffs I understand the purpose of a branch 😉 our fundamental disagreement is just whether it is a good idea to "work in isolation from other changes" or not. I am working with different teams in different projects without "regular feature branches" since years and almost anytime some dev creates a branch we experienced more trouble than without. The pattern explained in the video would have avoided these branches as well. Did you try working without "feature branches"? (aka trunkbaseddevelopment.com/)
@@AboutCleanCode yes, we have a code review. but I don't like any layers of abstraction that can be avoided. sure if you and your team have enough discipline can be use this type of pattern, but my practice said almost 0 team has enough. and result of that is for example Android apps. 120mb for printing hello world.
@ice2heart i see - discipline is also a topic in my experience - as a mitigation critical topics are reviewed by senior developers and software architects
do you really think poor performance is coming from abstractions? I highly doubt that if you have performance issues and you profile it that you would find it to be caused by an abstraction...
@Ashalmawia abstraction in software in a lot of cases like a big anvil in a trunk. Not the main problem, but it's not free. A lot of people think that is free and use it without thinking, like we have only one option, but in the future we probably will have some. Java people do it often
"Make the change easy, then make the easy change." - Kent Beck
unironically (and ironically), this is the way Torvals wanted us to use git
@diegoestrada35 oh really? interesting! how do you know? any source/reference? Thx!
there is a "Rebase" feature in git that updated your feature branch up to date with main branch. there is no need to merge incomplete Feature branch to Main
Squash your branch before you do this, as I find git rerere to be more trouble than it's worth.
@@yurisich "squash -merge" is when you re-intergrate your feature branch into main. You not supposed to do this with rebasing...
@a-rezhko the difference is, I want to integrate "incomplete features" to get fast feedback (on the integrated code) but of course without breaking any existing feature
good luck convincing management on this approach lol.... just work on a different branch and frequently pull in changes from the master to main to avoid merge conflict headaches down the road...
@underflowexception I believe branching strategy should be decided by the team, not by management. and the issue with "pull frequently" is: if everyone in the team only merges rarely back to "master" then there is nothing to pull frequently, right?
Aside from the clear benefits of inserting a feature toggle, I can't seem to understand why CI/CD is a problem with feature branches, why feature branches are a problem?
You would still need to create branches for the granular changes you are making to the code base right?
Anyway, the approach looks interesting, my only fear being that it would introduce too much redundant work, slow down the process etc
In a scrum setting for example, what do you do? Create many small tickets for each step of the way? When are testers involved? Do you merge the small changes to the development branch without having your code tested? outside of unit tests ofc
Am I asking the wrong questions? 😅
@ionuttiplea4666 CI on feature branches is by definition not a CI - as the code is not integrated 😉 (see martinfowler.com/articles/continuousIntegration.html) Personally I work on "master" when ever possible, submitting all small steps I do (no squashing). As to my experience this is not slowing down but speeding up the process as integration and collaboration with team is improved (more frequent merges). regarding scrum: not sure what exactly you mean - the number of commits is not related to work items from my perspective
@AboutCleanCode
Yeah ...
My understanding of CI was basically wrong
So I get your points
Hmm, directly on master, eh?
Feels kind of risky, I mean how feasible is it to keep the code ready for deployment at all time? 😁
Aaand the part about scrum, well, my guess now is that the way you define the work and the process will naturally change when going for CI
@ionuttiplea4666 as to my experience it is not risky at all IF you apply patterns like this one 😉
While I'm all for trying different things, this approach sounds like a nightmare in practice. It's quite rare that a change is as simple as "replace this module with another module". Like, have you seen an actual production codebase?
@Mekuso8 as said in the end of the video: working without (feature) branches is my favorite way of working - the biggest code base i contribute is ~7 mio LoC 😉
see also: trunkbaseddevelopment.com
so at core, this is like trunk-based development combined with feature-flagging (?) to make the feature flag easier we use common interface that can be decoupled from implementation correct?
@m.iqbalmaulana7328 i would say: if you want to do trunk-based dev this pattern (branch by abstraction) helps making large-scale changes incrementally without breaking other functionality
Why was there a concrete dependency to Module A in the first place instead of an abstraction (contract, interface)?
@krccmsitp2884 let's assume there was no need for it in the past - and unnecessary abstractions often contribute to complexity. What I also see sometimes is that interfaces exist but those do not properly abstract the implementation details of a module
I have use this approach for really latge and complex updates. It works. Actually, there was novody among ~1000 engineers who would agree to merge huge feature into master in single merge. Even if all tests are green.
So 👍
this sounds more like architecture than version control? they are not competing goals. I use hexagonal architecture (or at least my own interpretation of it). my modules are defined largely by dependency and each one already has an abstraction/logic layer that is the core of the module. the dependency or UI layers can be freely swapped out (or I can have more than one) if I needed to for each one. I do not remove the abstraction/logic layer, that is the core of each module. none of this has anything to do with git or version control though. you still use feature branches. just rebase and/or merge often to keep things up to date.
@Ashalmawia sounds like you have a clean code base and nice and modular architecture 👍😉 sounds also like you actually don't need feature branches and can easily do trunk-based development (trunkbaseddevelopment.com/) 👍😉
What scale of a code base are you working on that things are that simple? In 20 years of experience, those simple "just change a to b" literally never worked. Any worthwhile refactoring requires a breaking API change. Otherwise, it's nothing but aesthetics and preference. "I like my code in one file, it's easier to follow" vs "I like my code in multiple files, it's easier to follow."
@rumisbadforyou9670 i am working in multiple projects - the biggest one has ~7 mio LoC 😉 "replacing A with B" in the end is always easy - the hard work is getting the abstraction right. It depends how we define "breaking change", of course i am changing APIs but every submission to version control is in itself consistent, means non-breaking, means could be released.
I don't see the point in insisting on CI. Nor do I see how CI reduces the chances for conflict. If feedback from other developers on the team is the goal of CI, sounds like a waste of the other developers' time which can be better left to a feature branch pull request. Also, I would hate to be the one to deal with a merge history that is difficult to walk back in.
@YourComputer to goal of CI is that you get fast and frequent feedback from tests on the integrated code but also from your colleagues. that will be feedback on code and design when u practice code review or even feedback from your product owner when demo the partial feature being integrated in the app
@@AboutCleanCode That sounds like trying to implement Scrum on a code level rather than keeping it restricted it to a project level. Sounds like there would be less code writing and too many meetings. I find it hard to see how this would generate more productivity and not be just a greater waste of developers' time.
@YourComputer not sure how you derive that from my previous answer, it is actually the other way round: if we integrate very frequently, we get feedback very fast, can detect issues very early on and resolve them cheaper. that clearly improves productivity. for in-depth evaluation of "true CI" i recommend martinfowler.com/articles/continuousIntegration.html
@@AboutCleanCode Repeating your assertions (hype) is unconvincing to me. The notion of immediate feedback would suggest that the changes being committed are of insignificant size, otherwise you make little to no distinction from the typical feature-branch workflow. And in order for feedback to be in any way meaningful, you would have to halt all productivity until feedback is received before acted upon. Which comes off as identical to a typical scrum meeting, of which during that time you could have just continued being productive. If CI is to make itself distinct from a feature-branch workflow, the changes being made would have to be significantly smaller than those found in a typical feature branch. But to interject the notion of immediate feedback is to imply a drastic wasting of developer time. So, not only do you have scrum meetings outside of code, you also have scrum meetings inside of code (which is unsurprising considering the link you provide).
Let's be honest. This has nothing to do with productivity or high-quality code, but everything to do client reassurance. The whole point of pushing changes quickly is not for the sake of other developers but for the sake of businesses giving their clients the impression that progress is being made (though it's possible that progress has only begun). But CI is being sold to developers, when developers care more about being productive than being people-pleasers. To give the impression that this benefits development is misleading. It arguably benefits how clients perceive the company, but it would be a mistake to argue that this benefits developers.
@@AboutCleanCode This video is not about git. It is about a method to split up larger changes into more granular ones which can combine with any workflow around source control.
Read part of the linked article. Think of feature branches as follows: it is the local state of a project for a developer. It should not be worked on by multiple developers at once (though can be handed over). The CI on the feature branch is just the test that a developer in "real CI" would do locally before the merge. Similarly, before a merge a developer should pull in (either via merge or rebase) the latest changes on main. Then if all tests pass it can be fast-forward merged to main (just move the branch pointer). Probably it will get tested again but it needn't be, as the "local" tests are identical to the "main" ones.
What feature branches allow and a pure CI workflow doesn't is committing WIP code. Furthermore, that WIP code can be handed over to another developer to work on if circumstances demand (though that should be heavily discouraged). It allows multiple eyes to review the code before it gets into main.
And to make clear that the method you describe does not depend on workflow, it can also be facilitated by feature branches. The "feature"s are then just "create abstraction layer", "implement module B to be used by module X" ..., "add feature toggle for module A/B", ... .
So instead of one migration, you'll do three.
@bart2019 as much as possible - at least once a day. when doing refactoring probably multiple per hour
Test driven version control
🤔
@AboutCleanCode I made the same face watching the video
@noname13345 😂 interested in some more background info? www.amazon.com/Continuous-Delivery-Deployment-Automation-Addison-Wesley/dp/0321601912/ref=sr_1_1 😉
Adding abstraction for the sake of avoiding source control? 🤢
1. Stop calling them feature branches. We use story branches now
2. Stop bs marketing that running CI against a branch isn’t testing it integrated. CI/CD runs on the trunk branch once the feature is integrated
3. Allow self approvals for PR’s. We should be able to integrate our changes before someone else reviewing it. No blockers
Trust developers by having code review a part of the process developers are responsible for doing
4. Bad changes to trunk is ok. Not ideal. But ok. There should be mechanisms to identify and prevent it from going out
5. Squash when PR completes - clean history in trunk that maintains a full history
Branches are a lightning fast way we can squash hundreds of micro-commits into one easy to see change
@jrgalyen thx for sharing your perspective 👍 i have two questions: 1. do you run tests on your story branches as well? 2. Where do you perform code reviews - the squashed commit on trunk or the micro-commits on the story branch?
PS: I like point 3. 👍😉
Branches also organize the development, each new feature is clearly separate from others and commits don't pollute and mix with others on the main branch. Also merging PRs to separate branches can be done more easily with self approvals.
@AllanSavolainen I have 2 questions: how often do you merge/integrate with your team? Do you delete the "feature branch" after the feature is completed?
@@AboutCleanCode merges happen when the devs think the new feature wont break things too badly, so it varies from couple days to couple weeks. Branches are never deleted.
@AllanSavolainen weeks? 😲and does your team face a lot of merge trouble?
This literally has nothing to do with git, this is just basic software design. What a silly video
@mattymattffs you are right, this pattern is not Git specific BUT I do see the behavior of creating a branch "by default" esp. in the context of git (git flow, PRs, etc). With TFS for example this behavior is much more rare, as to my experience.
@AboutCleanCode any coffee change should be on a branch. You're compounding to entirely separate things.
@mattymattffs and this is where I disagree. A branch is neither necessary nor a good solution in many cases, from my perspective - reasons given in the video 😉
@AboutCleanCode yeah, but you're just unequivocally wrong.
You understand the branch just exists so you can work in isolation from other changes, right? People who work on teams don't have everyone working on master, because generally they're not complete idiots.
Branches also allow for much simpler cleaner code review as well as pipelines.
You're explaining a basic programming concept, an abstract internal API, and compounding that with a code merge strategy present in git.
Your accent says German, so maybe you're struggling with some of the words I'm using. I'll gladly explain in German why you're wrong.
@mattymattffs I understand the purpose of a branch 😉 our fundamental disagreement is just whether it is a good idea to "work in isolation from other changes" or not. I am working with different teams in different projects without "regular feature branches" since years and almost anytime some dev creates a branch we experienced more trouble than without. The pattern explained in the video would have avoided these branches as well. Did you try working without "feature branches"? (aka trunkbaseddevelopment.com/)
Yay, and we will have one more layer of abstraction. That nobody will remove at the end. Aaand hello the new more complex and slower app.
@ice2heart Does your team practice code review? Couldn't an "incomplete pattern" be detected during review?
@@AboutCleanCode yes, we have a code review. but I don't like any layers of abstraction that can be avoided. sure if you and your team have enough discipline can be use this type of pattern, but my practice said almost 0 team has enough. and result of that is for example Android apps. 120mb for printing hello world.
@ice2heart i see - discipline is also a topic in my experience - as a mitigation critical topics are reviewed by senior developers and software architects
do you really think poor performance is coming from abstractions? I highly doubt that if you have performance issues and you profile it that you would find it to be caused by an abstraction...
@Ashalmawia abstraction in software in a lot of cases like a big anvil in a trunk. Not the main problem, but it's not free.
A lot of people think that is free and use it without thinking, like we have only one option, but in the future we probably will have some. Java people do it often