Merge vs. Rebase Pull requests

[RafaelPalomar]

The default method for integrating pull requests in github is merge. I think we should use rebase instead because it leaves a cleaner git history without "Merge" intermediary commits like this:

8195ca7 *   Merge branch 'fix/multiple_registration_of_nodes'
        |\  
57119d9 | * BUG: Register markups display nodes
bf0459e * | Merge pull request #97 from RafaelPalomar/fix/multiple_registration_of_nodes
        |\| 
fe5757d | * BUG: Fix multiple registration of markups nodes
        |/  
ca7a20a *   Merge pull request #87 from RafaelPalomar/feature/link_distance_margin_ui
        |\  
352595d | * ENH: GUI improvements for resections
eab4596 * | Update README.md
        |/  
7fc259f *   Merge pull request #81 from RafaelPalomar/feature/extension_image
        |\  
9b65b10 | * ENH: Update information and extension image
b2c2c40 * |   Merge pull request #79 from RafaelPalomar/feature/module_icon

Instead, we would get something like this:

a67ecfd * origin/master ENH: Connect resection clipping with UI
ba19c41 * ENH: Add combined parenchyma/margin resection
60c2f4a * ENH: Add functionality for clipping out resection
25d54c4 * ENH: Add uncertainty margin functionality
009a4df * ENH: Add contributors

Slicer uses rebase for a cleaner git history. What do you think @ALive-research/alive-software?

[olevs]

I find merge much easier to use, and rebase cause problems if not used correctly: Rebase should not be used on any public branch (The Golden rule of rebasing). Than means you can't use rebase on a branch where two people work, or for a pull request in progress.
Rebase is basically a tool to rewrite git history to make it look nice, but it also require some experience to do correctly. While merge is mostly used for one specific operation, rebase can be used in many different ways, and also needs to be used in combination with merge.

If rebase is to be used by a project (with more than one person), the project needs to set up a set of rules/procedures to follow.
Atlassian tutorial: https://www.atlassian.com/git/tutorials/merging-vs-rebasing

I regularly use git history, and often want access to the incremental commits and bug fixes. When using git blame on a file you can often see why and how the different lines are added. When trying to do the same with Slicer code, I just found large "monster commits" that don't give any explanation on why the code is put together this way. My conclusion is therefore that I don't really see the benefit of a "clean" history.

[olevs]

You can always rebase the main branch into your local feature branch before sharing it with someone, but as soon as it have been shared rebase will mess up the git repos of everyone else. As I see it: Doing it correctly for a pull request or for a feature where several people work together will often require the use of several branches and a system of locking both the main branch and the feature branches.