From ab8df4848dc713c864cdb95b67c45391871bd63f Mon Sep 17 00:00:00 2001 From: Janek Bevendorff Date: Sat, 28 Jan 2017 19:04:56 +0100 Subject: [PATCH] Updated Merge strategy (markdown) --- Merge-strategy.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Merge-strategy.md b/Merge-strategy.md index 783f016..19b3659 100644 --- a/Merge-strategy.md +++ b/Merge-strategy.md @@ -19,7 +19,7 @@ Additionally to these two branches, there are several short-lived branches with Merging from a short-lived branch into a historical should be done using `git merge --no-ff` to preserve the origin of those commits. For instance, if a `feature/*` branch is merged into `develop` it should be done with a merge commit. -Merging from historical branches into short-lived branches cannot be done without a merge commit, so it is preferred to keep to short-lived branch rebased on top of the long-lived branch (i.e., rebase your `feature` onto the `develop` branch). If that is not possible because the branch is used by multiple contributors, a normal merge commit is acceptable. +Merging from historical branches into short-lived branches cannot be done without a merge commit, so it is preferred to keep the short-lived branch rebased on top of the long-lived branch (i.e., rebase your `feature` onto the `develop` branch). If that is not possible because the branch is used by multiple contributors, a normal merge commit is acceptable. Merging a `hotfix` into the `release` branch should be done using `git merge --ff-only` or `git rebase (--onto)` and then `git merge --ff-only` to avoid creating a merge commit. The same applies when merging between other short-lived branches. Avoid merge commits where possible. The exception is when the merged branch contains a significant number of commits and preserving the two branches in the history makes sense (*significant* is subjective).