As a junior front-end developer, my initial thought when asked to study extensively on version control was, "How hard could it be?" Create a branch, write code, commit, push, and then raise a pull request—simple, right? Well, I quickly realized that version control has its pitfalls, especially if you don’t fully understand how it works. Here are some lessons I learned the hard way that may help you avoid similar mistakes:

1. Always Pull from the Main Branch

If you push your code and notice that your changes aren’t reflected or that you're missing some updates, you probably forgot to pull first. Trust me, I learned this the hard way! Before you start a new branch, always pull the latest changes from the default/main branch to ensure you're working with the latest version of the project. Failure to do so can result in missing key components that your task may depend on and, worst of all, merge conflicts later.

2. How do branches work exactly?

I once attempted to revert a hero section ui by switching to an older branch and pushing, assuming the old design would return with the push. But nothing changed! It felt like trying to unlock a door with the wrong key — no matter how hard I tried, it just wouldn't work. What I didn’t understand was that branches are independent lines of development, which serve as pointers to commits. So switching to an old branch would only point to the project history recorded in that branch. To effect changes, one must compare and merge with the main branch properly.

3. git stash and git stash pop are Lifesavers

Ever forget to switch branches and accidentally make changes on the main branch? Yep, that happened to me. But git stash saved the day. It temporarily stores your changes, allowing you to switch branches and apply the changes later with git stash pop. git reset HEAD is another powerful command to undo changes in case you realize you messed up.

4. Handling Divergent Branches

Divergent branches occur when the histories of two branches have different sets of commits that do not share a common base. When branches diverge, choosing how to reconcile them is crucial. Please opt for git config pull.rebase false (merge) over git config pull.rebase true (rebase) or git config pull.ff only (fast-forward only) — a tip from a senior dev!. It is a safer option to preserve the history of all commits and have a record of all merges.

5. Organized Commits Are Key

This isn’t directly about version control, but well-organized commits make git log incredibly helpful. Don't wait until you’re almost done to make one huge commit. Break your work into smaller, meaningful commits. If you're setting up the UI, commit. Consuming an endpoint? Commit again. Make each step trackable; especially for times when you might need to revert.

6. Use .gitignore Wisely

Some files and configurations (like sensitive credentials) should be excluded from version control. Make sure you have a proper .gitignore file to avoid accidentally pushing sensitive or unnecessary files to the repo. You don’t want to expose secret API keys or clutter your repo with logs.

These are just a few version control tips from my experience as a junior dev. They’re by no means exhaustive, but I hope they save you from some of the mistakes I made. If you have any other tips or pitfalls to avoid, feel free to share them with me!

"How Confusing Can Version Control Be?"