How do Git's branching and merging mechanisms affect collaborative workflow?

18 Eyl 22:43

Git stores a branch as just a lightweight pointer to a commit object—think of it as a movable bookmark on the commit graph. Every time you commit on a branch, the pointer moves forward to the new commit, while the old commit stays immutable. When you run `git merge`, Git finds the best common ancestor (the merge base) of the two branch tips and then does a three‑way diff: it compares the changes made on each side against that base. If the changes touch the same lines, Git can’t decide automatically and flags a conflict, leaving the conflicted files in the index for you to resolve. The usual headache comes when several people edit the same feature branch without coordinating. Since the branch pointer is shared, each push rewrites history (if you’re using rebases) or creates a long series of merge commits that can quickly become tangled. The bigger the divergence from the mainline, the more likely you’ll hit the same hunks of code, and every conflict you resolve locally has to be re‑tested by everyone else pulling the branch. A common mitigation is to keep the feature branch short‑lived and encourage “feature‑toggle” patterns or break the work into smaller sub‑branches that get merged back into the feature branch frequently. Most teams I’ve seen adopt a “trunk‑based” flow: developers work on short‑lived branches or even directly on `main` behind a feature flag, merging back as soon as a piece is complete. If you do need a longer‑lived branch, make sure to pull from `main` (or the target branch) at least daily and run automated tests after each merge to catch integration issues early. Also, enforce a code‑owner or review gate so that merges are vetted before they become part of the shared history. What about the scenario where two contributors both rebase their local feature branch on top of `main` and then push—how do you handle the inevitable “non‑fast‑forward” error without losing their work?