From SLangTNG
Contents |
Git interfaces
This page gives a short overview on what Git is, in which use cases it can be applied and where to check out data from.
What is Git?
Git is a versioning system such as RCS, CVS, SVN, Mercurial, etc. It helps to administrate the source code of TNG including versioning control, locking, merging changes etc. The basic idea is that a central repository is located at a special file server. Developers may communicate via Git with this repo in order to tell the other developers which changes he made, and to obtain the changes of the other developers being made to the source tree.
The reasons for using Git in opposite of CVS and SVN are
- high flexibility (providing many different use cases) needed for establishing a community and interact with third-party developers.
- distributed network capabilities - commit changes without being online.
- minimal memory and network requirements
- an active supporting community (originally used by Linux kernel developers)
The logic behind Git is quite different compared with CVS and SVN, but once learned is as simple as the others.
Possible use modes
There are different use modes available when using git:
- individual repo clones:
- Every user updates and clones against other users. This is only recommended when the developer team is very small.
- master users:
- Every user clones against a master repo. When changes are to be committed, the master user will be informed and he will "pull" the changes from the user. Changes may be reviewed, accepted or declined. This is recommended when third-party developers try to commit code.
- Shared repository:
- A central repo is cloned from the master repo being tagged as "shared". Users who clone the shared repo can "push" their changes to the shared repo. This is a probable choice for internal developers, see sections "Editing" and "Working with a shared repo"
- A public repo serves as a public mirror which is not intended as working repository, but as interface for others in the outside world to fetch from.
Workflows of the configured repositories
Master
user commits changes to temp. branches | | user pulls V master repo -----------------------> user repo with changes | ^ | | reviews changes and | user merges possible conflicts and | merges user branch | continues his work | | | V master repo <----------------------- user repo master fetches with changes
Clone the repository:
git clone user@servername:location myrepo
which creates directory "repo" containing a copy of the repository. The copy is a real "copy" with its own history and management!
You can commit to your own repo as long as you wish. When being finished the main user (TNG master) must pull the changes from your repository:
cd location git pull $HOME_OF_YOU$/myrepo master
All changes are merged into the master branch. The TNG master must solve conflicts if they appear.
One can check what the other user did without trying to merge:
git fetch /home/bob/myrepo master git log -p HEAD..FETCH_HEAD
(show everything that is reachable from the FETCH_HEAD but exclude anything that is reachable from HEAD)
A visualization can be done using gitk or qgtk
gitk HEAD..FETCH_HEAD
Shared
user commits changes to temp. branches | | shared pulls user pulls V master repo ---------------------> shared repo --------------------> user repo <--------------------- ^ | master fetches | | | | user merges possible conflicts and | | continues to work | | | V +------------------------------- user repo with user pushes committed changes
For shared (trusted) access to a repository a local clone of the master repo has been created which is marked as a shared repository.
In order to clone the shared repository, type
git clone git clone user@servername:location myrepo my-project cd my-project
Public
you push your personal repo ------------------> your public repo ^ | | | | you pull | they pull | | | | | they push V their public repo <------------------- their repo
Users may fetch from this repo, but may not be able to push changes to it. The idea is that any developer has two repositories, a private and a public one. Then, the workflow is
In order to clone the public repository, type
git clone git clone user@servername:location myrepo my-project cd my-project
Creating the repositories
Creating a git repo
cd project-directory git init
Let git take a snapshot of the working dir:
git add .
Now the contents is stored in a temporary staging area called "index"
git commit
Remote repository
Define a remote repository (add user "bob"):
git remote add bob /home/bob/myrepo
Using this, TNG master can fetch the changes without pulling:
git remote add bob /home/bob/myrepo
The changes of bob are stored in an own branch ("bob/master") which can be reviewed. Let show the changes of bob
git log -p master..bob/master
and merge them:
git merge bob/master
Later, Bob can update his repo with the last changes of TNG master doing
git pull
Shared
Assume that there is already a git repo existing, being located at
servername:location
Create a new "bare" repository (a repository without a working tree) and fetch your project into it:
mkdir shared.git cd shared.git git --bare init --shared git --bare fetch servername:location master:master
Next, give every team member read/write access to this repository. One easy way to do this is to give all the team members ssh access to the machine where the repository is hosted. If you don't want to give them a full shell on the machine, there is a restricted shell which only allows users to do git pushes and pulls; see git-shell(1).
Put all the committers in the same group, and make the repository writable by that group:
chgrp -R tng shared.git
Note:
- Make sure committers have a umask of at most 027 (particularly Ubuntu/Mac), so that the directories they create are writable and searchable by other group members.
- Developers who are allowed to have shared access, must be part of the same group. They have to clone the directory shared.git
Public
The public repository was created via
git clone --bare SLangTNG public.git touch public.git/git-daemon-export-ok
Anonymous HTTP
Install git-daemon Docu:
http://www.bluishcoder.co.nz/2007/09/how-to-publish-git-repository.html
Steps:
git clone --bar public.git tng_public sudo cp -rf tng_public/ /srv/git/ rm -rf tng_public chmod +x /srv/git/tng_public/hooks/post-update
After your nightly update, do:
git push /srv/git/tng_public
or to specify branches
git push /srv/git/tng_public mybranch:master
To enable the git:/ protocol,
touch /srv/git/tng_publicgit-daemon-export-ok
To enable the http protocol, link the repo to your www root.
Configure Git to interact with CVS
Please, use git directly and not the CVS emulator.
In order to set up your environment to commit using CVS, follow these steps:
- Check out the repository (CVS version > 1.12.11)
- cvs -d ":ext;CVS_SERVER=git cvsserver:user@server/path/repo.git" co \<HEAD_name>
- If you didn't specify the CVSROOT/CVS_SERVER directly in the checkout command, automatically saving it in your CVS/Root files, then you need to set them explicitly in your environment:
- export CVSROOT=:ext:user@server:/var/git/project.git
- export CVS_SERVER="git cvsserver"
- For SSH clients that will make commits, make sure their server-side .ssh/environment files (or .bashrc, etc., according to their specific shell) export appropriate values for
- GIT_AUTHOR_NAME,
- GIT_AUTHOR_EMAIL,
- GIT_COMMITTER_NAME, and
- GIT_COMMITTER_EMAIL.
- Clients should now be able to check out the project. Use the CVS module name to indicate what GIT head you want to check out. This also sets the name of your newly checked-out directory, unless you tell it otherwise with -d <dir_name>. For example, this checks out master branch to the project-master directory:
cvs co -d project-master master