Differences

This shows you the differences between two versions of the page.

--- developers:git:specificities_git_abinit [2020/02/28 21:01] – [What is shown in the Buildbot Status table ?] Xavier Gonze
+++ developers:git:specificities_git_abinit [2022/07/24 19:02] – [How to set up a "hotfix" branch to be merged in trunk/release-x.y ?] Xavier Gonze
@@ Line 10: / Line 10: @@
 On the ABINIT gitlab server, an ABINIT project can be defined, specifically for you, with address <color blue>git@gitlab.abinit.org</color>:<color red>user_id</color><color blue>/abinit.git</color>. In order to do this, log on https://gitlab.abinit.org, go to "Explore projects", find "Trunk / Abinit" (+perhaps select "All"), then click on the "Fork" button. You need to contact Jean-Michel Beuken to have access to the ABINIT gitlab.
-In order to start to work locally (not on the ABINIT gitlab server, but on your own machine), you should setup the SSH environment for gitlab, as described  [[developers:git:specificities_git_abinit#Setup_of_the_ssh_environment|in the last section of this document]]. In particular on some machines you need to have an ssh agent running with your rsa key already available, so that git finds it when it runs ssh.
+In order to start to work locally (not on the ABINIT gitlab server, but on your own machine), you should setup the SSH environment for gitlab, as described  [[developers:git:specificities_git_abinit#Additional_infosetup_of_the_ssh_environment|in the last section of this document]]. In particular on some machines you need to have an ssh agent running with your rsa key already available, so that git finds it when it runs ssh.
 You have by default a <color magenta>master</color> branch and a <color magenta>develop</color> branch in your repository, but can create or work on other branches, following the philosophy of git. In particular, according to  [[http://nvie.com/posts/a-successful-git-branching-model|gitflow]], this <color magenta>master</color> branch will be of little use for the "physical" developers (including you), as we will see later, while the <color magenta>develop</color> and <color magenta>release-*</color> branches will be quite important for you.
@@ Line 103: / Line 103: @@
 However, when a <color magenta>release-*</color> branch is ready to be merged, the "merge request" should target the corresponding <color red>trunk</color>/<color magenta>release-*</color> branch.
 The master branch is only used by the trunk. So, never issue a merge request to trunk/master.
@@ Line 126: / Line 127: @@
    git pull trunk develop
-If, on the contrary, a new branch (e.g. a release branch, let's says 8.8 to fix the ideas) has to be created :
+===== How to set up a "hotfix" branch to be merged in trunk/release-x.y ? =====
+If you have a hotfix, a new branch has to be created. To fix the ideas, let's suppose you want to communicate a bug fix to ABINITv9.6, you have to issue :
-   git branch release-8.8 start-8.8.1    (this creates the branch release-8.8 from the start-8.8.1 tag)
+   git branch release-9.8 start-9.8.0    (this creates the branch release-9.8 from the start-9.8.0 tag)
-   git checkout release-8.8
+   git checkout release-9.8
-   git merge remotes/trunk/release-8.8
+   git merge remotes/trunk/release-9.8
-   git push -u origin release-8.8
+   git push -u origin release-9.8
-That's it ! You can now make modifications in your release-8.8, then issue a merge request to the trunk/release-8.8 .
+That's it ! You can now make modifications in your release-9.8, then issue a merge request to the trunk/release-9.8 .
 ===== Additional info: how to not mess with your branches ? ... show-branch ... =====