GIT
This is a more distributed manner of source code repository functionality.
* This documentation is loosely based on: [http://scie.nti.st/2007/11/14/hosting-git-repositories-the-easy-and-secure-way | hosting-git-repositories-the-easy-and-secure-way]
* This assumes both server and client are Ubuntu 10.04 LTS
If you are used to svn or cvs, be not worried. GIT, can act like a
centralized repository, if you wish. In fact what I did below is just that,
it allows the following:
- central repository
- remote administration of central repository
- once set up, the administrator will not need shell access to the central server
- authentication via ssh key exchange
- authorization via gitosis.conf (this is where you define what users do what)
- remote repository user setup, only once during setup does the admin need shell access to the central server.
Now, GIT, is very flexible, and at some point, REVIEW the RESOURCES, you may
find that “centralized repository(s)” may not be in your best interest anymore, that is where GIT will shine even more.
Install GIT on Server
aptitude install git-core build-essential gitosis adduser --system --shell /bin/bash --gecos 'git version control' --group --disabled-password --home /home/git git
Install GIT on Client (a developer machine)
aptitude install git-core gitosis
SETUP a GIT ADMINISTRATOR
* This method allows one to administer remotely and securely without having to login to a shell account on the git main repository
* “So we’re using Git to host the configuration file and keys that in turn define how our Git hosting behaves. That’s just plain cool.”
# ON CLIENT # make a git directory for your efforts as an admin cd $HOME mkdir git # make the ssh id something like id_git so you don't step on your other id_rsa ssh ids # we will assume it is "id_git" from here on. ssh-keygen vi ~/.ssh/config # and add a section for git
Host central_git Hostname YOUR-SERVER IdentityFile ~/.ssh/id_git [...]
# STILL ON CLIENT scp id_git.pub YOUR-SERVER:/tmp/ # ON YOUR-SERVER sudo -H -u git gitosis-init < /tmp/id_git.pub # THAT IS THE LAST TIME YOU NEED TO BE ON YOUR SERVER # from here on, you will administer from your local machine, # once that is, that you clone the gitosis-admin.git.... as we will # now do, pretty cool if you ask me. # ON CLIENT git clone git@central_git:gitosis-admin.git # now within your "git" dir you made at the first step of this # section you will have the gitosis-admin dir.
Creating NEW Repositories
Configure new repository
This example is using SOME-SOURCE (substitute for you own needs string SOME-SOURCE).
* NOTICE, we don’t have the source code yet.
cd git/gitosis-admin # or wherever your gitosis-admin dir is mkdir SOME-SOURCE vi gitosis.conf # and make it so
[gitosis] [group gitosis-admin] writable = gitosis-admin members = ADMIN-USER-YOU-ARE [group dev-team] members = ADMIN-USER-YOU-ARE writable = SOME-SOURCE
git commit -a -m "Allow ADMIN-USER-YOU-ARE write access to SOME-SOURCE" git push
Repository From EXISTING source
# now using your source, cd git mkdir SOURCE-TO-IMPORT-DIR cd SOURCE-TO-IMPORT-DIR # make a copy of your source you wish to import. Best not to fiddle in your golden copy if ya know what I mean. cp -vrp THE-ORIGINAL . # that will make a copy of SOME-SOURCE WITHOUT the hidden .svn files/dirs
Now we will import existing source into a git repository “SOME-SOURCE”
cd SOURCE-TO-IMPORT-DIR git init git remote add origin git@central_git:SOME-SOURCE.git git add -A #this will add the entire source tree git commit -am "initial import" git push origin master
Now go to a temp location and clone your new repository.
cd ~/temp git clone git@central_git:SOME-SOURCE.git # then compare with the original and make sure all is well.
Now remove the source tree that you used to make that repository. Yes, remove. Why? Trust me you will alleviate many headaches if you do. Better to have what your collaborators will have as well. That way
cd git rm -rf SOURCE-TO-IMPORT-DIR # then clone again git clone git@central_git:SOME-SOURCE.git # now work.
Using GIT
* NOTE: I am rather new to git. But so far what I have done works.
* Resources: [[ http://git.or.cz/course/svn.html | Git/SVN Crash Course ]]
Administrator Adding New Users
See, the above code “via YOUR-SERVER… do gitosis-init < some_key.pub". Well THAT ONLY WORKS when you FIRST setup the central server , in our case, YOUR-SERVER. SO HOW DO WE DO IT NOW…
As the Administrator working from YOUR PC
DANGER:… when you add a public ssh key, as you will see below, git does not like “jdoe@mymac.local” or “goon@mypc.local”, etc. Get rid of the “@blah”, just keep the user name of the shell account. You will see in the public key, at the end, a “== jdoe@mypc.local”, just make it “== jdoe”, simple as that, (SANS the double quotes mind you).
cd gitosis-admin #ASSUMING YOU CLONED THIS FROM YOUR-SERVER cp ~/alice.pub keydir/ cp ~/bob.pub keydir/ git add keydir/alice.pub keydir/bob.pub # EDIT YOUR gitosis.conf to allow bob and alice rights to various git repositories vi gitosis.conf # and make it somewhat like this example below
[group myteam] - members = jdoe + members = jdoe alice bob writable = free_monkey
#NOW COMMIT git commit -a -m "Granted alice and bob rights to free_monkey repository" git push # THIS IS CRITICAL
What will happen
* is their public keys will be added to YOUR-SERVER:/home/git/.ssh/authorized_keys.
* NOW they can do such things as git clone git@central_git:freemonkey.git
Man Page
# REVIEW this man gittutorial # Also review and it's suggestions on man pages man git
Cloning a Project
* Similar to “svn checkout” however not quite the same.
* Below is a “mac-mini” Example session
git clone git@central_git:mac-mini.git # ok, now see what you got (optional) find mac-mini/ # ok, now see what you got without the ".git" business (optional) find mac-mini/ | grep -v '.git' cd mac-mini/ vi Users/mmadmin/bin/rdwr.sh git diff # see your changes git commit -a # you will be prompted for a message from yourself as to why you committed, just like svn vi System/Library/LaunchDaemons/rdwr.plist git diff git commit -a
Examples
Two Developers
Sienna: git clone
Eli: git clone
BEST CASE:
Sienna:
vi index #make changes
git commit -a
git push
Eli (after Sienna pushes)
git pull #index.php is updated
vi index.php #make changes
git commit -a
git push
BAD CASE
Sienna: vi index.php #make changes
Eli: vi index.php #make changes
Sienna: git commit -a; git push # before Eli commit,push
Eli: git commit -a
Eli: git push #this is "rejected".... what to do for eli???
WHAT TO DO after the "rejection"
Eli:
git diff origin #origin is the YOUR-SERVER that both push to
# HOWEVER, the mod "_SIENNA_VARS_2" is not listed
git pull # this reveals "<<<<<<<<<<<<; HEAD ..... >>>>>>>>>>>>>> some-md5sum-value
vi index.php #within will now be the "<<<<<<<<<<< HEAD ..... >>>>>>>>>>>>>>>> some-md5sum-value
#Eli does a manual merge
git commit -a # Now, a very descriptive comments is ready for more comments
git push # all is well now.
NOW...... SIENNA does this
git pull #now the changes of eli and her are matching.
RESOURCES
* [[ http://progit.org/book/ch5-2.html ]]: This is great and is relative to how we have git setup, especially the part of “Private Small Team…. You and the other developers all have push access to the repository.”…. very cool in-deed.
* [[ http://scie.nti.st/2007/11/14/hosting-git-repositories-the-easy-and-secure-way ]]
* [[ http://www.x2on.de/2011/04/23/tutorial-redmine-with-git-and-gitosis-on-ubuntu-11-04/ ]]
* [[ http://www.redmine.org/projects/redmine/wiki ]]
* [[ http://sourceforge.net/apps/wordpress/redmin-mylyncon/ ]]
* [[ http://git.or.cz/course/svn.html ]]
* [[ http://smalltalk.gnu.org/blog/bonzinip/using-git-without-feeling-stupid-part-1 ]]
Not logged in