Speaker: Brian Gorman

Twitter @blgorman

Repo with all commands

For more, see the table of contents.

---

Note: The GitHub repo is excellent and has all the instructions/commands. I did not try to recreate them in my blog. Instead I focused on the concepts

Branching strategies

• Git Flow – main > dev > feature > developer. Good if just starting out. Not doing a lot of rebasing
• Trunk based – no long running branches, frequent checkins. More popular due to CICD
• Forking – integration repo, lieutenants and dictators. Good in super large orgs. More advanced
• While branching strategy doesn’t matter, does matter if linear commit history. (Some operations are trickier if non-linear)

Rebase and Force Push

• Rebase locally (based on remote or local branch)
• Can have orphaned commits
• Force pushing with a lease makes it safer
• May have to deal with conflicts on a rebase
• Use pull request; don’t create an extra merge commit
• Important to delete old branches to avoid confusion

Finding lost commits

• Can use GitViz (on WIndows only?) to look at graphically – https://github.com/Readify/GitViz
• git reflog –all
• git checkout <id> – puts in detached HEAD state to look at it. See double parens around commit id.

Clear local cache

• Unlikely to need. Cleans up state
• git reflog expire –expire-unreachable-now –all – expire all commits now
• git gc –prune – run garbage collection

Removing feature

• Not a problem if use feature flags
• Create a branch to keep safe the parts not changing
• Reset branch to last commit want to keep
• Create new feature branch and pick commits want

Accidentally committed to main

• Stop build as quickly as possible
• Let team know not to change or pull from main
• Create feature branch and cherry pick commits want
• Reset main hard. git push –force-with-lease
• Revert change to keep history
• Change settings on repo so can’t commit to main again :).
• (if can’t do this, can revert instead of changing history)

Someone committed a secret

• If only a local commit, delete .git and start over. If already pushed…
• If don’t need history, create new repo without history. If can’t….
• Stop all dev as doing massive history update
• Ensure all code checked in
• Use git bisect to find the first commit containing the secret (start, good id, bad id, then you keep saying if a commit is good/bad). Alternatively git log -S “secret” gives you the commit
• Ensure no branches are dependent on commit after the last good commit
• Amend commit with one that doesn’t have the secret, Then cherry pick the rest
• Everyone has to get the repo again since commits have changed

My take

I really like the mix of concepts, visualizations and videos of actually using the functionality. Great session.