![]() You do like tons of dead feature branches. You don’t agree? Well, maybe I was wrong. On the contrary, it’s very useful after years of active development. The point here is, the verboseness in rebase mode is not a bad thing. For instance, if I realize that I’ve made a wrong technical design decision, and decide to revert some commits, it makes sense to let my cooperators know why and in what condition it doesn’t work. But not every detail is meaningless and should be thrown away. That’s why git commit -amend, git reset or squash and drop options in git rebase -interactive were designed. These mistakes could be dropped because they don’t provide helpful information along the time. Some of them are meaningless, such as typos, or forget to switch branches. Wrong decisions, wrong codes, wrong commits, wrong everything. It is important to retain the development details. In rebase mode, details are retained at the cost of “verboseness”.In squash mode, details are gone with the feature branch.In merge mode, an ugly sideway out-and-in, barely changes. ![]() To keep the repository clean, we may routinely delete the merged branches. In squash mode or rebase mode, these branches are isolated and inactive after PRs get merged. There could be hundreds of frustrating feature branches. In rebase mode, all commits are added onto master branch individually, a little verbose.Ĭonsider a project that has been developed for months.In squash mode, changes are combined into a single commit on master branch, looks quite neat.In merge mode, an ugly sideway out-and-in retains all details in developing the feature.To be clear, I tagged each PR merge with its PR number and merging mode. It’s not my fault.įirst off, let’s give all three modes a try with pull requests #1, #2 and #3. I am Chinese and I wrote this post in English. Rather, I’d try explaining why I think there should be only one true (or no) option – the merge mode.Īfter being heckled by so many pathetic people who consider English as a privilege of westerners, let’s make this clear. I’m not going to repeat how they work under the hood. Each is described very clearly in the official doc “ About merge methods on GitHub”. ![]() The post is opinionated! GitHub provides three different modes for PR merging. You can check out any time you like, but you can never leave. ![]()
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |