From 5d14b27416402e8fe9f559b1f7cb93c992ce564a Mon Sep 17 00:00:00 2001 From: Janek Bevendorff Date: Sun, 23 Sep 2018 19:33:26 +0200 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 502b6d3..4abff77 100644 --- a/Merge-strategy.md +++ b/Merge-strategy.md @@ -23,6 +23,6 @@ In addition to these two branches, there are several short-lived topic branches Merging a topic branch into an eternal or release branch should always be done in a fast-forward manner. That means it needs to be [rebased](https://git-scm.com/docs/git-rebase) properly onto the latest revision of the target branch (usually `develop`) and merging is done without creating a merge commit (`git merge --ff`). Each commit on a merged branch needs to compile, pass all tests, and be in a usable state. Unless there is a very good reason for separating individual changes, this means that all changes of a branch should be merged into a single commit once a feature has been completed. -Merged commits need to be descriptive. For very small commits this means they need to have a good title. For larger commits, add an exhaustive description about what the patch does and why after the title. Reference issues liberally. +Merged commit messages need to be descriptive. For very small commits this means they need to have a good title. For larger commits, add an exhaustive description about what the patch does and why after the title. Reference issues liberally. If your branch does not meet the above-mentioned commit requirements, maintainers will squash-merge and rewrite your commit at will. \ No newline at end of file