Saving you from your Git troubles

Well Well Well

We've all been there. Learning how to program, learn about git & github, save code for free. Everything's so much fun at the start. and then BOOM. Its all over.

Let me save you this trouble of experiencing this downfall. So what do you actually need to know to save yourself from what I'm going to call in this blog, "Your Git Troubles"?

P.S. the things Im going to be talking about are helpful but I wouldn't have felt that they were useful if it weren't for the tools I was using when going through these "phases". LazyGit is gonna be life saver for you lot, it does look intimidating at first but trust me it'll change your life.

Merge Conflicts

Let's address the elephant in the room! (elephant sound effect!)

If you were expecting some magical way of resolving merge conflicts using agentic coding, vibe-coding or LLMs, let me break it to you, it's not as easy as it sounds. I know this because me and friends were trying to solve the same problem, resolving merge conflicts with soarailabs.

• • AI tools struggle with understanding context of the conflict
• • Manual resolution often faster for complex conflicts
• • Understand the codebase before using AI assistance
• • Communicate with teammates about conflicting changes

If you're interested in learning how we tried to tackle this, let me know.

Rebasing

If you want the short version: rebasing is a cleaner, better way to merge. But if you want to understand why, keep reading.

Imagine you're working on a feature branch called 'feat-login'. Meanwhile, 'main' has moved forward with commits from other teammates. Instead of merging 'main' into your branch (which creates a messy merge commit), rebasing essentially replays your commits on top of the current 'main'.

Merge puts your changes off to the side with a note. Rebase moves them straight on top. Same result, cleaner history.

Why It's Important to Rebase

Cleaner Commit History: When you merge, you get those ugly "Merge branch 'feat-login' into 'main'" commits cluttering your history. With rebasing, your commits stack linearly on top of 'main'.

Fewer Merge Conflicts: When you regularly rebase onto 'main', you're constantly resolving conflicts in small doses. If you wait until the end and merge, you might have to untangle conflicts from weeks of divergent work all at once.

• • Cleaner commit history
• • Fewer merge conflicts
• • Instant feedback on breaking changes

Cherry picking

Let me tell you when i first realized how powerful git rebase was. I was aware about this feature way before but never understood where I would personally use.

let me use the example that happened to me some time ago, which made me realize how good git cherry picking actually is. I was working on HelixDB, a graph database written in rust. I wanted to combine vector search and keyword search using their RRF reranker.

I was also writing another feature for helixdb - passing multiple params in their 'Embed' function. I wrote the Embed feature but decided it would probably be something only I use so there's no point in making a PR.

Accidentally, i checked out from the feat/embed branch to work on the RRF feature. My RRF feature relies on a lot of changes made during Embed feature work, and if thats not a feature thats going to be merged my RRF stuff wont work.

That's when I remembered git cherry picking - Apply the changes introduced by some existing commits. I basically yoinked commits from on top of the other feature branch, checked out a new branch from main and slapped those commits on to the new feature branch.

Digestive Commits

Small, focused commits are the difference between a git history you can read and one that makes you want to rip your hair out. Think of commits like saving a document. You wouldn't write 5000 words, save once, then call it a day.

If your commit message has 'and' in it, it should probably be two commits. 'Added login form and validation' = two commits. 'Fixed bug in auth middleware' = one commit, good.

Sane & Non AI PRs

Why it matters: OSS can be incredible—open-sourcing the Linux kernel helped put Linux everywhere. Yet open source feels harder now: AI-assisted coding has led to repo standards being ignored.

Small PRs: Your PR should be small and digestable. Maintainers shouldn't push it to the side because you remove 3k lines and added 7k lines. PRs with smaller changes are easier to review.

Respect the maintainers: Stop using AI to make PRs (I recommend learning about the codebase with AI and being comfortable in navigating where different parts of the project live first). That's the least you can do to respect the project you want to contribute to.

If I can tell that a PR is AI SLOP, trust me they can fs.