What is your recommended approach (merge, rebase, ff only) when having a dev branch use as follows:

main is production connected to auto-deploy in vercel
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.
Multiple people branch off dev and merge back into it, so need to keep your local dev up to date.

CodePudding user response：

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

CodePudding user response：

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.

CodePudding user response：

I normally prefer git pull --rebase. When you run git pull --rebase, your current local branch gets rebased on top of the last commit from the upstream . This will help you to achieve a linear history of changes.

When you do git pull -ff may result in a non-linear histories, by creating merge commits.

CodePudding user response：

I recommend this pipeline:

Stash the dirt files to have a clean repo:

git stash

Fetch with origin to retrieve the remote changes

git fetch origin

Merge your repo with the main branch:

git merge origin main

Then solve the conflicts if any.

Note that the two last operation can be done with git pull put it is better to split the two especially in case of conflicts.

Recover stash changes:

git stash pop

You can check your dirty changes with git status.

And then you can continue to work on your repo and eventually git add, git commit, git push...