Pull Request merging strategy

[danielpza]

Pull Request merging strategy

[sQVe]

Closing this as I think we've established a strategy for our PRs.

[kiprasmel]

What I do myself & highly recommend too:

Use feature branches for features
Once the feature is done, rebase it to origin/master
Then merge it into master with --no-ff to intentionally create a merge commit.

This produces a very clean commit history - you know which commits came from a specific feature branch, and which ones were commited straight into master.

Take a look at my recent project as an example -- https://github.com/sarpik/turbo-schedule

The workflow looks as follows:

git checkout master
git pull
git push # do not have unpushed commits

git checkout -b feat/my-dank-feature
# develop
# commit
git fetch
git rebase -i origin/master
# rebase interactively - you can even rename the commit messages to comply
# with semantic versioning via REWORD etc.

# either

# a) merge via
git checkout master
git pull
git merge --no-ff feat/my-dank-feature

# or b)
git push -u origin feat/my-dank-feature
# and create a PR & merge it from github
# (without additional rebasing/squashing, since we've already rebased)

# I highly prefer the b) approach - by creating a PR, you get additional benefits -
# you can later link to it, see the commits & changed files more clearly, discuss etc.

and that's it!

Also, I'd recommend ditching the develop branch for projects that do not have bigger teams & do not require multiple change previews before merging into master. It just slows you down, your hotfixes, releases & the synchronization between the master & develop branches becomes a mess, and the whole commit history becomes wrangled & unclear.
In the workflow example above - you automatically avoid the develop branch, since you're only creating feature branches straight from master.

---

P.S. The commit log is produced via git lg:

[alias]
	lg = log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit

(~/.gitconfig from https://github.com/sarpik/voidrice/blob/master/.gitconfig)

[danielpza]

I was aiming for something like this, it is what I use on all of my personal projects and it is imo cleaner and straightforward, no develop, just a master branch

notice PRs closed with squash merge have a #PR number in the commit

[sQVe]

I agree that we should squash in cases where PRs do not use conventional commits or the commit messages does not make sense.

In cases where the PRs is using conventional commits correctly I would prefer to simply merge instead of rebase as it gives a clearer tree of what actually happened.

Why are you preferring rebase over merge in that case. Is it just to keep the structure flat?

[danielpza]

Yes, just to keep the structure flat, I've use it in my workflows it it seems really nice, however I can see why you wouldn't want to do a rebase.