Git: Distributed Development

Example Using Remote Repositories

• place an initial repository in the depot
• clone development repositories out of the depot
• do development work within them
• sync them with the depot
• a second developer will clone it, work with his repository, and then push his changes back into the depot for all to use.

Let’s use /usr/local/Depot.
No actual development work should be done directly in the /usr/local/Depot directory or in any of its repositories.
Work should be performed in a local clone.
To populate /usr/local/Depot with an initial repository ~/public_html :

# Assume that ~/public_html is already a Git repository
$ cd /usr/local/Depot/
$ git clone --bare ~/public_html public_html.git

Initialized empty Git repository is in /usr/local/Depot/public_html.git/

By convention, bare repositories are named with a .git suffix.

Right now, you have two repositories that are virtually identical, except the initial repository has a working directory and the bare clone does not.

If ~/public_html repository was created using git init and not via a clone, it lacks an origin.

If you want to populate the development Git repository ~/public_html , you need to set the remote repository.

$ cd ~/public_html
$ git remote add origin /usr/local/Depot/public_html

The remote establishes a link from your current repository to the remote repository found /usr/local/Depot/public_html.git.
Now, the name origin can be used as a shorthand reference for the remote repository.
The remote establishes a link from your current repository to the remote repository.

You can do development work in the working repository.
Any change that you commit is completely local to your repository; it is not yet present in the remote repository.
A convenient way to get your commit into the remote repository is to use the command:

git push

Git has caused the changes that were originally on your master branch to be sent to the remote repository and then has requested that they be brought back onto the origin/master tracking branch as well.

$ git show-branch -a

Once you have established an authoritative repository, it is easy to add a new developer to a project simply by letting her clone the repository and begin working.

The new developers use git clone to get the cloned repository.
More information about the origin remote can be found:

$ git remote show origin

The complete contents of the configuration file after a default clone show how it contains the origin remote:

$ cat .git/config

Practice

Init the Repo

Log in with sudo user

$ sudo mkdir /usr/local/repo
$ sudo useradd git
$ sudo chown git repo
$ sudo passwd git

change git’s shell from /bin/bash to /usr/bin/git-shell to forbid logging in for a shell for the git account:

git:x:1001:1001::/home/git:/usr/bin/git-shell

Install git-daemon:

sudo yum install git-daemon

Enable git-daemon, change /etc/xinetd.d/git

# default: off
# description: The git dæmon allows git repositories to be exported using \
        #       the git:// protocol.

service git
{
            disable         = no
            socket_type     = stream
            wait            = no
            user            = nobody
            server          = /usr/libexec/git-core/git-daemon
            server_args     = --base-path=/usr/local/repo --export-all --syslog --inetd --verbose
            log_on_failure  += USERID
            # xinetd does not enable IPv6 by default
            flags           = IPv6

}

where:

• --base-path=
Remap all the path requests as relative to the given path. This is sort of "Git root" - if you run git daemon with --base-path=/srv/git on example.com, then if you later try to pull git://example.com/hello.git, git daemon will interpret the path as /srv/git/hello.git.
• --user-path=
Allow ~user notation to be used in requests. When specified with no parameter, requests to git://host/~alice/foo is taken as a request to access foo repository in the home directory of user alice. If --user-path=path is specified, the same request is taken as a request to access path/foo repository in the home directory of user alice.

Re-start the git daemon:

systemctl restart xinetd

Log in as git

$ cd /usr/local/repo
$ git init --bare robot.git
Initialized empty Git repository in /usr/local/repo/robot.git/

The generated files under robot.git:

├── branches
├── config
├── description
├── HEAD
├── hooks
│   ├── applypatch-msg.sample
│   ├── commit-msg.sample
│   ├── post-update.sample
│   ├── pre-applypatch.sample
│   ├── pre-commit.sample
│   ├── prepare-commit-msg.sample
│   ├── pre-push.sample
│   ├── pre-rebase.sample
│   └── update.sample
├── info
│   └── exclude
├── objects
│   ├── info
│   └── pack
└── refs
    ├── heads
    └── tags

To enable the git:// support,

touch /usr/local/repo/robot.git/git-export-daemon-ok

then, execute

/usr/libexec/git-core/git-update-server-info

~/git-shell-commands should exist and have read and execute access,

cd 
mkdir git-shell-commands
chmod 755 git-shell-commands

Log in as a developer user

To clone the remote repository:

$ git clone git://10.0.0.20/robot.git

git remote

Manage the set of repositories ("remotes") whose branches you track.

Commands

With no arguments, shows a list of existing remotes.
Several subcommands are available to perform operations on the remotes

• add

git remote add [-t <branch>] [-m <master>] [-f] [--[no-]tags] [--mirror=<fetch push="">] <name> <url>

Adds a remote named for the repository at . The command git fetch can then be used to create and update remote-tracking branches /.