13 ms·

I want the 'merge' function completely deprecated. I simply don't trust it anymore. If there are no conflicts, you might as well rebase or cherry-pick. If ther

I want the 'merge' function completely deprecated. I simply don't trust it anymore. If there are no conflicts, you might as well rebase or cherry-pick. If there is any kind of conflict, you are making code changes in the merge commit itself to resolve it. Developer end up fixing additional issues in the merge commit instead of actual commits. If you use merge to sync two branches continously, you completely lose track of what changes were done on the branch and which where done on the mainline.

eurasiantiger 4y ago
It is also a security risk. Someone could add whatever unreviewed code and it would get glanced over as a merge commit. Put your payload in an innocuous file not likely to be touched and call a boilerplate-looking function as a side effect from somewhere.
masklinn 4y ago
I think merge is great, having a “unit” for a feature branch being integrated is nice and not all things can be done in commits which are individually justifiable. The ability to bisect cleanly through the first ancestor is precious. I do agree that resolving conflicts in merges is risky though. It can make sense when merging just one way between permanent branch (e.g. a 1.x branch into a 2.x), but as soon as cross merges become a possibility it’s probably a mistake.
- losvedir 4y ago
  > I do agree that resolving conflicts in merges is risky though. How do you do otherwise, though? Or is your workflow a combination of rebases and merges? Continual rebasing of the feature branch onto `main` and then a final merge commit when it's ready to go?
  - neweroldguy 4y ago
    This is what I do unless I’m working with a large number of people on the feature branch (which is rare, usually that would be multiple branches). You get the equivalent of “mergeless” history (just restrict your git log to merge commits) but can dig into the individual feature histories easily.
  - masklinn 4y ago
    > Or is your workflow a combination of rebases and merges? Continual rebasing of the feature branch onto `main` and then a final merge commit when it's ready to go? Yes. You don't usually need "continual" rebasing, most commonly just once just before merging. In fact a good merge tool can do it for you (and refuse to merge if there are conflicts when rebasing).
danwee 4y ago
I usually do `git merge --no-ff development` when working on my feature branch. We do not leave feature branches "open/live" for too much time, so merge conflicts are not usually a problem, but sometimes they do happen. I like cherry-pick, but I barely use it (e.g., I need to cherry-pick one commit from branch X into my branch). I don't like rebase much because it requires force-push.
- cerved 4y ago
  rebase only require force push if you're rebasing something already pushed
nextlevelwizard 4y ago
If you have bunch of commits in a feature that are related it is easier to revert merges (even if you do pre-merge rebase from master and then merge with --no-ff)
rjmunro 4y ago
I usually rebase the branch onto the upstream branch (master or main or whatever) if there are merge conflicts. You can then resolve the conflicts commit by commit. This requires force pushes, but they are are not normally a problem because only one dev tends to work on a particular branch before it's merged. If you do have multiple devs working on the same branch, use `git pull --rebase` to stay in sync with each other, don't use merges and leave lots of merge commits. If you need to resolve conflicts with upstream, make sure other people have stopped working on the branch, rebase it, then merge.
simiones 4y ago
Unfortunately, git rebase has a very very annoying limitation that git merge doesn't. If you have a branch with, say, masterX + 10 commits, and commit 1 from your branch is in conflict with masterX+1, then when you rebase your branch onto masterX+1, you will have to resolve the conflict 10 times (assuming all 10 commits happen in the same area that had the original conflict). If instead you merge masterX+1 onto your branch, you will only have to resolve the conflict once. Even though I much prefer a linear history, losing 1h or more to the tedious work of re-resolving the same conflict over and over is not worth it, in my opinion.
- broeng 4y ago
  In your example, you pretty much have to change the same line, or neighbouring line, those 10 times to end in that scenario. If it's just somewhere else in the file, git auto-merging will handle it just fine. It seems like a very contrived example to me. We have been running rebase/fast-forward only for close to 10 years now, and I have never experienced anything that unfortunate.
  - ncann 4y ago
    Yeah that scenario only ever happens if you have an extremely large branch that hasn't been merged into the target branch for a long time (like a feature branch that takes months to develop), which btw isn't really something that should be done anyway (always try for more frequent merge with small side branches).
  - michaelt 4y ago
    Sounds like you've never worked on a project with a file everyone wants to append to :) If every error in your system needs a separate entry in the error enum, or every change needs an entry in the changelog - loads of changes will try to modify the last line of the file.
    - account42 4y ago
      Even multiple appends are not that bad for rebasing - if you put the remote changes before your own then after the first commit the context for your remaining commits will be the same. If order actually matters then yeah, git can't magically know where each new line should go.
GuB-42 4y ago
> I want the 'merge' function completely deprecated. I simply don't trust it anymore. Merge is perfectly fine and it is the only way to synchronize repositories without changing the history, which is very important for a decentralized system. It certainly has the potential to make a mess if used improperly, but so do rebase, cherry-pick, and basically every other command. > If you use merge to sync two branches continously, you completely lose track of what changes were done on the branch and which where done on the mainline. If you do things correctly, that is by making sure that when you merge changes from a feature branch into the mainline, the mainline is always the first parent, you shouldn't have any problem. Git is designed this way, so normally, you have to go out of your way to mess things up. If did it like that and you don't want to see the other branch commits, git-log has the --first-parent option.
- benatkin 4y ago
  Proper use of merge is table stakes. You get warned in your PR if your non-main branch is out of date with your main branch, and after you rebase and force push your non-main branch, you review the diff in the PR.
  - couchand 4y ago
    Then you don't actually need merge? Am I missing something? If you always rebase the branch, the commits can be applied directly.
    - xxpor 4y ago
      if you do this: (starting on main) git checkout -b feature do work git commit -a git checkout main git pull git checkout feature git rebase main publish code review, get approval git checkout main git merge feature You still use merge at the end, even though it's not actually doing anything that'll result in a conflict.
      - couchand 4y ago
        Totally on board (except the forbidden -a switch). The last command is: cp .git/refs/heads/feature .git/refs/heads/main No merge needed.
silon42 4y ago
Personally, I believe merging 'master' to your feature branch is the wrong model... what one should do is create a new branch from master and merge the old branch into it.
- piskerpan 4y ago
  If you’re merging (and not rebasing) it’s the same exact thing. You’re just switching the “incoming” version, but conflicts will be identical.
- dahart 4y ago
  Why? Merging master into the feature branch is done so that you can test the conflict resolution in the branch before inflicting it on everyone. It’s also done on a regular basis in longer running feature branches to prevent large conflicts from accumulating- you can merge master into your branch multiple times to stay current with master before ever merging back into master. I’m not sure why parent says this causes them to lose track of which changes happened in which branch. The history does get a bit more complex at a glance, but for any given commit, it’s easy to pinpoint their origin if using only merge commits. It only gets harder if you accidentally rebase someone else’s commits along the way. For smaller feature branches and smaller projects, it’s okay to merge branches into master, but for large branches, large projects, large teams, and teams that care about testing, merging master into feature branches is a best practice. What makes you consider it ‘wrong’?
- phailhaus 4y ago
  A merge commit is just a commit with two parents. You're not affecting the master branch at all when you "merge in master", you're just creating a new commit where the first parent is your branch, and the second parent is the master branch. If you do things the way you're suggesting, you'll make it really hard to tell what commits were made on your branch. Git clients tend to assume the first parent is the branch you care about.
bsza 4y ago
> you might as well rebase or cherry-pick Both tools are pure vandalism compared to merge. Among the two, cherry-picking is preferable in this case because you're "only" destroying your own history, so in the end, it's your funeral. > Developer end up fixing additional issues in the merge commit instead of actual commits. A merge commit IS an actual commit, in every sense of the word. The notion it somehow isn't, is what you need to get rid of.
- cerved 4y ago
  Rebasing / rerolling is completely fine if done right, no need to be overly zealous. But merges are often more elegant
BiteCode_dev 4y ago
This work if you have only experienced professional developpers in the team. If you have juniors or non devs (mathematicians, geographers, qwants...) that just happen to also code, rebase is a minefield. This is espacially true in open source contributions.
- kzrdude 4y ago
  Merge and conflict resolution is a minefield if unexperienced developers do it too. Fortunately it can (often) be arranged that those with some understanding of the issues involved can do the resolution.
  - cerved 4y ago
    you get the same, and often more, conflicts using rebase
  - z3t4 4y ago
    Always clone to another folder before merging ;)
- voakbasda 4y ago
  If you can’t rebase, I don’t want you pushing to my main branches. I would rather teach everyone how to rebase before I cave and allow merge commits.
  - BiteCode_dev 4y ago
    In a perfect world with infinite resources and no time constraints, sure.
    - antris 4y ago
      I've done several projects rebase-only with limited resources and time constraints. In fact, it saved resources and time when we did it. You have been repaid the time investment spent learning rebase commands, after once being able to avoid a really bad merge conflict.
u801e 4y ago
What I would like to see is a way to enforce fast-forward only merges along with the forced creation of a merge commit that references the same git tree as the HEAD commit of the branch that was just merged. This way, you know which set of commits was in the branch by looking at the parent commits of the merge commit, but the merge commit itself did not involve any automated conflict resolution.
- breatheoften 4y ago
  I've wanted this for awhile as well. Squash only merges, which are enforceable in github, get you close but leave you without any automated way to determine if a given branch was ever merged to main or not ...
  - cerved 4y ago
    merge is the only way to reliable determine if a branch is merged ¯ \ _ ( ツ ) _ / ¯
- wnoise 4y ago
  Yes, it is a shame that you can't combine git merge --ff-only --no-ff .
  - cerved 4y ago
    git rebase && git merge --no--ff
    - wnoise 4y ago
      (a) Because rebase is run on the branch to be rebased, but merge is run on the branch being merged to, that reverses the parents of the merge commit and puts it on the rebased branch rather than the parent. (b) Even if that were fixed, it alters the rebased branch, rather than stopping and warning in an unexpected case. I really do want the natural semantics of merge --ff-only --no-ff.
sidlls 4y ago
Rebasing is a tool of last resort, when something has so fowled up the code that merging a large-scale refactor is even more time consuming. Rebasing takes longer and is actually more prone to error because of the clunky interface. There is absolutely nothing wrong with squashing commits in a feature branch and merging that into master/main. In fact, it's generally better for the health of the repo and the mental health of developers.
- cerved 4y ago
  in my experience, rebase works great if the commits are structured and much more painful with lots of overlapping changes, say by continiusly doing _wip_ commits every hour
  - sidlls 4y ago
    I certainly am not perfect to the degree that I make a single commit or a relatively small number of “structured commits” to any branch I’m working on. Neither is anybody else (regardless of whether they think they are). Anyone who tailors their commit structure around a poorly designed tool interface is just wasting their own time, and therefore the company’s, in my opinion.
    - cerved 4y ago
      Well, I do, more or less. Whether it's a waste of time or not is dependent on how efficient you can do it, in my workflow it's efficient, and to which degree you can avoid waste as a consequence of a "messier" approach. For me, it evens out.
deleted 4y ago
[deleted]
foobarbecue 4y ago
> Developer end up fixing additional issues in the merge commit instead of actual commits. As long as the merge commit is being reviewed with the rest of the PR, that's fine, right? (We use rebase while working on feature branches, and then squash & merge for completed PRs, which seems to be the best of both worlds)
gpvos 4y ago
> If there is any kind of conflict, you are making code changes in the merge commit itself to resolve it. I don't get it. If you rebase, you get 20 chances to do the same.
- thargor90 4y ago
  Reviewing merge commits is harder because they will sometime have huge diffs to both branches. Rebasing is the process of redeveloping your feature based on the current master. This is smaller, easier steps to review later. It is a pitty that we can't have tooling to create "hidden" merge commits to allow to connect rebased branches, this would retain the history better and allow pulling more easily.
Chris2048 4y ago
I'd like a "quick ff" that will ff if there are no conflicts, or ff as far as it can with no conflicts - and an easy way to apply to many branches. Also, a way to "rebase" that works the same as cherry picking commits on top of the target. As far as I can see, the regular rebase works it's way up the target branch, so that I end up resolving conflicts in code that eventually changed in the target.
e40 4y ago
I have never had issues with merge, unless rerere was enabled. I've had some extremely surprising results recently with it enabled and I finally disabled it for good.
pnt12 4y ago
I don't understand the hate for merges, or the love for rrbaded. Let's consider what may happen using a github flow strategy (main branch, feature branches based solely on main): * If you screw up a merge, you undo the merge commit. Now your branch is exactly as it were. May not happen with a rebase. * If you push some code to the remote, and later find out it was outdated, you can merge it with main and push again: no need to force, github can distinguish what's already been reviewed and what hasn't. With rebase, you may need to push -- force, and if someone already reviewed the code they're going to be shit out of luck, as github will lose the capability to review "changes since last review", as the reference it has may have been lost. I also merge these features using squash commits, which provides a very linear history. This also saves some effort (you don't need to be rebase the commits in the feature branch, which can be a pain in the ass for unorganized people and git newbies, and you are pushed towards making smaller, granular PRs that make sense for the repo history).
palata 4y ago
What about the commit signatures? Only merge keeps them, right?

eurasiantiger 4y ago

It is also a security risk. Someone could add whatever unreviewed code and it would get glanced over as a merge commit. Put your payload in an innocuous file not likely to be touched and call a boilerplate-looking function as a side effect from somewhere.

masklinn 4y ago

I think merge is great, having a “unit” for a feature branch being integrated is nice and not all things can be done in commits which are individually justifiable. The ability to bisect cleanly through the first ancestor is precious. I do agree that resolving conflicts in merges is risky though. It can make sense when merging just one way between permanent branch (e.g. a 1.x branch into a 2.x), but as soon as cross merges become a possibility it’s probably a mistake.

losvedir 4y ago
> I do agree that resolving conflicts in merges is risky though. How do you do otherwise, though? Or is your workflow a combination of rebases and merges? Continual rebasing of the feature branch onto `main` and then a final merge commit when it's ready to go?
- neweroldguy 4y ago
  This is what I do unless I’m working with a large number of people on the feature branch (which is rare, usually that would be multiple branches). You get the equivalent of “mergeless” history (just restrict your git log to merge commits) but can dig into the individual feature histories easily.
- masklinn 4y ago
  > Or is your workflow a combination of rebases and merges? Continual rebasing of the feature branch onto `main` and then a final merge commit when it's ready to go? Yes. You don't usually need "continual" rebasing, most commonly just once just before merging. In fact a good merge tool can do it for you (and refuse to merge if there are conflicts when rebasing).

danwee 4y ago

I usually do `git merge --no-ff development` when working on my feature branch. We do not leave feature branches "open/live" for too much time, so merge conflicts are not usually a problem, but sometimes they do happen. I like cherry-pick, but I barely use it (e.g., I need to cherry-pick one commit from branch X into my branch). I don't like rebase much because it requires force-push.

cerved 4y ago
rebase only require force push if you're rebasing something already pushed

nextlevelwizard 4y ago

If you have bunch of commits in a feature that are related it is easier to revert merges (even if you do pre-merge rebase from master and then merge with --no-ff)

rjmunro 4y ago

I usually rebase the branch onto the upstream branch (master or main or whatever) if there are merge conflicts. You can then resolve the conflicts commit by commit. This requires force pushes, but they are are not normally a problem because only one dev tends to work on a particular branch before it's merged. If you do have multiple devs working on the same branch, use `git pull --rebase` to stay in sync with each other, don't use merges and leave lots of merge commits. If you need to resolve conflicts with upstream, make sure other people have stopped working on the branch, rebase it, then merge.

simiones 4y ago

Unfortunately, git rebase has a very very annoying limitation that git merge doesn't. If you have a branch with, say, masterX + 10 commits, and commit 1 from your branch is in conflict with masterX+1, then when you rebase your branch onto masterX+1, you will have to resolve the conflict 10 times (assuming all 10 commits happen in the same area that had the original conflict). If instead you merge masterX+1 onto your branch, you will only have to resolve the conflict once. Even though I much prefer a linear history, losing 1h or more to the tedious work of re-resolving the same conflict over and over is not worth it, in my opinion.

broeng 4y ago
In your example, you pretty much have to change the same line, or neighbouring line, those 10 times to end in that scenario. If it's just somewhere else in the file, git auto-merging will handle it just fine. It seems like a very contrived example to me. We have been running rebase/fast-forward only for close to 10 years now, and I have never experienced anything that unfortunate.
- ncann 4y ago
  Yeah that scenario only ever happens if you have an extremely large branch that hasn't been merged into the target branch for a long time (like a feature branch that takes months to develop), which btw isn't really something that should be done anyway (always try for more frequent merge with small side branches).
- michaelt 4y ago
  Sounds like you've never worked on a project with a file everyone wants to append to :) If every error in your system needs a separate entry in the error enum, or every change needs an entry in the changelog - loads of changes will try to modify the last line of the file.
  - account42 4y ago
    Even multiple appends are not that bad for rebasing - if you put the remote changes before your own then after the first commit the context for your remaining commits will be the same. If order actually matters then yeah, git can't magically know where each new line should go.

GuB-42 4y ago

> I want the 'merge' function completely deprecated. I simply don't trust it anymore. Merge is perfectly fine and it is the only way to synchronize repositories without changing the history, which is very important for a decentralized system. It certainly has the potential to make a mess if used improperly, but so do rebase, cherry-pick, and basically every other command. > If you use merge to sync two branches continously, you completely lose track of what changes were done on the branch and which where done on the mainline. If you do things correctly, that is by making sure that when you merge changes from a feature branch into the mainline, the mainline is always the first parent, you shouldn't have any problem. Git is designed this way, so normally, you have to go out of your way to mess things up. If did it like that and you don't want to see the other branch commits, git-log has the --first-parent option.

benatkin 4y ago
Proper use of merge is table stakes. You get warned in your PR if your non-main branch is out of date with your main branch, and after you rebase and force push your non-main branch, you review the diff in the PR.
- couchand 4y ago
  Then you don't actually need merge? Am I missing something? If you always rebase the branch, the commits can be applied directly.
  - xxpor 4y ago
    if you do this: (starting on main) git checkout -b feature do work git commit -a git checkout main git pull git checkout feature git rebase main publish code review, get approval git checkout main git merge feature You still use merge at the end, even though it's not actually doing anything that'll result in a conflict.
    - couchand 4y ago
      Totally on board (except the forbidden -a switch). The last command is: cp .git/refs/heads/feature .git/refs/heads/main No merge needed.

silon42 4y ago

Personally, I believe merging 'master' to your feature branch is the wrong model... what one should do is create a new branch from master and merge the old branch into it.

piskerpan 4y ago
If you’re merging (and not rebasing) it’s the same exact thing. You’re just switching the “incoming” version, but conflicts will be identical.
dahart 4y ago
Why? Merging master into the feature branch is done so that you can test the conflict resolution in the branch before inflicting it on everyone. It’s also done on a regular basis in longer running feature branches to prevent large conflicts from accumulating- you can merge master into your branch multiple times to stay current with master before ever merging back into master. I’m not sure why parent says this causes them to lose track of which changes happened in which branch. The history does get a bit more complex at a glance, but for any given commit, it’s easy to pinpoint their origin if using only merge commits. It only gets harder if you accidentally rebase someone else’s commits along the way. For smaller feature branches and smaller projects, it’s okay to merge branches into master, but for large branches, large projects, large teams, and teams that care about testing, merging master into feature branches is a best practice. What makes you consider it ‘wrong’?
phailhaus 4y ago
A merge commit is just a commit with two parents. You're not affecting the master branch at all when you "merge in master", you're just creating a new commit where the first parent is your branch, and the second parent is the master branch. If you do things the way you're suggesting, you'll make it really hard to tell what commits were made on your branch. Git clients tend to assume the first parent is the branch you care about.

bsza 4y ago

> you might as well rebase or cherry-pick Both tools are pure vandalism compared to merge. Among the two, cherry-picking is preferable in this case because you're "only" destroying your own history, so in the end, it's your funeral. > Developer end up fixing additional issues in the merge commit instead of actual commits. A merge commit IS an actual commit, in every sense of the word. The notion it somehow isn't, is what you need to get rid of.

cerved 4y ago
Rebasing / rerolling is completely fine if done right, no need to be overly zealous. But merges are often more elegant

BiteCode_dev 4y ago

This work if you have only experienced professional developpers in the team. If you have juniors or non devs (mathematicians, geographers, qwants...) that just happen to also code, rebase is a minefield. This is espacially true in open source contributions.

kzrdude 4y ago
Merge and conflict resolution is a minefield if unexperienced developers do it too. Fortunately it can (often) be arranged that those with some understanding of the issues involved can do the resolution.
- cerved 4y ago
  you get the same, and often more, conflicts using rebase
- z3t4 4y ago
  Always clone to another folder before merging ;)
voakbasda 4y ago
If you can’t rebase, I don’t want you pushing to my main branches. I would rather teach everyone how to rebase before I cave and allow merge commits.
- BiteCode_dev 4y ago
  In a perfect world with infinite resources and no time constraints, sure.
  - antris 4y ago
    I've done several projects rebase-only with limited resources and time constraints. In fact, it saved resources and time when we did it. You have been repaid the time investment spent learning rebase commands, after once being able to avoid a really bad merge conflict.

u801e 4y ago

What I would like to see is a way to enforce fast-forward only merges along with the forced creation of a merge commit that references the same git tree as the HEAD commit of the branch that was just merged. This way, you know which set of commits was in the branch by looking at the parent commits of the merge commit, but the merge commit itself did not involve any automated conflict resolution.

breatheoften 4y ago
I've wanted this for awhile as well. Squash only merges, which are enforceable in github, get you close but leave you without any automated way to determine if a given branch was ever merged to main or not ...
- cerved 4y ago
  merge is the only way to reliable determine if a branch is merged ¯ \ _ ( ツ ) _ / ¯
wnoise 4y ago
Yes, it is a shame that you can't combine git merge --ff-only --no-ff .
- cerved 4y ago
  git rebase && git merge --no--ff
  - wnoise 4y ago
    (a) Because rebase is run on the branch to be rebased, but merge is run on the branch being merged to, that reverses the parents of the merge commit and puts it on the rebased branch rather than the parent. (b) Even if that were fixed, it alters the rebased branch, rather than stopping and warning in an unexpected case. I really do want the natural semantics of merge --ff-only --no-ff.

sidlls 4y ago

Rebasing is a tool of last resort, when something has so fowled up the code that merging a large-scale refactor is even more time consuming. Rebasing takes longer and is actually more prone to error because of the clunky interface. There is absolutely nothing wrong with squashing commits in a feature branch and merging that into master/main. In fact, it's generally better for the health of the repo and the mental health of developers.

cerved 4y ago
in my experience, rebase works great if the commits are structured and much more painful with lots of overlapping changes, say by continiusly doing _wip_ commits every hour
- sidlls 4y ago
  I certainly am not perfect to the degree that I make a single commit or a relatively small number of “structured commits” to any branch I’m working on. Neither is anybody else (regardless of whether they think they are). Anyone who tailors their commit structure around a poorly designed tool interface is just wasting their own time, and therefore the company’s, in my opinion.
  - cerved 4y ago
    Well, I do, more or less. Whether it's a waste of time or not is dependent on how efficient you can do it, in my workflow it's efficient, and to which degree you can avoid waste as a consequence of a "messier" approach. For me, it evens out.

deleted 4y ago

[deleted]

foobarbecue 4y ago

> Developer end up fixing additional issues in the merge commit instead of actual commits. As long as the merge commit is being reviewed with the rest of the PR, that's fine, right? (We use rebase while working on feature branches, and then squash & merge for completed PRs, which seems to be the best of both worlds)

gpvos 4y ago

> If there is any kind of conflict, you are making code changes in the merge commit itself to resolve it. I don't get it. If you rebase, you get 20 chances to do the same.

thargor90 4y ago
Reviewing merge commits is harder because they will sometime have huge diffs to both branches. Rebasing is the process of redeveloping your feature based on the current master. This is smaller, easier steps to review later. It is a pitty that we can't have tooling to create "hidden" merge commits to allow to connect rebased branches, this would retain the history better and allow pulling more easily.

Chris2048 4y ago

I'd like a "quick ff" that will ff if there are no conflicts, or ff as far as it can with no conflicts - and an easy way to apply to many branches. Also, a way to "rebase" that works the same as cherry picking commits on top of the target. As far as I can see, the regular rebase works it's way up the target branch, so that I end up resolving conflicts in code that eventually changed in the target.

e40 4y ago

I have never had issues with merge, unless rerere was enabled. I've had some extremely surprising results recently with it enabled and I finally disabled it for good.

pnt12 4y ago

I don't understand the hate for merges, or the love for rrbaded. Let's consider what may happen using a github flow strategy (main branch, feature branches based solely on main): * If you screw up a merge, you undo the merge commit. Now your branch is exactly as it were. May not happen with a rebase. * If you push some code to the remote, and later find out it was outdated, you can merge it with main and push again: no need to force, github can distinguish what's already been reviewed and what hasn't. With rebase, you may need to push -- force, and if someone already reviewed the code they're going to be shit out of luck, as github will lose the capability to review "changes since last review", as the reference it has may have been lost. I also merge these features using squash commits, which provides a very linear history. This also saves some effort (you don't need to be rebase the commits in the feature branch, which can be a pain in the ass for unorganized people and git newbies, and you are pushed towards making smaller, granular PRs that make sense for the repo history).

palata 4y ago

What about the commit signatures? Only merge keeps them, right?