From 84aa9878ad93d0e3876d1584caeb96ca43d52734 Mon Sep 17 00:00:00 2001 From: Datz <37868477+DatzAtWork@users.noreply.github.com> Date: Fri, 20 May 2022 08:37:06 +0200 Subject: [PATCH 1/3] Add a chapter on quashing Explains what to keep in mind when using squash commits/merges with GitLab flow. --- README.md | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/README.md b/README.md index 19de3a3..12c3fa2 100644 --- a/README.md +++ b/README.md @@ -164,3 +164,19 @@ Production -> Pre-production -> Master (ERROR) Despite the name, the GitLab flow is not a flow to be applied just on gitlab.com. Can be used with any repository the uses Git. +### A word about Squash Commits +Often it it a good idea to use [squash commits](https://git-scm.com/docs/git-commit#Documentation/git-commit.txt---squashltcommitgt), in order to maintain a clean and readable Git history. But there are a few points to keep in mind when using GitLab Flow with quashing. + +The peculiarity of a squash commit is that a new commit (with a new SHA-1 hash) is created. Thus the git history of the branches would differ when a merge request is squash merged first into the master branch and then into the environment branches. This would make it more difficult to merge between environment branches. + +### Enhancement flow +When a new feature is merged into the master branch, you can use squash commits without hesitation. In the best case you should delete the function branch directly after the merge. + +But whenever the master branch is merged into an environment branch, you must never use quash commits, as this would result in different git histories for the branches. + +### Hotfix flow +When a hotfix is needed, you must be carfully. Never squash merge the remote hotfix branch into several branches, as each squash merge would result into a new commit (with different SHA-1 hashs). + +You can either squash merge the hotfix branch into the production branch, then delete the hotfix-branch, and then merge the production branch back into the master branch and the other environment branches. + +Or you can squash merge all commits of the hotfix branch ('error_A') into a new hotfix branch ('error_A-final'). This new hotfix branch can then be merged into all environment branches without squashing. From 7119ef52f8c6011add96505bcece9d61e8ab27e3 Mon Sep 17 00:00:00 2001 From: Datz <37868477+DatzAtWork@users.noreply.github.com> Date: Fri, 20 May 2022 08:39:20 +0200 Subject: [PATCH 2/3] typo --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 12c3fa2..ff5cb4a 100644 --- a/README.md +++ b/README.md @@ -165,7 +165,7 @@ Production -> Pre-production -> Master (ERROR) Despite the name, the GitLab flow is not a flow to be applied just on gitlab.com. Can be used with any repository the uses Git. ### A word about Squash Commits -Often it it a good idea to use [squash commits](https://git-scm.com/docs/git-commit#Documentation/git-commit.txt---squashltcommitgt), in order to maintain a clean and readable Git history. But there are a few points to keep in mind when using GitLab Flow with quashing. +It is often a good idea to use [squash commits](https://git-scm.com/docs/git-commit#Documentation/git-commit.txt---squashltcommitgt), in order to maintain a clean and readable Git history. But there are a few points to keep in mind when using GitLab Flow with quashing. The peculiarity of a squash commit is that a new commit (with a new SHA-1 hash) is created. Thus the git history of the branches would differ when a merge request is squash merged first into the master branch and then into the environment branches. This would make it more difficult to merge between environment branches. From b85d954c1a748e6ab3b80ae884884c4c33fb43ad Mon Sep 17 00:00:00 2001 From: Datz <37868477+DatzAtWork@users.noreply.github.com> Date: Tue, 7 Jun 2022 20:46:36 +0200 Subject: [PATCH 3/3] Typos --- README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index ff5cb4a..625c95f 100644 --- a/README.md +++ b/README.md @@ -165,14 +165,14 @@ Production -> Pre-production -> Master (ERROR) Despite the name, the GitLab flow is not a flow to be applied just on gitlab.com. Can be used with any repository the uses Git. ### A word about Squash Commits -It is often a good idea to use [squash commits](https://git-scm.com/docs/git-commit#Documentation/git-commit.txt---squashltcommitgt), in order to maintain a clean and readable Git history. But there are a few points to keep in mind when using GitLab Flow with quashing. +It is often a good idea to use [squash commits](https://git-scm.com/docs/git-commit#Documentation/git-commit.txt---squashltcommitgt), in order to maintain a clean and readable Git history. But there are a few points to keep in mind when using GitLab Flow with squashing. The peculiarity of a squash commit is that a new commit (with a new SHA-1 hash) is created. Thus the git history of the branches would differ when a merge request is squash merged first into the master branch and then into the environment branches. This would make it more difficult to merge between environment branches. ### Enhancement flow When a new feature is merged into the master branch, you can use squash commits without hesitation. In the best case you should delete the function branch directly after the merge. -But whenever the master branch is merged into an environment branch, you must never use quash commits, as this would result in different git histories for the branches. +But whenever the master branch is merged into an environment branch, you must never use squash commits, as this would result in different git histories for the branches. ### Hotfix flow When a hotfix is needed, you must be carfully. Never squash merge the remote hotfix branch into several branches, as each squash merge would result into a new commit (with different SHA-1 hashs).