User Tools

Site Tools


developers:git:specificities_git_abinit

Differences

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

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
developers:git:specificities_git_abinit [2019/11/05 00:57] – [Additional info: Setup of the SSH environment] Matteo Giantomassidevelopers:git:specificities_git_abinit [2024/02/29 10:07] (current) – [(Quick start) Cloning from gitlab] 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. 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. 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 30: Line 30:
 \\ \\
 After some modifications, using the git commands (e.g. git add, git commit ...), you can push on the gitlab server thanks to : \\ After some modifications, using the git commands (e.g. git add, git commit ...), you can push on the gitlab server thanks to : \\
-<color blue>git push </color>\\ 
-[ or\\ 
 <color blue>git push --tags  </color>     <color red>( double-dash before tags )</color>\\ <color blue>git push --tags  </color>     <color red>( double-dash before tags )</color>\\
-if tags have been introduced...]\\+\\
 In order for the modifications to be merged in the trunk, a merge request has to be issued, as described later.\\ In order for the modifications to be merged in the trunk, a merge request has to be issued, as described later.\\
 \\ \\
Line 74: Line 72:
 For a <color magenta>release-*</color> branch to be **on-track**, not only a specific commit must be contained in the past history of the branch, but also the commit that starts the next development version **cannot** be present. Only one among the <color magenta>release-*</color> branches is **on-track** at any time. For a <color magenta>release-*</color> branch to be **on-track**, not only a specific commit must be contained in the past history of the branch, but also the commit that starts the next development version **cannot** be present. Only one among the <color magenta>release-*</color> branches is **on-track** at any time.
  
-As an example, suppose we were on ABINIT v8.9.x, and want to start preparing a release 8.10.(for production) and a new v8.11.0 (for development)   : +As an example, suppose we were on ABINIT v9.9.3, and want to start preparing a release 9.10.(for release) and a new v9.11.0 (for development)   : 
-  * a branch entitled <color magenta>release-8.10.0</color> will be forked from the <color magenta>develop</color> branch ; +  * a branch entitled <color magenta>release-9.10</color> will be forked from the <color magenta>develop</color> branch ; 
-  * after this branching, the first commit in the <color magenta>release-8.10.0</color> branch will be tagged start-8.10.0, while the first commit in the <color magenta>develop</color> branch will be tagged start-8.11.0, +  * after this branching, suppose the first commit in the <color magenta>release-9.10</color> branch is 1d5efe42, while the first commit in the <color magenta>develop</color> is the commit 34dbe7f2d 
-  * for a <color magenta>develop</color> branch to be considered **on-track** (and eligible for a merge request), the commit tagged start-8.11.0 will have to be present ; +  * for a <color magenta>develop</color> branch to be considered **on-track** (and eligible for a merge request), the commit 34dbe7f2d must be present ; 
-  * for a <color magenta>release-8.10.0</color> branch to be considered **on-track** (and eligible for a merge request), the commit tagged start-8.10.0 will have to be present, while it will be forbidden to contain the commit tagged start-8.11.0 .+  * for a <color magenta>release-9.10</color> branch to be considered **on-track** (and eligible for a merge request), the commit 1d5efe42 must be present, while it will be forbidden to contain the commit 34dbe7f2d .
  
-In complement to the start of a X.Y.Z version being tagged as "start-X.Y.Z", +In complement to the start of a X.Y.Z version for release being tagged as "start-X.Y.Z", 
-the commit that ends some X.Y.Z version of ABINIT will be tagged "X.Y.Z".+the commit that ends some X.Y.Z version for release will be tagged "X.Y.Z".
  
  
Line 95: Line 93:
 The default selection of bots, that is the "night" set, should be adequate for all merge requests. The default selection of bots, that is the "night" set, should be adequate for all merge requests.
 The selection capabilities of the Buildbot Status table are rather extended, you have to play a bit wit them. The selection capabilities of the Buildbot Status table are rather extended, you have to play a bit wit them.
- 
-(By the way, the behaviour of this Buildbot Status table when changing the selections has still some problems -as of May 2018-. Do not hesitate to click on the update button, and the "Grouping" button -the latter back and forth-, sorry for the inconvenience). 
  
 ===== How and when will the merge in the master branch be done ? ===== ===== How and when will the merge in the master branch be done ? =====
Line 105: Line 101:
  
 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.  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. The master branch is only used by the trunk. So, never issue a merge request to trunk/master.
  
Line 118: Line 115:
 Then, in order to synchronize, in a first step, issue : Then, in order to synchronize, in a first step, issue :
  
-   git fetch trunk+   git fetch --tags trunk
  
 then, if the develop branch is to be updated, supposing it is checked out, merge the trunk/develop in your develop :  then, if the develop branch is to be updated, supposing it is checked out, merge the trunk/develop in your develop : 
Line 128: Line 125:
    git pull trunk develop    git pull trunk develop
  
-If, on the contrary, a new branch (e.g. a release branch, let'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 createdTo fix the ideas, let'suppose you want to communicate a bug fix to ABINITv9.8, you have to issue :
  
-   git branch release-8.8 start-8.8.   (this creates the branch release-8.8 from the start-8.8.tag) +   git branch release-9.8 start-9.8.   (this creates the branch release-9.8 from the start-9.8.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 --tags
  
-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 ... ===== ===== Additional info: how to not mess with your branches ? ... show-branch ... =====
developers/git/specificities_git_abinit.1572911873.txt.gz · Last modified: 2019/11/05 00:57 by Matteo Giantomassi