Answers: <p>Consider to substitute the version in POM by the <code>git describe</code> upon build without hardcoding the version in your repository, you could do this with e.g. <code>sed</code> from below <code>version_slug</code>.</p>
  
  <pre><code>export git_version=`git describe --tags --always`
  export version_slug="$(sed s/-/\./g &lt;&lt;&lt;$git_version)"
  </code></pre>
  
  <p>and then substitute the version_slug in pom.</p>
  
  <p>In that way for each commit and/or tag in gitlab, you'll create a new version, with out actually changing the repository. </p>
  
  <p>this is what i did for a ruby project: <a href="https://gitlab.com/dgoo2308/jekyll-plantuml-url/blob/master/.gitlab-ci.yml" rel="nofollow noreferrer">jekyll-plantuml-url</a>, where the version is not coded in the source, but is set upon build, and after testing deployed as the git tag.</p>
  
  <pre><code>  script:
     - bundle install
     - rake set_git_tag
     - rake
     - gem build jekyll-plantuml-url.gemspec
  </code></pre>
  
  <p>Furthermore don't understand the need of all those branches, with CI/CD we continuously build, test and deploy, that means before accepting a merge to master you have a deployment for QA to do the testing, code review, functional testing ...etc.</p>
  
  <p>Next add QA as approver for a merge to master, thus make it mandatory that QA signs of a merge request to master and integrate quality in the development cycle or have a master that is always ready for release.</p>
  
  <p>One could opt to work from master and for a release tag the master branch with a version tag, as per above example.</p>
  
  <p>OR </p>
  
  <p>like gitlab does it, to create a branch for each release, cherry pick the features from master that are ready or planned and then tag the branch with a version tag.</p>
  
  <p>where as a version tag creates a deployment for a commit, release or a RC.</p>
  
Answers: CC BY-SA 4.0
Answers: 2018-09-15T09:48:32.900Z
Answers: 2018-09-17T07:24:51.213Z
Answers: 2018-09-17T07:24:51.213Z
Answers: Danny Goossen
Body: <p>I'm using <strong>GitLab CE</strong> with <strong>Maven</strong> project, and try to follow the <a href="https://docs.gitlab.com/ce/workflow/gitlab_flow.html#environment-branches-with-gitlab-flow" rel="nofollow noreferrer">Environment branches with GitLab flow</a> and <a href="https://about.gitlab.com/2016/07/27/the-11-rules-of-gitlab-flow/" rel="nofollow noreferrer">The 11 Rules of GitLab Flow</a> </p>
  
  <p>The step for releasing is as the following: - </p>
  
  <pre class="lang-none prettyprint-override"><code>feature   +---   +---          +---
           /    \ /    \        /    \
  master  + ---- + ---- + ---- + ---- +  
                          \            \
  qa-tmp (chage ver to RC) +---         + --- 
                               \             \
  qa      + ------------------- + ---------- +
                               (v1.0-RC1)   (v1.1-RC1)
                                \            \    
  prod-tmp (chage ver to final)  +---         + ---
                                     \             \
  prod    + ------------------------ + ------------ +
                                   (v1.0)         (v1.1)
  </code></pre>
  
  <ol>
  <li>Create a <code>feature</code> branch and merge into the <code>master</code> so that it is ready to be released</li>
  <li><p>Create the <code>qa-tmp</code> branch e.g. <code>release-v1.0-RC1</code> from <code>master</code></p>
  
  <p>2.1 Update the pom version to <code>1.0-RC1</code></p>
  
  <p>2.2 Merge the <code>release-v1.0-RC1</code> to <code>qa</code></p>
  
  <p>2.3 Tag <code>v1.0-RC1</code> from merged <code>qa</code> branch.</p></li>
  <li><p>When it pass the QA, create <code>prod-tmp</code> branch e.g. <code>release-v1.0</code> from tag <code>v1.0-RC1</code></p>
  
  <p>3.1 Update the pom version to <code>1.0</code></p>
  
  <p>3.2 Merge the <code>release-v1.0</code> to prod</p>
  
  <p>3.3 Tag <code>v1.0</code> from merged <code>prod</code> branch</p>
  
  <p>3.4 Bump <code>master</code> to version <code>1.1-SNAPSHOT</code></p></li>
  <li><p>Develop the version <code>1.1-SNAPSHOT</code> in the features &amp; master when it is ready to be released, repeat the step 2 and 3.</p></li>
  </ol>
  
  <p>The trouble is since the <code>version</code> is changed during merging the <code>qa</code> branch and <code>prod</code> branch, when I perform a next release there is a <em>merge conflict</em> for the <code>version</code> inside the pom. This cause me to resolve this conflict manually.</p>
  
  <p>I'm not sure if I'm doing something wrong or misunderstanding about the releasing procedure or not. </p>
  
  <p>Furthermore, do we have any practice to make this releasing to be an automation, e.g. via script? </p>
  
  <p>Could you please help to advise?</p>
  
Tags: <git><gitlab>
Title: What's the practice to perform a releasing with Git?
UserDisplayName: Charlee Chitsuk
ThreadText: # What's the practice to perform a releasing with Git?
  
  (Asked by: username_0 on 2018-09-06)
  
  I'm using **GitLab CE** with **Maven** project, and try to follow the [Environment branches with GitLab flow](https://docs.gitlab.com/ce/workflow/gitlab_flow.html#environment-branches-with-gitlab-flow) and [The 11 Rules of GitLab Flow](https://about.gitlab.com/2016/07/27/the-11-rules-of-gitlab-flow/)
  
  The step for releasing is as the following: -
  
  ```none
  feature   +---   +---          +---
           /    \ /    \        /    \
  master  + ---- + ---- + ---- + ---- +  
                          \            \
  qa-tmp (chage ver to RC) +---         + --- 
                               \             \
  qa      + ------------------- + ---------- +
                               (v1.0-RC1)   (v1.1-RC1)
                                \            \    
  prod-tmp (chage ver to final)  +---         + ---
                                     \             \
  prod    + ------------------------ + ------------ +
                                   (v1.0)         (v1.1)
  
  ```
  
  1. Create a `feature` branch and merge into the `master` so that it is ready to be released
  2. Create the `qa-tmp` branch e.g. `release-v1.0-RC1` from `master`
  
     2.1 Update the pom version to `1.0-RC1`
  
     2.2 Merge the `release-v1.0-RC1` to `qa`
  
     2.3 Tag `v1.0-RC1` from merged `qa` branch.
  3. When it pass the QA, create `prod-tmp` branch e.g. `release-v1.0` from tag `v1.0-RC1`
  
     3.1 Update the pom version to `1.0`
  
     3.2 Merge the `release-v1.0` to prod
  
     3.3 Tag `v1.0` from merged `prod` branch
  
     3.4 Bump `master` to version `1.1-SNAPSHOT`
  4. Develop the version `1.1-SNAPSHOT` in the features & master when it is ready to be released, repeat the step 2 and 3.
  
  The trouble is since the `version` is changed during merging the `qa` branch and `prod` branch, when I perform a next release there is a *merge conflict* for the `version` inside the pom. This cause me to resolve this conflict manually.
  
  I'm not sure if I'm doing something wrong or misunderstanding about the releasing procedure or not.
  
  Furthermore, do we have any practice to make this releasing to be an automation, e.g. via script?
  
  Could you please help to advise?
  
  **Tags:** git, gitlab
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2018-09-15. Score: 4 | Accepted answer
  
  Consider to substitute the version in POM by the `git describe` upon build without hardcoding the version in your repository, you could do this with e.g. `sed` from below `version_slug`.
  
  ```
  export git_version=`git describe --tags --always`
  export version_slug="$(sed s/-/\./g <<<$git_version)"
  
  ```
  
  and then substitute the version\_slug in pom.
  
  In that way for each commit and/or tag in gitlab, you'll create a new version, with out actually changing the repository.
  
  this is what i did for a ruby project: [jekyll-plantuml-url](https://gitlab.com/dgoo2308/jekyll-plantuml-url/blob/master/.gitlab-ci.yml), where the version is not coded in the source, but is set upon build, and after testing deployed as the git tag.
  
  ```
    script:
     - bundle install
     - rake set_git_tag
     - rake
     - gem build jekyll-plantuml-url.gemspec
  
  ```
  
  Furthermore don't understand the need of all those branches, with CI/CD we continuously build, test and deploy, that means before accepting a merge to master you have a deployment for QA to do the testing, code review, functional testing ...etc.
  
  Next add QA as approver for a merge to master, thus make it mandatory that QA signs of a merge request to master and integrate quality in the development cycle or have a master that is always ready for release.
  
  One could opt to work from master and for a release tag the master branch with a version tag, as per above example.
  
  OR
  
  like gitlab does it, to create a branch for each release, cherry pick the features from master that are ready or planned and then tag the branch with a version tag.
  
  where as a version tag creates a deployment for a commit, release or a RC.
  
  
  ---
  
  