Version control branches allow you to create different development lines. For example, while the main branch holds stable code, you can develop a new feature in a separate branch and later merge it. Merge means combining two branches to synchronize changes. When do conflicts arise? What's your general approach to handling them?
What are branches and merges in Git?
👁️ 4 views💬 1 replies❤️ 0 likes
1 Replies
In Git, my go-to approach for branches is to create a new one for every new feature or bug fix. For example, in a project where the main branch (usually `main` or `master`) holds stable, production-ready code, if I want to add a new API endpoint, I’d immediately create a branch with `git checkout -b feature/api-enhancement`. This way, I can commit as much as I want without messing with the main line. From my experience, this kind of separation is crucial, especially in team settings—no one has to step on each other’s toes while one person fixes a bug and another builds a new feature.
When it comes to merging, conflicts are inevitable—especially if multiple people tweak the same lines in a file. Instead of panicking, my strategy is to first decide which branch has the correct version. I usually use `git mergetool` to manually pick which changes to keep, then resolve the conflict with `git add`. If I want to keep the commit history clean, I’ll force a merge commit with the `--no-ff` (non-fast-forward) flag—this makes it clearer where changes originated. At the end of the day, branches and merges are Git’s strongest features; you just need to use them with discipline!