![]() ![]() Taking advantage of native Git functionality can offer a non-destructive alternative: performing a “git diff master…branch” (e.g. While a clean version history and ease of code review are important, both of these are essentially UI-level concerns, arguably better handled by development tools specific to those purposes. If overused, squashing can significantly increase the cost of finding and fixing flaws when things go awry. ![]() ![]() So while there’s nothing inherently bad about squashing commits, and tactical squashing is a valuable thing, it’s important to remember that squashing is an inherently destructive act-one that removes development breakpoints. Git as a VCS excels at helping engineers move quickly: branching is cheap, committing frequently is encouraged, and there are lots of great Git power-user features that make it very easy to recover. Part of what makes squashing a poor default practice is that it’s somewhat at odds with other things Git tends to encourage. Lack of proper version history here will make the bug harder to find and costlier to fix. Once the bug is located, the time to fix it could increase significantly, especially when the problem is non-trivial (as can be the case with more complex “structural” bugs). In the squashed version, bisect will tell us that the bug was introduced at some point in feature 4, leaving a fair amount of forensics undone if this is a large feature. The merged commit can be reverted and the bulk of the work cherry-picked into a working version in short order. In a complete history, Git bisect can more accurately narrow down the specific problem commit. The lack of granularity in the version history makes diagnosis and mop-up problematic, effectively increasing the surface area of the problem: The problem here comes when we get a “bad” commit-say, a commit that introduces an undetected bug that then makes it into production. This cleaned-up view of history does make it a bit easier to focus on larger branch events, and since these commits are squashed, each one of these “final product” features can be viewed in a repo browser as a single body of work, which can be a huge time-saver. Now contrast this with the type of detail you’d get on a team that automatically squashes all features as they’re merged in: There’s a nice level of detail here: We can see features branches walking their way toward completion, followed by a merge into the main branch. To better illustrate this, imagine a development workflow where we can see a series of iterative contributions on feature branches, followed by the merging of that work into a main branch. Obfuscating how features come into existence.Removing developmental “safety points” that can be used to locate and tactically remove any bugs that might occur.While this can definitely make for easier code review and a more visually appealing Git history, it’s also doing two problematic things at the same time: So what happens when “squash and merge” becomes policy for all incoming work, or when developers are encouraged to liberally edit their history for ease of code review? With UI-level access to this Git power-user feature, more teams are squashing commits to make code review easier and provide a cleaner-looking history in tools like gitk or SourceTree.īut squashing for the sake of creating a cleaner history comes along with some non-trivial downsides that are often overlooked. Since the introduction of GitHub’s awesome new “squash and merge” functionality, there’s a whole lot more squashing going on. ![]()
0 Comments
Leave a Reply. |