The latest articles on DEV Community by Kevin Gida (@kevingida). https://dev.to/kevingida https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F1211386%2F3d0088d5-4b68-495f-a39b-e0e92a220693.png https://dev.to/kevingida en Kevin Gida Thu, 16 Nov 2023 14:43:37 +0000 https://dev.to/kevingida/trunk-based-development-tbd--2o48 https://dev.to/kevingida/trunk-based-development-tbd--2o48 <p>This post will cover a basic of Trunk Based Development.</p> <h3> What is Trunk Based Development? </h3> <p>The easiest way to explain TBD is we have one single branch (usually <code>main</code> branch) with open access to it, and every developer work directly on that branch.<br> With this approach we embrace Continuous Integration, prioritize agility and fostering collaboration. </p> <h3> Pros : </h3> <ul> <li>Always release ready</li> <li>Minimize merge conflict</li> <li>Quick iteration</li> <li>Encourage small batches of work and CI/CD</li> <li>Create robust code by encouraging refactoring</li> <li>Leaner codebase</li> </ul> <h3> Cons : </h3> <ul> <li>Requires discipline and communication among developer</li> <li>Relies on a lot of automatic testing</li> <li>Not ideal for larger projects</li> </ul> <p>Separate deployment from release. The idea is we are comfortable to deploy partially completed feature into production that is not yet “release” in a sense of available for people to use.There are many start with this type of release, But these are the 3 most common:</p> <ol> <li><p>Dark launching<br> We are deploying features that don't affect the end user or people can't see yet. For example it could be a piece of code that is not used yet, or we build the backend for some feature before adding the UI at the end.</p></li> <li><p>Branch by abstraction<br> Great technique to release big changes incrementally. Improve the abstraction in our code step by step to make cleaner interfaces overtime to improve its modularity. THEN, start to replace small component in our system with new one over many deployment and release</p></li> <li><p>Feature Flag<br> We hide a new incomplete feature behind a software switch or flag. We continue to develop a new feature behind a flag, and when it's ready to release we flip the switch.</p></li> </ol> <h3> Git tips : </h3> <p><code>git pull -r</code><br> This command makes sure the latest changes from origin are fetched before rebasing on top of them.</p> <p><code>git stash</code><br> Helps you with this by stashing your changes locally.</p> <p><code>git rebase</code><br> Git rebase (opposite to Git merge) integrates changes from one branch onto another by moving or reapplying commits to the tip of the target branch, creating a linear history.</p>