Skip to content

Instantly share code, notes, and snippets.

Embed
What would you like to do?
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
#
# 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 (Optional)
git checkout XXXXXXXX-add-example-feature
git push origin XXXXXXXX-add-example-feature:spike-add-example-feature
# keep a local backup too (Optional)
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 (On github, gitlab, or locally)
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.
@gsanchezd

This comment has been minimized.

Copy link

gsanchezd commented May 15, 2018

:)

@jpcuevaslavin

This comment has been minimized.

Copy link

jpcuevaslavin commented May 15, 2018

👏

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.