5 ms·

There are two different methods to merge pull requests in the article. When do people prefer one over the other? Are there any good reasons why someone should

• deleted 9y ago
  [deleted]
• mpetrovich 9y ago
  I personally prefer merging via squash since it keeps a linear commit history without polluting the history with tons of intermediate work-in-progress commits. A linear history is helpful when debugging since it makes git bisect a lot easier. Having individual PR commits in the history makes git bisect useless since it’s unfortunately common for individual PR commits to leave the system in a broken state.
  • u801e 9y ago
    > I personally prefer merging via squash since it keeps a linear commit history without polluting the history with tons of intermediate work-in-progress commits. How do you deal with cases where your changes require more than a single commit? Some changes are easier to review when they're separated into several logical commits rather than having one giant diff from a single commit.
    • faitswulff 9y ago
      You can rebase locally into commits that make sense and then merge normally on GitHub.
    • mpetrovich 9y ago
      The squash is only performed when merging the pull request (via GitHub’s merge button on the pull request). The actual work is done and reviewed as individual commits. The nice part of this workflow is that the changes are all squashed into a single commit in the trunk, but there’s always a link to the pull request where you can see the individual commits pre-squash.
      • mnsc 9y ago
        Does the individual commits pre-squash still exist in the repo or are they only saved in the PR, ie. duplicated and saved somewhere in Github's infrastructure?
        • jmuhlich 9y ago
          Yes, the original individual commits are kept alive and never garbage collected from GitHub's copy of the repository. You can get back to them on the website via the "Commits" tab of the PR. Local clones won't contain those branches though unless you explicitly fetch them.
    • gonewest 9y ago
      I deal with that by keeping the separate logical commits, like you said, and I squash only the commits that don't add any historical meaning (like "fix a typo" or "forgot to update the changelog"). I put the issue number in the comments so you can view the history and see a group of commits are all related to a single issue.
• CJefferson 9y ago
  Some people like a linear history. Personally I don't, because it produces commits which have "never existed", and have certainly never been tested to check they even compile.
• rahkiin 9y ago
  I have found that rebasing often creates more issues than it is worth it. Only when there are only a couple of commits I might try but you are still rewriting history: something that is destructive and needs force-pushing which I almost always disallow. Merging does create a merge commit which is sometimes annoying (when you are merging a single-line commit, for example). It does however preserve full history.
  • u801e 9y ago
    > It does however preserve full history. Frequently, I see a commit history like: Implemented feature Forgot semi-colon Fixed syntax error Addressing review comments Removed unnecessary method History like that, other than the initial commit, is not very useful. It makes more sense to rebase to clean up the commit history such that it becomes a logical series of commits, which can then be viewed via git log or git blame.
  • foo101 9y ago
    Why would rebase require force-pushing? You can always rebase the pull request on the most current master. There would be no conflicts then and no need to force-push. If the push fails because the master has changed during the few minutes you spent in rebasing, just rebase again on the most current master and push again. No force-push is required.
• u801e 9y ago
  > Are there any good reasons why someone should try to rebase and merge (fast-forward) a pull request to avoid a merge commit? I've always thought of it as a way to effectively create a branch, do your work, and fast-foward merge it back in to the main branch without having any other work included in it. To put it another way, let's say you create a fork, do your work, and in the interim, several other contributors do the same thing and merge their work back into the main repo. Now, you could merge the mainline back into your fork and have a merge commit in your private branch that shows the changes that the other contributors made since you created your branch, or you could merge your branch back into the main branch at the end and have it show that it branched off earlier than the current head of the main branch. In the first case, you now have a commit that shows changes that you didn't actually make. In the second case, it shows that you didn't base your work on the latest version of the main branch. In contrast, if you rebase and only merge your work into the main branch via a fast-forward merge, your branch will only show commits that you made and it will effectively show that it was based on the latest version of the main branch before it was merged back in.
• tedmiston 9y ago
  IMO rebasing is always worth it. Commit history is read more than it's written. For community projects, squashed focused PRs that are rebased are simplest for everyone else besides the author.