Git: Difference between revisions

From Mu2eWiki
Jump to navigation Jump to search
No edit summary
Line 67: Line 67:
==Workflows for committing code==
==Workflows for committing code==


We are using two workflows when changed need to be committed back to the repository.
As the group of mu2e code developers grows at the same time that the need for a stable code base increases, individual code contributions may start to clash with other contributions, so we are using a "request to pull" procedure.  In this procedure, the developer does code development on a git branch and commits that branch to the repository frequently.  This branch does not affect other users, so it can be in any state the developer finds useful - it might not even compile. Once the developer believes the work is complete, they make a request to the Offline group heads to "pull" the branch into the master branch.  If the change is very simple or low-risk, the heads may ask the developer to go ahead and do that merge.  If the change is large or complex, they may request additional documentation or testing before the pull.  The branch should be prepared so it does not have any conflicts with the head, so it can be merged with "fast forward".


* [[GitMinorWorkflow|Minor development]], or "hot fix". This is for small changes, such as changing fcl parameters, fixing bugs, adding minor features, or starting a new module. These modifications are committed directly to the head and should leave the head in a state that compiles and runsThere should be no branch visible afterwards. The changes should not require any special warning to users.  This pattern is copied from [https://cdcvs.fnal.gov/redmine/projects/mu2eofflinesoftwaremu2eoffline/wiki/Git_Workflow_for_Mu2e mu2e commit instructions the original redmine page].
The procedure of developing on branch, then requesting to merge is explained in detail on the [[GitMajorWorkflow|git  development page]].   


* [[GitMajorWorkflow|Major development]]. This is intended for development which will take more than a day, perhaps up to months, and may involve multiple contributors and validators, or should be documented in the git repository for some time.  They may also mark breaking changes, need to be coordinated with product changes, other branches, or tags.  Currently we plan to leave these branches visible in the repository until they are no longer of interest, at which time they may be archived so as to not clutter the repo forever.
If a change is very small, or planned in advance, or urgent, the Offline group heads may allow the commit to follow the [[GitMinorWorkflow|workflow]] which ends in a commit directly to the head of master.


==Repositories==
==Repositories==

Revision as of 19:47, 27 August 2018

Introduction

The primary source code management system for the Mu2e Offline software is a git repository that is hosted on the Fermilab Redmine site. Git is a popular open-source software version control system and Redmine is a software project management system which contains, for each project, a log, a wiki (which may contain useful info), and possibly gantt charts and bug tracking along with the git respositories.

Based on the git repository's url, you can check out code, and, if you are a code developer, check in modifications. NB, when committing code, please follow these mu2e conventions only. Git also has capabilities for tagging code, tracking history and supports splitting off and merging development branches, among many other features.

Depending on your experience or needs, please also see the basic code recipe. You can continue with the quick start on this page or the expanded git introduction page. See the references for more details on Redmine and git.

Some older parts of Mu2e software is managed using other source code management systems. Some code, both critical and specialized, is in other, smaller repositories. See Repositories below for more details on repositories.

Quick Start

Please also see the basic code recipe for an introduction to setting up the environment, checking out code and building.

If you are going to commit anything, you must understand and follow the mu2e commit instructions

If this is the first time you are using git in the mu2e environment, please follow the few steps listed in order to set up your preferences in ~.gitconfig.

A more detailed introduction to all mu2e repositories is here and our introduction to git is here.

  • checkout the main repository
    • readonly:
      git clone http://cdcvs.fnal.gov/projects/mu2eofflinesoftwaremu2eoffline/Offline.git
    • with kerberos authentication for committing code
      git clone ssh://p-mu2eofflinesoftwaremu2eoffline@cdcvs.fnal.gov/cvs/projects/mu2eofflinesoftwaremu2eoffline/Offline.git
  • checkout the head to a local working branch, here named "work" (recommended)
git checkout -b work
  • see the history of a file
git log fileSpec
  • list tags
git tag -l
  • checkout a tag or branch or commit hash into the working area. Use this to switch between branches, it will NOT overwrite your work.
git checkout tagOrBranchNameorHash 
  • update the local repository to the origin repository (Redmine)
git fetch
  • update the local repository to changes staged in the working area (does not affect the origin repository)
git commit -m"'Your descriptive message'"
  • update the origin repository (Redmine) to changes in your local repository
git push
  • update the local repository to the origin repository (REDMINE)
git fetch
  • update the working area to the local repository
git merge
  • update the local repository and update the working area both together
git pull
  • merge a branch (including master) into your branch. NB: do NOT merge your branch into master unless authorized
git checkout otherbranch 
git pull
git checkout mybranch
git pull
git checkout mybranch
git merge otherbranch
  • see what the status is
git status
  • command line help
git status help
  • git browser (to see a graphical history of commits)
gitk --all


Please see the references below or many web resources for details on git concepts, commands and features. If you are going to commit anything, you must understand and follow the commit workflows.

Workflows for committing code

As the group of mu2e code developers grows at the same time that the need for a stable code base increases, individual code contributions may start to clash with other contributions, so we are using a "request to pull" procedure. In this procedure, the developer does code development on a git branch and commits that branch to the repository frequently. This branch does not affect other users, so it can be in any state the developer finds useful - it might not even compile. Once the developer believes the work is complete, they make a request to the Offline group heads to "pull" the branch into the master branch. If the change is very simple or low-risk, the heads may ask the developer to go ahead and do that merge. If the change is large or complex, they may request additional documentation or testing before the pull. The branch should be prepared so it does not have any conflicts with the head, so it can be merged with "fast forward".

The procedure of developing on branch, then requesting to merge is explained in detail on the git development page.

If a change is very small, or planned in advance, or urgent, the Offline group heads may allow the commit to follow the workflow which ends in a commit directly to the head of master.

Repositories

One important piece of the mu2e offline code is the BTrk UPS product, which contains our Kalman track fit code, and is stored in the BTrk github repo.

All of the rest of the mu2e Offline code and tools are in Redmine repositories. You can browse all Redmine projects and mu2e Redmine. The mu2e Redmine has subprojects (and sub-subprojects) and each has a repository associated with them. For example in the Standalone subproject, there is a sub-subproject Mu2eCCFC. In addition, the main mu2e Offline repository has sub-repositories which can be seen on the right sidebar menu on the repository main page. An example is the dhtools sub-repo.

Here is a (possibly incomplete) list of the repositories.

content user name alias
p-mu2e_artdaq mu2e_artdaq
raw data format p-mu2e_artdaq mu2e_artdaq-core
F-C limit setting p-mu2eccfc mu2eccfc-mu2eccfc mu2eccfc.git
CI validation p-mu2e_ci mu2e_ci
p-mu2e-daq-firmware mu2e-daq-firmware
p-mu2e-daq-firmware mu2e-daq-firmware-dtc
p-mu2e-dcs mu2e-dcs
p-mu2e_detector_construction_db mu2e_detector_construction_db
p-mu2eextmontestdaq mu2eextmontestdaq
grid tools p-mu2egrid mu2egrid
Offline p-mu2eofflinesoftwaremu2eoffline mu2eofflinesoftwaremu2eoffline Offline.git
Jenkins p-mu2eofflinesoftwaremu2eoffline mu2eofflinesoftwaremu2eoffline-codetools codetools.git
data handling p-mu2eofflinesoftwaremu2eoffline mu2eofflinesoftwaremu2eoffline-dhtools dhtools.git
p-mu2eofflinesoftwaremu2eoffline mu2eofflinesoftwaremu2eoffline-geomdisplay geomdisplay.git
satellite releases p-mu2eofflinesoftwaremu2eoffline mu2eofflinesoftwaremu2eoffline-satellite
gridexport product p-mu2eofflinesoftwaremu2eoffline mu2eofflinesoftwaremu2eoffline-gridexport gridexport.git
p-mu2eofflinesoftwaremu2eoffline mu2eofflinesoftwaremu2eoffline-test
obsolete p-mu2eofflinesoftwaremu2eoffline mu2eofflinesoftwaremu2eoffline-validation validation.git
Stntuple framework p-mu2eofflinesoftwarestntuple mu2eofflinesoftwarestntuple Stntuple.git
p-mu2eofflinesoftwareuser mu2eofflinesoftwareuser-betasource betasource.git
p-mu2eofflinesoftwareuser mu2eofflinesoftwareuser-example01 example01.git
p-mu2eofflinesoftwareuser mu2eofflinesoftwareuser-streamline
p-mu2epbarmodels mu2epbarmodels
p-mu2epbaridanalysis mu2epbaridanalysis
p-mu2e-raw-data mu2e-raw-data
p-mu2e-simulations mu2e-simulations
p-mu2estat mu2estat
p-mu2e-tools mu2e-tools-bintools mu2ebintools
FileTools p-mu2e-tools mu2e-tools-filetools mu2efiletools
FileTools p-mu2e-tools mu2e-tools-mu2efilename mu2efilename
generate_fcl p-mu2e-tools mu2e-tools-tools mu2etools

Creating a Redmine subproject is done by the "add subproject" button on the Redmine project web page. This is probably more appropriate for a project not closely associated with the Offline. Creating a sub-repository associated to the main offline repo is explained in the mu2e instructions and SCD instructions. This is probably more appropriate for a project closely associated with the Offline. Write privileges to each repository can be controlled by the .k5login contents of each group username associated with the repo - note that this file should be edited by the Redmine project web page (settings->members), not directly. The login to the group account is controlled by the .admin file.

A git repository is accessed through a url and the url can be read-only or read/write, which allows commits back to the repo. Taking values from the table of Redmine repos above, a repo without an alias will have read-only and read/write urls:

http://cdcvs.fnal.gov/projects/name
ssh://user@cdcvs.fnal.gov/cvs/projects/name

and if it has an alias:

http://cdcvs.fnal.gov/projects/name/alias
ssh://user@cdcvs.fnal.gov/cvs/projects/name/alias

A good view of all repositories can be found by logging is as one of the user names where you have write permissions:

ssh user@cdcvs.fnal.gov

The projects can be seen

cd /cvs/projects
ls -l | grep mu2e

there is one directory per repository and the username can be seen as the owner of the repository directory. If the repository has an alias, it will appear as a subdirectory or a circular link under

/cvs/projects/name

The .k5login file for a repository is

/home/name/.k5login

References