Difference between revisions of "Git"

From UFRC
Jump to navigation Jump to search
(14 intermediate revisions by 2 users not shown)
Line 1: Line 1:
[[Category:Infrastructure]][[Category:Docs]]
+
[[Category:Infrastructure]][[Category:Docs]][[Category:Revision Control]]
==Installation==
+
=Using UFRC Git Server=
===Redhat EL 6.0===
+
'''Note:''' Use git.ufhpc hostname from inside HiPerGator and git.rc.ufl.edu from the outside when cloning any repository from the UFRC Git Server.
Simple installation:
+
==Request a group Git archive==
 +
This is the first step. As a result the group will have a Git archive on the UFRC Git server that they can add any number of repositories to and have full control of access privileges and membership.
  
yum install git
+
As an example we'll use the ''awesome'' group, administrative user (set up by UFRC staff) ''admin'' and a regular user ''student''.
  
==Using git.hpc.ufl.edu==
+
* Open a support ticket in the [http://support.rc.ufl.edu UFRC Support]] ticket system with a name like "Create an UFRC Git repository for the "Awesome" group.
===Request a group repository===
 
As an example we'll use the ''awesome'' group, administrative user (set up by HPC staff) ''admin'' and a regular user ''student''.
 
 
 
* Open a support ticket in the [http://support.hpc.ufl.edu HPC Support]] ticket system with a name like "Create an HPC Git repository for the "Awesome" group.
 
 
* List your projected git usage:
 
* List your projected git usage:
  
Line 20: Line 17:
 
#Where the repository administrator's public ssh key can be found (you can paste it into the support ticket).
 
#Where the repository administrator's public ssh key can be found (you can paste it into the support ticket).
  
* Assuming that your usage pattern falls within the limits of our resources we'll create a repository 'awesome' on git.hpc.ufl.edu and configure it for the administrator. After that the administrator 'admin' can do the following:
+
* Assuming that your usage pattern falls within the limits of our resources we'll create a repository 'awesome' on git.rc.ufl.edu and configure it for the administrator. After that the administrator 'admin' can do the following:
  
===admin@linux64===
+
==Repository Administration==
The admin user on a remote machine ''linux64'' can do the following
+
Check out the admin repository
* Check out the admin repository
+
  git clone awesome@git.rc.ufl.edu:gitolite-admin.git
  git clone awesome@git.hpc.ufl.edu:gitosis-admin.git
+
or change into the gitolite-admin directory if already cloned and run 'git pull' to refresh the local working tree from the server.
* Add more users e.g. 'student' with a public key ''student.pub''
+
 
  cd gitosis-admin
+
===Add users===
  cp ~/student.pub keydir/
+
;Single machine
 +
: e.g. user 'jdoe' working on a single machine who provided the repository administrator with a public ssh key named ''jdoe.pub''
 +
  cd gitolite-admin
 +
  cp ~/jdoe.pub keydir/
 
  git add keydir/*
 
  git add keydir/*
  git commit -m "added user student"
+
  git commit -m "added user jdoe"
 +
git push
 +
 
 +
;Additional machines
 +
: if a user needs to access the repository from another machine named, for example, 'jdoe_laptop'
 +
cd gitolite-admin/keydir
 +
mkdir jdoe_laptop
 +
cp ~/jdoe.pub jdoe_laptop
 +
git add *
 +
git commit -m "added a new key from jdoe_laptop for user jdoe"
 
  git push
 
  git push
* Create a new repository ''denovo'' for ''de novo'' assembly scripts and set access to users ''admin'' and ''student''
+
 
  cd gitosis-admin
+
===Grant Access===
  vim gitosis.conf
+
Once a new user (but not a new key for an existing user) is added they need to be granted access to appropriate repositories. This is done by editing the config/gitolite.conf file, then committing and pushing the commit to the server.
Add:
+
 
  [group awesome]
+
For example, to allow access from users 'janedoe' and 'johndoe' to a repository 'test1' either add their gitolite key names to the access list for that repository or create a gitolite group, add the users to the group and grant the group access to the repository.
writable = denovo
+
 
members = admin student
+
repo test1
 +
    RW+    =  janedoe johndoe
 +
    R      =  @all
 +
 
 +
or
 +
 
 +
repo test1
 +
    RW+    =  @mygroup
 +
    R      =  @all
 +
 
 +
# Groups
 +
@test_group  = janedoe johndoe
 +
 
 +
Access types:
 +
RW+ means 'Read and Write access'
 +
R  means 'Ready-only access'
 +
 
 +
===Create a new repository===
 +
;For example, an admin wants to create a repository called ''denovo'' for ''de novo'' assembly scripts and set access to users ''admin'' and ''student''
 +
  cd gitolite-admin
 +
  vim conf/gitolite.conf
 +
Add a group configuration:
 +
  @mygroup = admin student
 +
Add a repository configuration
 +
repo denovo
 +
    RW+    =   @mygroup
 +
    R      =   @all
 
* Commit and push
 
* Commit and push
 
  git add *
 
  git add *
Line 48: Line 83:
 
  cd denovo
 
  cd denovo
 
  git init
 
  git init
  git remote add origin awesome@hpc.ufl.edu:denovo.git
+
  git remote add origin awesome@git.rc.ufl.edu:denovo.git
 
* Add and edit some files
 
* Add and edit some files
 
* Commit and push to the Git server
 
* Commit and push to the Git server
Line 59: Line 94:
 
  Writing objects: 100% (3/3), 231 bytes, done.
 
  Writing objects: 100% (3/3), 231 bytes, done.
 
  Total 3 (delta 0), reused 0 (delta 0)
 
  Total 3 (delta 0), reused 0 (delta 0)
  To awesome@git.hpc.ufl.edu:denovo.git
+
  To awesome@git.rc.ufl.edu:denovo.git
 
  * [new branch]      master -> master
 
  * [new branch]      master -> master
  
After a new user 'student is allowed access they can start using the repository.
+
===User Activities===
===student@linux64===
+
Regular cycle of git repository usage
 
* Clone the ''denovo'' repository
 
* Clone the ''denovo'' repository
  git clone awesome@git.hpc.ufl.edu:denovo.git
+
  git clone awesome@git.rc.ufl.edu:denovo.git
 
Output:
 
Output:
 
  Cloning into denovo...
 
  Cloning into denovo...
Line 78: Line 113:
 
  git commit -m "The changes I made"
 
  git commit -m "The changes I made"
 
  git push
 
  git push
 +
 +
==Git email reports==
 +
We can enable Git email reports for any repository. Please email the support or file a suport ticket. Once enabled, every "push" to the remote repository on git.rc.ufl.edu will produce a commit email report to a defined list of email addresses.
 +
==Multiple SSH keys==
 +
To enable a user to have multiple ssh keys for accessing the UFRC Git server the repository administrator can simply put the user's keys under subdirectories in the 'keydir', add, commit, and push as usual. The user must make sure they're using the right key. It's often convenient to create a SSH configuration for each particular combination of repositories and keys. For example,
 +
 +
* Edit your <code>~/.ssh/config</code> file on a local machine that need to be configured. Let's assume that the main configuration is
 +
Host hpcgit
 +
    HostName git.rc.ufl.edu
 +
    User awesomegroup
 +
    IdentityFile ~/.ssh/id_rsa
 +
   
 +
To be able to use an alternate key add the following configuration
 +
Host hpcgit2
 +
    HostName git.rc.ufl.edu
 +
    User awesomegroup
 +
    IdentityFile ~/.ssh/id_rsa_my_other_key
 +
 +
Once configuration is done you'll be able to check out the repository via
 +
 +
git clone hpcgit2:my_repository
 +
 +
'''Notes:''' Make sure that the '''User''' is set to your group's Git account and not your personal HPC account name.
 +
 +
==Graphical User Interfaces to Git==
 +
[[TortoiseGit_Clone_Repository|How to use TortoiseGit to clone a Git Repository]]

Revision as of 16:01, 18 September 2019

Using UFRC Git Server

Note: Use git.ufhpc hostname from inside HiPerGator and git.rc.ufl.edu from the outside when cloning any repository from the UFRC Git Server.

Request a group Git archive

This is the first step. As a result the group will have a Git archive on the UFRC Git server that they can add any number of repositories to and have full control of access privileges and membership.

As an example we'll use the awesome group, administrative user (set up by UFRC staff) admin and a regular user student.

  • Open a support ticket in the UFRC Support] ticket system with a name like "Create an UFRC Git repository for the "Awesome" group.
  • List your projected git usage:
  1. What group will be accessing it.
  2. Who would be the group administrator (username).
  3. How soon you need it set up.
  4. How much space you need i.e. what type of content is going to be stored in the repository.
  5. The uptime requirements i.e. whether the occasional downtime is acceptable.
  6. Where the repository administrator's public ssh key can be found (you can paste it into the support ticket).
  • Assuming that your usage pattern falls within the limits of our resources we'll create a repository 'awesome' on git.rc.ufl.edu and configure it for the administrator. After that the administrator 'admin' can do the following:

Repository Administration

Check out the admin repository

git clone awesome@git.rc.ufl.edu:gitolite-admin.git

or change into the gitolite-admin directory if already cloned and run 'git pull' to refresh the local working tree from the server.

Add users

Single machine
e.g. user 'jdoe' working on a single machine who provided the repository administrator with a public ssh key named jdoe.pub
cd gitolite-admin
cp ~/jdoe.pub keydir/
git add keydir/*
git commit -m "added user jdoe"
git push
Additional machines
if a user needs to access the repository from another machine named, for example, 'jdoe_laptop'
cd gitolite-admin/keydir
mkdir jdoe_laptop
cp ~/jdoe.pub jdoe_laptop
git add *
git commit -m "added a new key from jdoe_laptop for user jdoe"
git push

Grant Access

Once a new user (but not a new key for an existing user) is added they need to be granted access to appropriate repositories. This is done by editing the config/gitolite.conf file, then committing and pushing the commit to the server.

For example, to allow access from users 'janedoe' and 'johndoe' to a repository 'test1' either add their gitolite key names to the access list for that repository or create a gitolite group, add the users to the group and grant the group access to the repository.

repo test1

   RW+     =   janedoe johndoe
   R       =   @all

or

repo test1

   RW+     =   @mygroup
   R       =   @all
# Groups
@test_group  = janedoe johndoe

Access types:

RW+ means 'Read and Write access'
R   means 'Ready-only access'

Create a new repository

For example, an admin wants to create a repository called denovo for de novo assembly scripts and set access to users admin and student
cd gitolite-admin
vim conf/gitolite.conf

Add a group configuration:

@mygroup = admin student

Add a repository configuration repo denovo

   RW+     =   @mygroup
   R       =   @all
  • Commit and push
git add *
git commit -m "Set up a new repository denovo for use by admin and student"
git push
  • Create a local working tree for the denovo project:
cd
mkdir denovo
cd denovo
git init
git remote add origin awesome@git.rc.ufl.edu:denovo.git
  • Add and edit some files
  • Commit and push to the Git server
git add *
git commit -m "Initial import"
git push origin master

Output:

Initialized empty Git repository in /git/awesome/repositories/denovo.git/
Counting objects: 3, done.
Writing objects: 100% (3/3), 231 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
To awesome@git.rc.ufl.edu:denovo.git
* [new branch]      master -> master

User Activities

Regular cycle of git repository usage

  • Clone the denovo repository
git clone awesome@git.rc.ufl.edu:denovo.git

Output:

Cloning into denovo...
remote: Counting objects: 3, done.
remote: Total 3 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (3/3), done.
  • Work in the git working tree
cd denovo

Edit and add files

  • Commit and push the changes to the repository
git add *
git commit -m "The changes I made"
git push

Git email reports

We can enable Git email reports for any repository. Please email the support or file a suport ticket. Once enabled, every "push" to the remote repository on git.rc.ufl.edu will produce a commit email report to a defined list of email addresses.

Multiple SSH keys

To enable a user to have multiple ssh keys for accessing the UFRC Git server the repository administrator can simply put the user's keys under subdirectories in the 'keydir', add, commit, and push as usual. The user must make sure they're using the right key. It's often convenient to create a SSH configuration for each particular combination of repositories and keys. For example,

  • Edit your ~/.ssh/config file on a local machine that need to be configured. Let's assume that the main configuration is
Host hpcgit
   HostName git.rc.ufl.edu
   User awesomegroup
   IdentityFile ~/.ssh/id_rsa
   

To be able to use an alternate key add the following configuration

Host hpcgit2
   HostName git.rc.ufl.edu
   User awesomegroup
   IdentityFile ~/.ssh/id_rsa_my_other_key

Once configuration is done you'll be able to check out the repository via

git clone hpcgit2:my_repository

Notes: Make sure that the User is set to your group's Git account and not your personal HPC account name.

Graphical User Interfaces to Git

How to use TortoiseGit to clone a Git Repository