Some merging rules to make collaboration easier through repository order. Think of rebasing as updating the context in which you write your feature, see also: https://gonzalo-bulnes.github.io/blog/gardening_with_git/context-from-scratch.html

safe_merge.sh

# safe merge
#
# merge the branch XXXXXXXX-add-example-feature into master

# make sure the feature is properly tested and
# doesn't break anything in its original context
git checkout XXXXXXXX-add-example-feature
rake # the test suite MUST NOT raise any error

# make sure your local copy of master is up-to-date
git checkout master
git pull origin master # MUST be fast-forward, if not do abort

# keep a copy of the original feature context in origin
git checkout XXXXXXXX-add-example-feature
git push origin XXXXXXXX-add-example-feature:spike-add-example-feature

# keep a local backup too
git branch XXXXXXXX-add-example-feature-backup # do not switch to that branch, just create it

# update the feature context with the newest master changes
git rebase master # may raise conflicts, solve them as they appear

# make sure the feature doesn't break anything in the master context
rake # the test suite MUST NOT raise any error

# if necessary, fix the errors and commit them until there are no more errors

# update the remote copy of the branch to update the PR (pull request)
git push origin --force-with-lease XXXXXXXX-add-example-feature

# Since the rebase modified the commits hashes, if you don't force the push it will be rejected.
# That's an expected and it's one of the few cases where forcing things doesn't reflect an issue. 

# merge the branch
git checkout master
git merge --no-ff XXXXXXXX-add-example-feature # note the --no-fast-forward option

# The --no-fast-forward option ensures a merge commit is created,
# without it there is no way to know where the feature started or finished.
# This option must be provided because the branch IS fast-forwardable (that's the point of the previous steps)

# make sure nothing bad happened during the merge (should not)
rake # the test suite MUST NOT raise any error

# update the remote copy of master (close the PR automatically)
git push origin master # MUST NOT be forced

# If your push to master is rejected, somebody updated master while you were merging your branch.
# The correct thing to do in that case is redoing the process to merge the branch in an up-to-date master.
# Communicating your intention to merge to your team mates would have prevented that pain, never forget to do it early.