CODEWITHSUNDEEP
gitgithub
Jay Bazuzi
Jay Bazuzi

Reputation: 46526

How can I delete a git branch after using `git merge --squash`

For a while, I worked in with Git in this unusual way:

  1. git checkout -b feature123
  2. tiny edit, commit, repeat
  3. git checkout master
  4. git merge --squash feature123
  5. Use output of git log --oneline to populate the commit message, like this:
Implement feature 123, floobing the brob

Long, detailed description here.
    
         f5d1b77 REFACTOR: Extract Method
         1c1346e REFACTOR: Rename `A` to `B`
         63457de etc.
         884fga1 floob

I especially like the working mode of refactoring until the behavior change I want to create is trivial. At any time, if I get stuck, I can roll back to my last good commit. Reading my commit history is easy, because behavior change & refactorings are separate, and behavior changes are simple and obvious.

I picked up this habit while working at Microsoft with Source Depot. I could make a series of tiny commits to a branch and merge the branch upstream as a single commit. We had a gui tool (similar to gitk) that would show that merge commit with a + next to it. I could expand, and see the details if I wanted. Really nice. I was trying to duplicated that in Git.

GitHub would make those commit SHAs in to links to the individual commits, if I wanted to drill down to the details. However, it only does that with some of the commits, and the rest don't become links.

enter image description here

This is clearly an unusual way of working in Git. The tools aren't likely to improve around it, and other programmers are likely to be confused when they see it.

Normally, after merging a Git feature branch, you can delete it - not much reason to keep it around. But in this case, if I delete the branch, the individual commits will disappear, and you can't click through to them in GitHub. So those old branches clutter things up, even though they're not useful. How can I get rid of them?

Maybe some magic incantation of rebase?

Upvotes: 2

Views: 1502

Answers (1)

michas
michas

Reputation: 26555

As far as I understand your intention, your point is having a simple history with details as needed.

If you do a squashed merge there will (unless you add some explicit ref) be no direct way to access the original commits and git will (eventually) clean up all those unreachable commits.

Hence you need a way to store the ref of the original branch. The most natural place to do that is, well, the merge commit itself, which results exactly in a non-quashed merge.

Therefore my suggestion is doing a regular merge and filter the important commits when displaying your history, like in gitk --first-parent. This will only show you the commits on the main branch and leaves out any side branches. (i.e. the one you would get rid of when quashing your merge in the first approach.)

Upvotes: 4

Related Questions