Differences

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

--- scmgit-intro [2020/07/11 08:41] – created perlfan
+++ scmgit-intro [2024/09/16 07:39] (current) – it” hc9
@@ Line 1: / Line 1: @@
-See //[[http://sdf.org/?tutorials/scmgit-intro]]//.
+Note: this tutorial originally appeared before //[[Hosted GIT repos - gitea on SDF]]// was offered.
+===== Introduction =====
+git is a [[wp>Version_control|source control management]] tool similiar to CVS or SVN. This tutorial will give enough information to:
+  * create a central git repository on your MetaARPA account
+  * clone that git repository to your off-site computer
+  * sync your changes with your repository copy on sdf
+  * create a public readonly copy of your repository
+The best reason why a person would use git instead of cvs or svn is that git does not require a central server. For example, let's say you were taking out a CVS repository to your laptop and would not be able to connect to the server for a month. When you get back, that entire months worth of work is seen as a single diff. Which you would have to merge by hand to the other changes, but also you couldn't differentiate between reasons you changed files. For example, let's say you fixed a bug and added a new feature. Which filechanges were for the new feature? Which for the bugfix? CVS has no clue. Enter git. You can locally “commit” changes without talking to the server, so you could have done a commit after the new feature and a commit after the bug fix and to the repository they are two unique changes.
+===== Configuring your account to use git on sdf =====
+First, you must be MetaARPA to use git.
+Second, it may be necessary to update your ''%%$PATH%%'' on the main cluster to include git. The git pkg installs most binaries you need in /usr/pkg/libexec/git-core. This needs to be in your PATH. The easiest solution is to include the following in your ''%%~/.profile%%'':
+''%%export PATH=/usr/pkg/libexec/git-core/:${PATH}%%''
+If this is necessary and you plan on accessing the repository remotely over SSH, be sure this is done even on non-login shells. This may require including it in .kshrc, .bashrc, .zshenv, .cshrc, etc.
+Now any SSH session will have the necessary git binaries in the PATH.
+===== Creating a central git repository on SDF =====
+I suggest creating a subdirectory that will hold nothing but your git repositories.. let's say it's ~/git. The server copy of the git repository need not be a useable repository (IE, the files under revision control do not need to exist.. we just need the git database to exist so we can clone from it). Under git this is called a “bare” repository.
+==== Create the server repository ====
+<code>
+    mkdir -p ~/git/myproject
+    cd ~/git/myproject
+    git --bare init
+</code>
+Note that the path is arbitrary and can be anywhere in your home directory. This can be done either on the Meta Array or on the main cluster.
+And that's it! on the server side. This remains empty until you first “push” your project to the server.
+===== Creating your local git repository. =====
+On your local machine, let's assume you already have a project you want to start watching under git, with the files
+  * ''%%~/proj/%%''
+  * ''%%~/proj/include%%''
+  * ''%%~/proj/test.c%%''
+  * ''%%~/proj/include/test.h%%''
+First, initialize the git project:
+<code>
+    cd ~/proj
+    git init
+</code>
+Now your repository is initialized! Time to check in your current project. First we add the files to the repository. I like to manually add each file instead of doing a “commit all” because “commit all” tends to collect files you never wanted to add to source control (object files, temp editing files, etc).
+<code>
+    git add test.c include/test.h
+    git commit
+</code>
+If the commit failed, follow the directions onscreen to configure your username and email so git can track you as a user in the repository.
+Now time to connect your local copy to the repository on the main cluster:
+<code>
+    git remote add origin user@sdf.org:git/proj
+    git push origin master
+</code>
+Or, if you created your repo on the Meta Array, set up your remotes like this:
+<code>
+    git remote add origin user@ma.sdf.org:git/proj
+    git push origin master
+</code>
+Git should ask for your password, and then tell you it uploaded the objects and that everything succeeded.\\
+If not, ask on the sdf forum for advise.
+===== Copying (cloning) your central repository to a client machine =====
+Last thing: Now that you have a central copy, how do you check it out? use ''%%git clone%%'' from your local machine:
+''%%git clone ssh://user@sdf.org/~/git/proj%%''
+If your repo was created on the Meta Array, adjust accordingly:
+''%%git clone ssh://user@ma.sdf.org/~/git/proj%%''
+===== Backing up all your existing git repos to a remote server =====
+sdf doesn't backup your git repository.. while any cloned git tree is basically a backup it'd be nice to have an “official” backup to go along with your now “official” git server on sdf.\\
+Here is a script that will, in sequence:
+  * check your git repo for any changes
+  * if changes exist, tar up all your git repo
+  * ftp it to another host
+The script is expecting you to have a directory called ~/git, and under that directory have your git projects named as ~/git/proj1.git, ~/git/proj2.git, etc. Otherwise modify it as you see fit.
+==== The script, git-backup.sh ====
+<code>
+#!/usr/pkg/bin/bash
+cd ~/git
+mv git-summary git-summary-old
+for i in *.git; do
+  cd $i
+  git log --pretty=oneline >> ../git-summary
+  cd ..
+done
+diff git-summary git-summary-old
+if [ "$?" != "0" ]; then
+   #tgz up the whole git directory with today's date
+   cd ..
+   rm git-latest.tgz
+   tar -cvzf git-latest.tgz git
+   ftp ftp.your-host.com <<WOOPWOOPWOOP
+   cd git-backup
+   rename git-latest.tgz git-backup.tgz
+   put git-latest.tgz
+   quit
+WOOPWOOPWOOP
+fi
+</code>
+Note: For the FTP to work, edit your ~/.netrc file so that ftp.your-host.com has an entry that looks like:
+<code>
+machine ftp.your-host.com
+    login your-user-name
+    password your-password
+    bin
+</code>
+Also ensure to run “chmod 600 ~/.netrc” to hide your credentials to the rest of the world :). Now add this to your (daily or less) cron tasks with mkcron (MetaARPA only, just like git ;) and enjoy your timely backups!
+===== Updating your local copy with changes made to the repo =====
+First, let's note that for git, each repository is equal. This is unlike older VCS like CVS or Subversion. Now, if you have not cloned from your SDF repo, do
+''%% git remote add origin user@sdf.org:git/project%%''
+where ''%%origin%%'' is the nickname for the repository on ''%%sdf.org%%''. Then, you do
+''%% git fetch%%''
+followed by
+''%% git merge%%''
+Git also provides the command ''%%git pull%%'' to do a fetch followed by a merge. This is unlike CVS and Subversion, where ''%%update%%'' works like ''%%pull%%''. The two commands are provided because your local repo is not meant to be a copy of the remote, so you need to be able to fetch the remote without merging it into your local repository.
+===== Creating a public access, read only repo =====
+Once you have your repo setup for you to do your work in, you may have a need to make your work public. Making it public allows for other users to pull specific version of your project without having to have development rights. A slight modification to your repo is needed and some webspace to host it.\\
+==== Setup some webspace ====
+To host a readonly public access version of your repo you will need to setup some space in your html directory. For our example our public repo will be accessable at http:%%//%%user.sdf.org/devel/proj.git\\
+\\
+''%%mkdir ~/html/devel%%''\\
+==== hooks/post-update ====
+In your repo directory for the project there is a directory that contains a set of scripts which are called at different times during your interaction with git. For more information about the “hooks” directory check out [[http://www.kernel.org/pub/software/scm/git/docs/githooks.html|githook]].
+The script we will need to modify is post-update. This script is called after an update has occured on the server side of your repo.
+<code>
+#!/bin/sh
+#
+# File: ~/git/proj.git/hooks/post-update
+#
+# Description: Called when an update is pushed to the server
+#
+# Location of your repo on the server
+GIT_DIR=/arpa/tz/u/user/git/proj.git
+# Location of your public version of the repo
+HTTP_DIR=/arpa/tz/u/user/html/devel/proj.git
+# Update local repo info
+git update-server-info
+# Make sure a clean copy is moved
+rm -rf $HTTP_DIR
+cp -rf $GIT_DIR $HTTP_DIR
+chgrp -R nobody $HTTP_DIR
+# Directories must have Read and Execute Permissions
+# for apache to be able to navigate them.
+for d in `find $HTTP_DIR -type d`; do
+  chmod a+rx $d
+done
+# Files must have Read Permissions for apache
+# to be able to read them.
+for f in `find $HTTP_DIR -type f`; do
+  chmod a+r $f
+done
+# Display a message on the client side to show
+# the action has been performed.
+echo "Updated Public Access"
+</code>
+Now that you have setup this script make sure its executable.
+''%% chmod a+x ~/git/proj.git/hooks/post-update%%''
+You can now run the script directly or wait until you have committed and pushed an update to your server.
+==== Verifying script is run. ====
+When you push an update to your private development repo, a new output has been added by our script.
+<code>
+$ git push
+Counting objects: 5, done.
+Compressing objects: 100% (2/2), done.
+Writing objects: 100% (3/3), 256 bytes, done.
+Total 3 (delta 1), reused 0 (delta 0)
+remote: Updated Public Access
+To user@sdf.org:git/proj.git
+   e60a9de..1f8a43f  master -> master
+$
+</code>
+In the above example there is a new line labled “remote” which means that during the push, the server produced output. The line matches the last line in our post-update script. Now you have two methods of access.
+**Private Access:** git clone user@sdf.org:~/git/proj.git\\
+**Public Readonly Access:** git clone http:%%//%%user.sdf.org/devel/proj.git\\
+===== Allowing Multiple Users git Access =====
+If you want to use your git repo for a group project and need multiple users access this can be done with the user of SSH Keys.
+==== Create SSH Key ====
+The first step is creating an ssh key for a user. On their local machine generate a key pair and have them send you the public key.
+<code>
+# ssh-keygen -t dsa
+Generating public/private dsa key pair.
+Enter file in which to save the key (/home/joe/.ssh/id_dsa): /home/joe/.ssh/sdf-dev
+Enter passphrase (empty for no passphrase):
+Enter same passphrase again:
+Your identification has been saved in /home/joe/.ssh/sdf-dev
+Your public key has been saved in /home/joe/.ssh/sdf-dev.pub.
+The key fingerprint is:
+e:aa:25:bb:2e:ec:ee:93:ff:ef:a1:21:8a:fe:df:fc joe@mypc
+The key's randomart image is:
++--[ DSA 1024]----+
+|+++.+.           |
+|=*+ ..    =+     |
+|*++   .  - ..    |
+|.o ..= S         |
+|  E   . S        |
+|     o   .  o +  |
+|  ++  .          |
+|  +      S  o    |
+|     +++         |
++-----------------+
+# ls /home/joe/.sdf
+sdf-dev sdf-dev.pub
+</code>
+==== Create a git access script ====
+The next task is to create a script that runs git's shell command to create an instance of a shell that only allows git commands. Store this in your home directory along with all the other scripts and binaries you keep for personal use.
+<code>
+#!/bin/sh
+exec git-shell -c "$SSH_ORIGINAL_COMMAND"
+</code>
+The ''%%$SSH_ORIGINAL_COMMAND%%'' variable contains the commands issued with your ssh session (try logging in with ''%%ssh localhost ls%%'').
+==== Add User to Authorized Keys ====
+The last step is to add the user's public key to your ''%%authorized_keys%%'' file. This will be a little different than you normally would enter one, as we want to force the user to run our git access script instead of a normal shell. At the end just paste the contents of the public key as you normally would.
+<code>
+command="/arpa/gm/f/frank/gitaccess.sh",no-port-forwarding,no-agent-forwarding,no-x11-forwarding,no-pty ssh-rsa AAAB3...
+</code>
+All the ''%%no-*%%'' flags disable all other types of ssh access (Port Forwarding, X11, PTY) so we only get git access and nothing else. Now if your friend uses your user name and his/her ssh key to connect to your git server they will be able to clone, pull, commit, etc. just as if they were you. Make sure they set their global settings in their git client so you can see your history correctly.
+===== TODO =====
+merging/branching\\
+Best look online for more in-depth tutorials.. I haven't needed these features yet as my projects are all just me, so I don't know how to do it!\\
+$Id: scmgit-intro.html,v 1.11 2020/01/01 22:52:17 niro Exp $
+----
+©1987-2065 [[http://sdf.org|SDF Public Access UNIX System]], Inc. 501(c)(7)\\
+(//this page was generated using ksh, sed and awk//)
+Originally appeared at https://sdf.org/?tutorials/scmgit-intro