I'm only nine days into a new job and accidentally force-pushed over a coworker's branch after half-remembering a tutorial that made force-pushing sound like a general fix. We recovered the work from their local copy, and nobody got angry, but the silence during standup was rough. So far I mainly understand add, commit, and push. What concepts and commands should I learn next, and how can I practice branching, merging, and rebasing without putting shared work at risk?
5 Answers
Learn the basics thoroughly before worrying about rebase: branches, merging, fetching, pulling, remotes, conflict resolution, and how to inspect history with commands like git log and git diff. Whether rebasing is preferred depends on your team’s workflow. Some teams use it for short-lived feature branches to keep history tidy; others mostly merge. Never rewrite a shared branch just because a tutorial suggested it—ask the team first.
A good practice routine is to create a small local repository, make several branches and commits, merge them, introduce a conflict, resolve it, then try an interactive rebase. Keep a backup branch before each experiment and use reflog to inspect what happened. That turns Git from a set of scary incantations into something you can test safely.
If you genuinely need to update a branch whose history you rewrote, --force-with-lease is safer than --force because it refuses to overwrite remote commits you haven’t seen. But it is not a permission slip: it still rewrites history and can still disrupt teammates. Avoid it on main or other shared branches unless your workflow explicitly requires it and someone has approved the change. Also, don’t use a force-push as a substitute for understanding what went wrong.
The safest protection is still branch permissions and a team process that prevents force-pushes to important branches. A command-line safeguard helps with race conditions, but it cannot make history rewriting harmless.
The best next step is to ask a teammate or mentor to walk through the project’s branching rules. Learn where feature branches come from, how pull requests are updated, when to merge versus rebase, and what commands are safe on shared branches. If you are unsure or only half-remember a command, pause and ask before running it. A healthy workflow should also protect important branches so one mistaken command cannot overwrite everyone else’s work.
Don’t beat yourself up too much—most people have made a Git mistake. Start by building a mental model: commits are snapshots with parent commits, branches are movable references to commits, and a rebase creates new commits on top of a different base. Practice in a disposable local repository where you can intentionally create conflicts and recover from them. Before experimenting on real work, make a backup branch, and remember that git rebase --abort can cancel an in-progress rebase. git reflog is also useful for finding commits that seem to have disappeared.
Exactly. A rebase is not inherently dangerous, but rewriting commits that other people are using is disruptive. It’s usually fine on your own unpublished branch, while shared branches should generally be protected from force-pushes.