Pros and Cons of various git pull strategies on dev branch [closed]

Question

What are some Pros and Cons of various approaches (merge, rebase, ff only) when having a dev branch use as follows:

1. main is production connected to auto-deploy in vercel
2. dev is used to branch off of for any bug fixes or feature branches, which then get merged back into dev, then, when we want to make a release dev is merged into main for deployment.
3. Multiple people branch off dev and merge back into it, so need to keep your local dev up to date.

Answer 1

Depends how you work, myself I prefer to do a rebase when possible, that prevent having a merge commit while it is not needed.

When you have to merge, that's adding many commits difficult to track in the commit tree. Optimally you like to have something clean, with the smallest distance between your commit and the previous one.

The rebase will try to pull without your edits, and apply your edits on the top of the last commit.

local    ┌─────
remote ──┴───╸

# Rebase :
local        ┌─────
remote ──────┴

# Merge :
local    ┌────┬
remote ──┴────┴

If you do it on long term, you would end up with this:

# Rebase :
local                       ┌─────
remote ─────────────────────┴
               ↑ linear upstream

# Merge :
local    ┌────┬──┬────┬─────────┬
remote ──┴────┴──┴────┴─────────┴
               ↑ Non linear upstream

Answer 2

I recommend setting pull.rebase to true or merges. Here's why.

Merging work is significant, updating work is not.

Part of the point of version control is to help future programmers understand why things are the way they are. A merge commit retains the record that "these set of commits were done as a single unit of work" and it provides a spot to record what that unit was; a reference to a PR, for example. For that reason

But git pull is just updating the branch, and nobody will care how many times you updated the branch. If git pull merges, you've got all these extra merge commits cluttering up the history and hiding the significant merges. So do a rebase.

It's easier to resolve conflicts.

If you git pull and it merges and there are conflicts, all those conflicts have to be resolved at once. And any consequences of those conflicts will be tangled up in there.

If you rebase, conflicts come one at a time. This breaks up the problem into small chunks, you can see exactly which commit caused the conflict. And they happen immediately before more work is piled on top of them, you can deal with them before more work is piled on top of it.

It's easier to review.

If you merge, your branch is written on a moving target. Earlier commits will be written on earlier parts of the upstream code, later commits will be written on later parts of the upstream code. If a reviewer wants to look through the branch commit-by-commit, they have to keep in mind which version of the upstream that commit was written against.

Rebasing on pull rewrites your code as if it were always on top of the latest upstream version all along. This forces you to rewrite each commit to work for the same version. Now if a reviewer looks at a commit they know it is written for a single version of the upstream.