10 posts tagged with "workflow"

Deleting a branch is a bit like taking out the trash: if you only do it in the kitchen (locally), the bin outside (remotely) stays full. To truly clean up your project, you need to perform a two-step operation.

Here is how to safely and effectively wipe a branch from existence both on your machine and on the server.

Finding a bug is like detective work-except the crime scene is your code, and the suspect is one of your last 200 commits. You know the code worked last week, and you know it's broken now, but finding the exact moment it failed can take hours of manual checking.

Enter git bisect. It uses a binary search algorithm to find the offending commit with mathematical efficiency. Instead of checking every commit, it cuts the search area in half every single time.

It looks like a tiny typo, but in Git, the difference between a slash and a space is the difference between a simple update and a complete context switch.

If you are staring at your terminal wondering why one works and the other throws an error (or moves you to a different branch entirely), here is the breakdown of the "Invisible Space" mystery.

We have all been there: you are deep in the zone, half-way through building a complex new feature, and your terminal is full of uncommitted changes. Suddenly, you get a message from your team: "Critical bug in production! We need a hotfix right now!"

The traditional response is to use git stash, switch to main, fix the bug, and then try to un-stash your messy feature branch later. But if you have complex dependencies (like node_modules or .venv) or untracked files, stashing can lead to absolute chaos.

This is where git worktree comes in. It is the professional's secret weapon for parallel development.

Rebasing is not recommended in two primary situations: when you are working on a public or shared branch and when the rebase operation would cause a significant loss of historical context.

How to Undo a Git Rebase​

Undoing a git rebase is a common task, especially if you've made a mistake or the rebase process introduced unexpected issues. The method you use depends on the state of your repository and whether you've pushed the changes to a remote repository.

Is rebase better than merge?​

Neither rebase nor merge is inherently "better"; they are different tools used for different purposes in Git. The choice between them depends on your workflow, your team's preferences, and whether you want a clean, linear history or an accurate, chronological record of events (3).

Rebasing a local branch onto a remote branch is a common workflow for keeping your feature branch up-to-date with the main development branch (like main or master) and maintaining a clean, linear commit history.

The process involves a few key steps: fetching the latest changes, checking out your local branch, performing the rebase, handling conflicts, and then force-pushing your changes if the branch was already shared.

Does git rebase affect other branches?

Yes, git rebase can affect other branches, but only if you rebase a branch that other developers have already pulled and started working from. Rebasing a local, unshared branch has no impact on other branches in the repository.

The key to understanding this lies in how rebase works. It rewrites the commit history of a branch by moving its commits to a new base. When you run git rebase, you're essentially creating a new set of commits that replace the original ones.

You want to bring your feature branch up to date with the latest main, but you don’t want messy merge commits.

The solution: rebase.

Rebase reapplies your local commits on top of the latest main from remote. It keeps your commit history clean, linear, and easy to read - especially when preparing a pull request.