Git for Beginners
by Sergey Okinchuk
When Git Cannot DecideChapter 7: GitHub: Putting It Somewhere Else
Cleaning Up After Yourself
Topic 27

Cleaning Up After Yourself

Branching

The sightings page is merged. main has the work, the site looks right, and there is a label called sightings-page still sitting in the list with nothing left to do.

Deleting it is safe, undramatic, and worth doing — because a git branch list of forty stale names is how you stop knowing what is actually in progress.

Deleting a merged branch

Remove the label, now that the work has landed
git branch -d sightings-page
Git confirming
Deleted branch sightings-page (was 6e0a95c).

Git prints the commit the label was pointing at, which is a quietly thoughtful touch: if you ever need to come back to it, that hash is right there in your terminal.

What deleting actually removes

The label. Nothing else.

The commits are in main now — that is what merging did — so removing the sticky note takes nothing with it. This follows directly from the model at the start of the chapter, and it is worth saying out loud because "delete" is a frightening word.

The safety check

Try deleting a branch whose work has not been merged anywhere and Git refuses:

Git declining to throw work away
error: the branch 'header-experiment' is not fully merged
hint: If you are sure you want to delete it, run 'git branch -D header-experiment'

That is -d doing its job. It deletes only branches whose commits already exist somewhere else, which makes it a safety check rather than a demolition tool.

The forceful version

git branch -D, with a capital D, deletes regardless.

It is the right tool for an experiment you have genuinely decided to abandon — that is a real and common situation, and there is nothing wrong with throwing away work you do not want. It is the wrong tool for "Git said no and I want it to say yes".

And if you delete unmerged work by mistake, the commits are still there: the reflog from Chapter 4 knows where the branch was, and only the label was removed. That is the second time the reflog has quietly been the reason something is survivable.

Which delete, and what happens
Work is merged into main→git branch -d · removes the label only
Experiment you have decided to abandon→git branch -D · deliberate, and fine
-d refused and you are not sure why→stop · the branch has unmerged commits
Deleted something you needed→git reflog · the commits are still there

Naming so that cleanup is easy

Short, hyphenated, describing the work: sightings-page, fix-meeting-time, add-photo-gallery. Not test, not new, not branch2, and not your own name — on a team, "whose branch is this" is answered by Git, while "what is it for" is answered only by the name.

Naming gets a proper treatment in Chapter 10. The habit starts here, because it is the difference between a branch list you can read and one you delete out of despair.

The rhythm

Branch, commit, merge, delete, then start the next branch from an up-to-date main. Round and round.

That loop is the working rhythm of every project in this book and most projects outside it. In Chapter 8 the same loop acquires a website and a second person, but the shape does not change at all.

Common Confusions
  • "Deleting a branch deletes its commits." Merged commits live in main. The label is all that goes, and Git prints the commit it was pointing at as it goes.
  • "-d refusing means something is broken." It means the branch holds commits that are not merged anywhere. That is the check working — merge it, or decide deliberately to abandon it.
  • "I should keep old branches around as a record of what I did." The history is the record. Old labels are clutter, and the commits stay reachable regardless.
  • "-D is dangerous and should never be used." It is the correct tool for abandoning an experiment. It is only dangerous as a way of overruling a warning you have not read.
Why It Matters
  • The branch-commit-merge-delete loop is the working rhythm of Chapter 8, where GitHub offers to delete the branch for you the moment a pull request merges.
  • A short branch list is what makes git branch a useful answer to "what am I working on", which on a real project is a question you ask daily.
  • Knowing that -d refuses unmerged work means you can delete branches confidently rather than hoarding them out of uncertainty.

Knowledge Check

What does git branch -d sightings-page remove?

  • The label alone, while the commits stay in the branch you merged into
  • The label and every commit that was made on that branch since it started
  • The label, plus any files that were created on the branch and not elsewhere
  • Nothing permanent, since the label is restored the next time you switch branches

Git refuses to delete a branch, saying it is not fully merged. What does that mean?

  • The branch is holding commits that do not yet exist anywhere else at all
  • The branch is currently checked out, so it cannot be removed while in use
  • The repository is in a broken state and needs to be repaired before deleting
  • The branch has been pushed to GitHub, so it can only be deleted from there

You delete an unmerged branch with -D and immediately regret it. What now?

  • The commits still exist, and git reflog can find where the branch pointed
  • Nothing can be done, because the capital-D form deletes commits permanently
  • Recreate the branch with the same name, and Git will restore its old position
  • Restore it from GitHub, which keeps a copy of every branch ever created

What is the loop this chapter has built?

  • Branch, commit, merge, delete, then branch again from an up-to-date main
  • Commit, push, review, deploy, then start the next piece of work from scratch
  • Branch, merge, branch again, and keep every branch as a record of the work
  • Edit, stash, restore, and commit only once the whole feature has been finished

You got correct