Techniques to make rebasing less of a headache

I often see developers merging main into their feature branches and opening pull requests (PRs) that include commits from other branches. This practice leads to “git spaghetti,” which has several consequences:

• It complicates the commit history
• It increases the risk of conflicts which are hard for others to resolve
• It can introduce changes that are not ready for main
• It hinders code review, as extraneous changes can distract from the core purpose of the PR

Soft Reset Before Rebasing #

Use git reset to rewind to the point where your branch diverged from the main branch. This keeps your changes intact in the working directory, ready to be committed in a cleaner, more organized manner.

git reflog  # Identify the divergence point
git reset commit_sha  # Soft reset to this point

Advantages: #

• Retains your changes in the working directory
• Simplifies the rebase process by reducing the number of commits to manage
• Results in a cleaner, more meaningful commit history
• Less pressure to decide on a commit message because you just squash them into one

Fetch Instead of Pull #

Run git fetch to update your repository with the latest changes from the remote without automatically merging those changes into your local branch. This gives you the chance to review changes before deciding how to integrate them.

git fetch origin
git rebase origin/main  # Rebase your branch on the updated main branch

Advantages: #

• Lets you decide when to incorporate new changes from your team
• Improves understanding of new commits before merging or rebasing
• Helps maintain a linear and clean commit history