![]() 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. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |