Support Interactive Rebases

Describe the feature or problem you’d like to solve

I would like to be able to do interactive rebases in GitHub Desktop without using the command line.

Proposed solution

Interactive rebases are one of the crowning features of git. They offer enormous flexibility to craft a revision history to a wide variety of specifications, and can be used to remedy almost all of the common situations engineers face after having made a mistake with git.

Additional context

This is the git/GitHub workflow I was taught by Linux kernel developers, the original purpose for which git was designed. It has a bit of a learning curve, but produces a commit history of the highest quality when applied correctly. With a bit of practice my experience has been that it actually accelerates even my initial authoring of correct software as opposed to slowing me down or distracting from feature development. The practice of decomposing my changes into correct commits and authoring helpful commit messages often reveals my own mistakes to me. I don’t recommend this workflow, however, if your goal is to hastily churn out buggy code; nor do I recommend attempting to transition to it during a period of unusual organizational stress. When the commits are clean and coherent, it facilitates code review, maintenance (especially when an engineer leaves the organization), debugging with git bisect, the use of git blame to offer context, etc. I would love to see interactive rebases supported by GitHub Desktop so that engineers who are less familiar with git and the command line can devote less of their focus to ramping up on the git CLI. In the meantime, I will encourage use of GitLens in VSCode, but that has the drawback of requiring people to either use two different editors or leave their editor of choice. I kept the explanations of the commands as a reminder of how much newcomers to git are already being asked to learn at once.

1. git checkout main (Switch to the main branch if you aren’t already on it.)
2. git pull (Update the main branch with any changes to the main branch on GitHub.)
3. git checkout -b <branch_name> (Make a new branch and switch to it.)
4. Make the pertinent changes to your task. (It’s fine to fix other things along the way within reason if desired, but put them in separate commits.)
5. git add -p <modified_file> (Select the appropriate hunks to stage from each file you made changes to, repeating as needed. This process is invaluable for self review as we are psychologically more likely to detect our own mistakes when presented with them in a different format.)
6. git commit (Repeat steps 5-6 once per logical coherent describable unit of work; all of the changes within one commit should relate to one another.)
7. git push --set-upstream origin <branch_name> (Copy your branch to GitHub. Aim for fewer than 100 to 300 lines per pull request, which is all the commits you push in one unit for review.)
8. Open a pull request to merge your branch to main at GitHub. (The output of git push contains a link to do this.)
9. Address review feedback, if any.
10. git add -p <modified_file> (This is the same as step 5, but the changes will be relative to the changes you previously made.)
11. git commit (Add the --amend flag if there is only one commit in your pull request to squash all your changes together and avoid polluting the revision history with a bunch of commits that say “addressed code review feedback.”)
12. git rebase -i main (If there is more than one commit in your pull request, you can use this command to fixup specific commits in response to your review feedback.)
13. git push --force-with-lease (Overwrite your branch on GitHub with the latest and greatest version of your branch.)
14. Once your pull request is approved, rebase and merge your branch into main using the green button at the bottom, and delete the branch on GitHub.
15. git checkout main (Switch to the main branch.)
16. git pull (Update the main branch with the contents of your recently merged pull request and any other changes that may have landed in the meantime.)
17. git checkout <branch_name> (Switch to the feature branch.)
18. git rebase main (Rebase the feature branch to ensure that you merged what you expected to; this should succeed without intervention.)
19. git checkout main (Switch back to main.)
20. git branch -d <branch_name> (Delete the local branch now that it’s merged and rebased.)

[sergiou87]

Thanks for your feedback @JKRhb!! ❤️

I’m afraid right now those features are not in our roadmap. I recommend to file issues for both features (if they don’t exist already). Getting traction on those (via 👍 reactions or comments) will make them more likely to happen, as that would mean there is an interest/need on them.

[Kurt-von-Laven]

You can rename it locally even if it is already pushed and then force push the branch. This is generally a good idea if it’s your own branch and a bad one if it’s shared (e.g., master/main). To reword a commit, presently you would have to reorder them (e.g., via drag and drop), amend it, and then reorder them back. I agree that it would be ideal to be able to reword a commit without this level of overhead.