Cheap VPS & Xen Server


Residential Proxy Network - Hourly & Monthly Packages

Debian Wheezy Local Git Server With Git Lite Workflow


Introduction

This howto describes a shared local git [1] server setup for a small team. This is a repository layout that is familiar to anyone used to working with a traditional version control system.

One of the tutorial objectives is to show detailed steps to prepare the server (here called the depot because of its authoritative role) and publish the code on a public service like Github, Gitorious [2,3] et. al.

A second objective is to introduce the Git Lite Workflow in team development. This serves as an introduction to gits powerful branch and merge features. Your personal favorite workflow may be different compared to this model. For a feature rich workflow albeit more complex, see nvie [4].

To facilitate the description we have two team members. Alice, who code and is responsible for all releases. A second team developer is Bill. Their shared git server have the private IP address 192.168.0.100.

They both work for an open source friendly company EXAMPLE with domain example.com. Alice have set up a project repository at Github with the url https://github.com/alice/My-Module.git.

If you want to replay this howto, set up a free public Github repository. Follow Githubs instructions but do not add README or .gitignore files. This howto push an existing repository to this Github repository.

This tutorial has been tested on Debian Wheezy with following versions:

$ uname -a ; lsb_release -d ; git –version ; ssh -V

Linux debinix 3.2.0-4-686-pae #1 SMP Debian 3.2.32-1 i686 GNU/Linux
Description: Debian GNU/Linux testing (wheezy)
git version 1.7.10.4
OpenSSH_6.0p1 Debian-3, OpenSSL 1.0.1c 10 May 2012

 

Install git on the server

Install git and create a git1 user on the depot server to authorize git push and pull access. As an extra precaution restrict this git1 user to only doing git activities with a limited shell tool called git-shell. This is included with git. With this as shell our git1 user can’t have normal shell access to the git server.

# aptitude install git

Add a new password for this git1 user in the adduser script and use e.g. Git Group 1 as Full Name.

# adduser –shell /usr/bin/git-shell git1

To use this shared git depot Alice and Bob must know this password in order to collaborate as a team in this project. If very fine-grained access control is required then look at the gitolite project [5].

Confirm that git1 user shell is set to git-shell with:

# cat /etc/passwd | grep git1

Git first time settings includes adding depot user information:

# git config –system user.name “Git Depot”
# git config –system user.email “root@example.com”

Server tasks can be performed remotely if secure shell is installed. If not already installed, install it with:

# aptitude install openssh-server

 

Create the shared git project depot on the server

The root of the depot is e.g. created below /srv with:

# mkdir /srv/git1
# chown root:git1 /srv/git1
# chmod 0750 /srv/git1

Create a project and name it e.g. My-Module.git:

# mkdir /srv/git1/My-Module.git
# chmod 0750 /srv/git1/My-Module.git

Initialize a bare git repository in the project directory:

# cd /srv/git1/My-Module.git
# git –bare init
# chown -R git1:git1 /srv/git1/My-Module.git

Repeat these last five steps to setup a new project on the depot server.

 

Project authentication for git users

Users authenticate with ssh keys. Alice and Bill does not need a password for the key itself since git on the server use the git1 account password for authorization. Note: There is no need to create a new ssh key if it already exist. Use it also for the git server.

On Alice workstation, switch user to alice and accept the default ssh-keygen options when creating her key:

# su alice
$ ssh-keygen

This created the id_rsa.pub file in directory ~/.ssh.

Copy her public key to the depot server (not the private key!).

$ exit
# scp /home/alice/.ssh/id_rsa.pub root@192.168.0.100:/tmp

Use ssh to access the depot sever at address 192.168.0.100:

# ssh root@192.168.0.100
root@192.168.0.100’s password: *********

Once logged in at the server, append this key to git1 authorization_keys file in /home/git1/.ssh. Adding new users can be done with a shell script:

# cd /usr/local/bin
# nano ssh.addkey

In this file add:

#!/bin/sh
test  !  -d  /home/$1/.ssh && mkdir  /home/$1/.ssh
chmod  0700  /home/$1/.ssh
cat  /tmp/id_rsa.pub  >>  /home/$1/.ssh/authorized_keys
chmod  0600  /home/$1/.ssh/authorized_keys
chown  -R  $1:$1  /home/$1/.ssh
rm  /tmp/id_rsa.pub

Save it and make this script executable:

# chmod 0700 ssh.addkey
# exit

Add appropriate error checks to this script. Whenever a new user needs to be added to group git1 on depot server invoke it like so:

# ssh root@192.168.0.100 ssh.addkey git1

Don’t forget to copy the ssh key to directory /tmp on the server first.

 

Desktop (Alice) git preparations

Install git and gitk (revision tree visualizer) on alice machine:

# aptitude install git
# aptitude install gitk

Add some information about Alice:

# su alice
$ git config –global user.name “Alice”
$ git config –global user.email “alice@example.com”

Continue and add some useful settings in ~/.gitconfig:

$ nano ~/.gitconfig

Add these lines in the file:

[user]
    name = Alice
    email = alice@example.com
[color]
    ui = auto
[core]
    editor = /bin/nano
[alias]
    com = commit
    sta = status
    sw2 = checkout
    nbr = checkout -b
    vhi =  <see Note 2>
    vbr = branch -a
    vre = remote -v
    mer = merge --no-ff
    mef = merge --ff-only
    dif = diff --staged

The merge option, –no-ff, helps maintaining the history, for which commits implemented a specific feature, after it have been merged into another branch.

Naturally you can put any development files you like in the project directory but for the purpose of this howto Alice plans a new Perl module. Alice initiate the new Perl project wisely and install one Comprehensive Perl Archive Network (CPAN [6]) distribution that helps create a good start set of files called Module::Starter::PBP.

# aptitude install libmodule-starter-pbp-perl

To set up module-starter (i.e. setup its configuration and templates), run as user alice:

$ perl -MModule::Starter::PBP=setup

Creating /home/alice/.module-starter/PBP…done.
Creating /home/alice/.module-starter/PBP/t…done.
Creating /home/alice/.module-starter/config…
Please enter your full name: Alice Wonderland
Please enter an email address: alice@example.com
Writing /home/alice/.module-starter/config…
done.
Installing templates…
/home/alice/.module-starter/PBP/Build.PL…done
/home/alice/.module-starter/PBP/Makefile.PL…done
/home/alice/.module-starter/PBP/README…done
/home/alice/.module-starter/PBP/Changes…done
/home/alice/.module-starter/PBP/Module.pm…done
/home/alice/.module-starter/PBP/t/pod-coverage.t…done
/home/alice/.module-starter/PBP/t/pod.t…done
/home/alice/.module-starter/PBP/t/perlcritic.t…done
Installation complete.

The configuration file is in ~/.module-starter.

Option: To install the latest Module::Starter::PBP module direct from CPAN use the Perl installer tool cpanminus. As root install cpanminus:

# aptitude install cpanminus
# cpanm Module::Starter::PBP

Git Lite Workflow configuration

Workflow organization

Alice and Bill have agreed on an easy to use workflow model for their project. Two long-lived branch exists and a number of shorter-lived local topic branches.

Activities in branch master (i.e. for public released code).

  • Never, ever, do any development here. This master is for stable releases.
  • Release new code by merging with a fast-forward, from next.
  • Push master branch to Github to release this new version.

The integration branch next.

  • Branch next suppose to be stable most of the time.
  • New code from topic branches are merged into next by each developer.
  • A release is initiated in the Changes file and with a git version tag.
  • Each developer updates this Changes file when topics have been merged in.

 

Local shorter-lived topic branches.

  • Always code in topics branches (bug fixes, new features, documentation etc).
  • Create new topic branches from the authorized branch depot/next.
  • New code is merged into next after successful local unit testing.

 

Naturally, other workflow models exists but the point here is to practice, and modify to find out what works best in your team. Simplicity is the focus here. Depending on the language used for the project the file Changes may be named differently but its role is similar.

 

Public repository preparations

To follow this howto a Github hosted repository is required. In this example its assumed that the public user is alice and at this point of the tutorial the repository url is similar to:

https://github.com/alice/My-Module.git

This howto push an existing repository to this Github repository.

Alice creates project My-Module

Create the new project My-Module (without .git) with module-starter.

$ mkdir ~/projects
$ cd ~/projects
$ module-starter –module=My::Module –dir=My-Module –builder=Module::Build –verbose

This created a start set of files for the project in My-Module directory:

$ cd My-Module
$ ls -l

-rw-r–r– 1 alice alice 429 Dec 14 11:14 Build.PL
-rw-r–r– 1 alice alice 90 Dec 14 11:14 Changes
drwxr-xr-x 3 alice alice 4096 Dec 14 11:14 lib
-rw-r–r– 1 alice alice 123 Dec 14 11:14 MANIFEST
-rw-r–r– 1 alice alice 979 Dec 14 11:14 README
drwxr-xr-x 2 alice alice 4096 Dec 14 11:14 t

Initialize the git repository:

$ git init
Initialized empty Git repository in /home/alice/projects/My-Module.git/

Add a shortcut url to upstream origin repository for branch master:

$ git remote add origin https://github.com/alice/My-Module.git

View (v) the remote (re) repository shortcuts:

$ git vre

origin https://github.com/alice/My-Module.git (fetch)
origin https://github.com/alice/My-Module.git (push)

Add all project files to master branch and commit:

$ git add –all
$ git sta
$ git com -m ‘Initial commit’

Push first commit to Github:

$ git push -u origin master

Counting objects: 14, done.
Compressing objects: 100% (12/12), done.
Writing objects: 100% (14/14), 4.33 KiB, done.
Total 14 (delta 0), reused 0 (delta 0)
To https://github.com/alice/My-Module.git
* [new branch] master -> master
Branch master set up to track remote branch master from origin.

You only need to add option -u (–set-upstream) the first time you push. After this you can push to Github without any additional parameters in the push command as long as your current branch is master.

 

Configure the remote server depot/next

Alice names the project and adds a shortcut to the authorized depot to be used for all team members in her project:

$ git remote add depot git1@192.168.0.100:/srv/git1/My-Module.git

View (v) all remote (re) repository shortcuts:

$ git vre

depot git1@192.168.0.100:/srv/git1/My-Module.git (fetch)
depot git1@192.168.0.100:/srv/git1/My-Module.git (push)
origin https://github.com/alice/My-Module.git (fetch)
origin https://github.com/alice/My-Module.git (push)

Note that a push or pull or fetch depends the current branch. See Note 1 on last page, howto change the prompt to show your current branch.

 

Create and push the next branch to depot server

Following the concepts of Gite Lite Workflow create a new (n) local integration branch (br) next:

$ git nbr next

$ git push -u depot next

Counting objects: 14, done.
Compressing objects: 100% (12/12), done.
Writing objects: 100% (14/14), 4.33 KiB, done.
Total 14 (delta 0), reused 0 (delta 0)
To git1@192.168.0.100:/srv/git1/My-Module.git
* [new branch] next -> next
Branch next set up to track remote branch next from depot.

The last command pushed master branch content to depot/next and configured depot/next as the upstream branch when current branch is next.

Create a new (n) milkshake topic branch (br) for initial project code:

$ git nbr milkshake

View (v) all branches (br):

$ git vbr

master
next
* milkshake
remotes/depot/next
remotes/origin/master

When a new branch is created its made the current branch.

 

Development work

Alice works on her milkshake topic branch and commit three times.

Open the README file in an editor:

<edit README: add a new text line and the word “milk.” >
$ git add –all
$ git sta
$ git com -m ‘Added milk’

Continue to change the file:

<edit README: add a new text line and the word “banana.”>
$ git add –all
$ git sta
$ git com -m ‘Added banana’

Finally the third time additions:

<edit README: add a new text line and the word “ice cream.”>
$ git add –all
$ git sta
$ git com -m ‘Added ice cream’

Note that using git dif where git sta is used above would have shown the changes in the staged files compared to latest commit.

View (v) history (hi) of commits:

$ git vhi

* 2eed2f7 – (HEAD, milkshake)Added ice cream(8 minutes ago) <alice>
* 45cdbf2 -Added banana(11 minutes ago) <alice>
* d96a45c -Added milk(14 minutes ago) <alice>
* 384b71b – (origin/master, depot/next, next, master)Initial commit(33 minutes ago) <alice>

See Note 2, last page, for the git vhi alias. Use gitk as an alternative command to view commit history:

$ gitk

When the milkshake code have passed the unit test suit it is merged into next branch.

Switch (sw) to (2) next and merge changes into next with option –no-ff:

$ git sw2 next

$ git mer milkshake

Merge made by the ‘recursive’ strategy.
README | 5 +++++
1 file changed, 5 insertions(+)

The git mer alias takes care of the –no-ff option. View (v) commit history (hi) after the last merge:

$ git vhi

* 5164966 – (HEAD, next)Merge branch ‘milkshake’ into next(79 seconds ago) <alice>
|\
| * 2eed2f7 – (milkshake)Added ice cream(25 minutes ago) <alice>
| * 45cdbf2 -Added banana(28 minutes ago) <alice>
| * d96a45c -Added milk(31 minutes ago) <alice>
|/
* 384b71b – (origin/master, depot/next, master)Initial commit(50 minutes ago) <alice>

Public release on master

On branch next, update Changes file and any other files that contains a reference to the version number.

If Alice does not intend to bring this particular change to a full release she adds the change text, but leaves a template identifier like [% nextrev %] or {{NEXT}} as a placeholder for the revisions number.

When she decides to release a new version, she first updates branch next with the current authorized code from branch depot/next:

$ git pull

Project files may also contain revision information. Edit these:

< edit any project files that contains any revision number >

Finally, edit the file Changes and the template identifiers with the actual version information for this release:

$ nano Changes
< edit the Changes file with new version and save >

Run the unit test suit after any edits and then commit the code. These unit tests are frequently run as a form of regression test in branch next.

$ git add –all
$ git sta
$ git com -m ‘version 0.0.2’

Before merging with master, tag it with the new version number:

$ git tag -a v0.0.2 -m ‘version 0.0.2’

View (v) the history (hi):

$ git vhi

* b437a9c – (HEAD, v0.0.2, next)version 0.0.2(52 seconds ago) <alice>
* 5164966 -Merge branch ‘milkshake’ into next(25 minutes ago) <alice>
|\
| * 2eed2f7 – (milkshake)Added ice cream(49 minutes ago) <alice>
| * 45cdbf2 -Added banana(52 minutes ago) <alice>
| * d96a45c -Added milk(55 minutes ago) <alice>
|/
* 384b71b – (origin/master, depot/next, master)Initial commit(74 minutes ago) <alice>

Alice switch (sw) to (2) branch master for the public Github release:

$ git sw2 master

View (v) the history (hi):

$ git vhi

* 384b71b – (HEAD, origin/master, depot/next, master)Initial commit(80 minutes ago) <alice>

Note that master branch only knows about the initial commit.

Merge branch next with a fast forward (always) into branch master. The fast forward updates the branch pointer, without creating a merge commit:

$ git mef next

Updating 384b71b..b437a9c
Fast-forward
Changes | 5 ++++-
README | 5 +++++
2 files changed, 9 insertions(+), 1 deletion(-)

View (v) the history (hi):

$ git vhi

* b437a9c – (HEAD, v0.0.2, next, master)version 0.0.2(11 minutes ago) <alice>
* 5164966 -Merge branch ‘milkshake’ into next(35 minutes ago) <alice>
|\
| * 2eed2f7 – (milkshake)Added ice cream(59 minutes ago) <alice>
| * 45cdbf2 -Added banana(62 minutes ago) <alice>
| * d96a45c -Added milk(65 minutes ago) <alice>
|/
* 384b71b – (origin/master, depot/next)Initial commit(84 minutes ago) <alice>

Now HEAD, next and master have been aligned with the git merge alias git mef.

Push the new version to the public repository origin/master at Github:

$ git push

Counting objects: 17, done.
Compressing objects: 100% (14/14), done.
Writing objects: 100% (14/14), 1.43 KiB, done.
Total 14 (delta 8), reused 0 (delta 0)
To https://github.com/alice/My-Module.git
b2b4804..506483c master -> master

Note that that branch depot/next is not updated with these recent changes.

 

Update branch depot/next and dispose the topic branch

Switch (sw) to (2) branch next again.

$ git sw2 next

Switched to branch ‘next’
Your branch is ahead of ‘depot/next’ by 5 commits.

Branch depot/next is still at the original commit as seen with:

$ git vhi

* b437a9c – (HEAD, v0.0.2, origin/master, next, master)version 0.0.2(16 minutes ago) <alice>
* 5164966 -Merge branch ‘milkshake’ into next(41 minutes ago) <alice>
|\
| * 2eed2f7 – (milkshake)Added ice cream(65 minutes ago) <alice>
| * 45cdbf2 -Added banana(68 minutes ago) <alice>
| * d96a45c -Added milk(70 minutes ago) <alice>
|/
* 384b71b – (depot/next)Initial commit(2 hours ago) <alice>

Update branch depot/next with a push:

$ git push

Any other team developer can now pull down recent updates from depot/next to their local desktop before branching off in a new topic branch.

Dispose the milkshake branch with:

$ git branch -d milkshake

Deleted branch milkshake (was c9e0441).

 

Add developer Bill to My-Module project.

Install git and gitk (revision tree visualizer) at Bills machine with:

# aptitude install git
# aptitude install gitk

Bill is ready to work on the project, when his public ssh key (~/id_rsa.pub) has been added to the git1 user on the depot server (see first page). Set up git user information:

$ git config –global user.name “Bill”
$ git config –global user.email “bill@example.com”

Add the git aliases (see first page) and set up the local project directory:

$ mkdir ~/projects
$ cd ~/projects

Clone the project repository from the remote origin which were named depot and the branch named depot/next:

$ git clone -o depot -b next git1@192.168.0.100:/srv/git1/My-Module.git

Confirm that the repository was cloned:

$ cd My-Module
$ ls -l

-rw-r–r– 1 bill bill 429 Dec 14 11:14 Build.PL
-rw-r–r– 1 bill bill 90 Dec 14 11:14 Changes
drwxr-xr-x 3 bill bill 4096 Dec 14 11:14 lib
-rw-r–r– 1 bill bill 123 Dec 14 11:14 MANIFEST
-rw-r–r– 1 bill bill 979 Dec 14 11:14 README
drwxr-xr-x 2 bill bill 4096 Dec 14 11:14 t

Now Bill is ready to work on the new project.

Git push and pull configuration for his repository was automatically setup by git since the project was cloned from the server.

View (v) the remote (re) configuration information:

$ git vre

depot git1@192.168.0.100:/srv/git1/My-Module.git (fetch)
depot git1@192.168.0.100:/srv/git1/My-Module.git (push)

 

Bill commits new code.

Bill pulls down the latest code from branch depot/next before his topic branch is created. Note that a pull is a fetch from depot/next followed by a merge in Bills local next branch.

$ git pull

He decides to modify the build file Build.PL. His plan is to replace the artistic2 license with Perls. Create a topic branch for this:

$ git nbr build-license

Open the file Build.PL with an editor:

$ nano Build.PL
< change the license from ‘artistic2’ to ‘perl’ and save file >

Add and commit changes:

$ git add –all
$ git sta
$ git com -m ‘use perl license’

Switch (sw) to (2) branch next and merge in his new code:

$ git sw2 next
$ git mer build-license

Update the Changes file but leave out the version number since this have to wait for some future point in time when to release. Edit Changes file:

$ nano Changes
< edit the Changes file with new version text and save file >

Run the unit test suit again after all edits then commit the new code.

$ git add –all
$ git sta
$ git com -m ‘added license change’

Finally, update the remote branch depot/next:

$ git push

After this Bill can continue to create new topic branches.

In the case depot/next development have progressed by other team members, Bills push fails with:

$ git push

To git1@192.168.0.100:/srv/git1/My-Module.git
! [rejected] next -> next (non-fast-forward)
error: failed to push some refs to ‘git1@192.168.0.100:/srv/git1/My-Module.git’

This means that Bill must pull from branch depot/next and resolve any conflicts by editing the file and committing again. After this he can push his changes:

$ git pull
< edit conflicting file and commit it again >
$ git push

Hot bug fix in released code.

Alice noticed that the README file for public version 0.0.2 release still refers to version 0.0.1. She decides to create a hot bug fix for this.

Note that the stability in branch next may not be such that it can be merged into master to correct the bug in the already released code.

Alice updates branch next before she creates a new hot bug fix topic branch from a suitable point in the commit history.

Switch (sw) to (2) branch next:

$ git sw2 next
$ git pull

After the pull, history looks like:

$ git vhi

* a57f287 – (HEAD, depot/next, next)added perl license(26 minutes ago) <bill>
* 8d51eac -Merge branch ‘build-license’ into next(56 minutes ago) <bill>
|\
| * 40f6a65 -use perl license(67 minutes ago) <bill>
|/
* b437a9c – (v0.0.2, origin/master, master)version 0.0.2(2 hours ago) <alice>
* 5164966 -Merge branch ‘milkshake’ into next(2 hours ago) <alice>
|\
| * 2eed2f7 -Added ice cream(3 hours ago) <alice>
| * 45cdbf2 -Added banana(3 hours ago) <alice>
| * d96a45c -Added milk(3 hours ago) <alice>
|/
* 384b71b -Initial commit(3 hours ago) <alice>

Create a new (n) branch (br) named bugfix1. Branch from commit b437a9c or use git tag v0.0.2 for this new branch:

$ git nbr bugfix1 v0.0.2

This branch bugfix1 points at the last public release:

$ git vhi

* b437a9c – (HEAD, v0.0.2, origin/master, master, bugfix1)version 0.0.2(2 hours ago) <alice>
* 5164966 -Merge branch ‘milkshake’ into next(3 hours ago) <alice>
|\
| * 2eed2f7 -Added ice cream(3 hours ago) <alice>
| * 45cdbf2 -Added banana(3 hours ago) <alice>
| * d96a45c -Added milk(3 hours ago) <alice>
|/
* 384b71b -Initial commit(3 hours ago) <alice>

Fix the bug in the README file:

$ nano README
< change version to ‘0.0.3’ and save file >

Update the Changes file:

$ nano Changes
< add change text describing version 0.0.3 and save file >

Finally add and commit:

$ git add –all
$ git sta
$ git com -m ‘Bug#1: wrong version in README’

While working in branch next, tag the new public release before merging with branch master:

$ git tag -a v0.0.3 -m ‘version 0.0.3’

Switch (sw) to (2) branch master :

$ git sw2 master

View (v) all branches (br):

$ git vbr

bugfix1
* master
next
remotes/depot/next
remotes/origin/master

Merge changes into master with option fast-forward (always):

$ git mef bugfix1

Updating b437a9c..a407b79
Fast-forward
Changes | 3 +++
README | 2 +-
2 files changed, 4 insertions(+), 1 deletion(-)

Finally, push this bug fix to the public Github repository:

$ git push

 

Merge back the bug fix into the integration branch.

Switch branch to next:

$ git sw2 next

View (v) all branches (br):

$ git vbr

bugfix1
master
* next
remotes/depot/next
remotes/origin/master

Merge the bug fix into next (always recursive, when not in master):

$ git mer bugfix1

Auto-merging Changes
CONFLICT (content): Merge conflict in Changes
Automatic merge failed; fix conflicts and then commit the result.

Git puts help marks in the Changes file to show conflicting text lines. Edit the file with:

$ nano Changes

Original file:

Revision history for My-Module
<<<<<<< HEAD
[% nextrev %]
       Use perl license.
=======
0.0.3  Tue Dec 25 16:30 2012
       Bugfix: Wrong version in README.
>>>>>>> bugfix1
0.0.2  Tue Dec 25 13:51 2012
       Added milkshake.
0.0.1  Tue Dec 25 12:40 2012
       Initial release.

Correct Changes as below and save file:

Revision history for My-Module
[% nextrev %]
       Use perl license.
0.0.3  Tue Dec 25 16:30 2012
       Bugfix: Wrong version in README.
0.0.2  Tue Dec 25 13:51 2012
       Added milkshake.
0.0.1  Tue Dec 25 12:40 2012
       Initial release.

Add and commit:

$ git add –all
$ git sta
$ git com -m ‘Corrected Changes file’

View (v) current history (hi):

$ git vhi

* d722edf – (HEAD, next)Corrected Changes file(2 minutes ago) <alice>
|\
| * a407b79 – (v0.0.3, origin/master, master, bugfix1)Bugfix#1: wrong version in README(79 minutes ago) <alice>
* | a57f287 – (depot/next)added perl license(2 hours ago) <bill>
* | 8d51eac -Merge branch ‘build-license’ into next(3 hours ago) <bill>
|\ \
| |/
|/|
| * 40f6a65 -use perl license(3 hours ago) <bill>
|/
* b437a9c – (v0.0.2)version 0.0.2(4 hours ago) <alice>
* 5164966 -Merge branch ‘milkshake’ into next(4 hours ago) <alice>
|\
| * 2eed2f7 -Added ice cream(5 hours ago) <alice>
| * 45cdbf2 -Added banana(5 hours ago) <alice>
| * d96a45c -Added milk(5 hours ago) <alice>
|/
* 384b71b -Initial commit(5 hours ago) <alice>

Push next to update depot/next:

$ git push

Counting objects: 12, done.
Compressing objects: 100% (7/7), done.
Writing objects: 100% (7/7), 716 bytes, done.
Total 7 (delta 5), reused 0 (delta 0)
To git1@192.168.0.100:/srv/git1/My-Module.git
a57f287..d722edf next -> next

View (v) the updated history (hi):

$ git vhi

* d722edf – (HEAD, depot/next, next)Corrected Changes file(55 minutes ago) <alice>
|\
| * a407b79 – (v0.0.3, origin/master, master, bugfix1)Bugfix#1: wrong version in README(2 hours ago)
* | a57f287 -added perl license(3 hours ago) <bill>
* | 8d51eac -Merge branch ‘build-license’ into next(4 hours ago) <bill>
|\ \
| |/
|/|
| * 40f6a65 -use perl license(4 hours ago) <bill>
|/
* b437a9c – (v0.0.2)version 0.0.2(5 hours ago) <alice>
* 5164966 -Merge branch ‘milkshake’ into next(5 hours ago) <alice>
|\
| * 2eed2f7 -Added ice cream(6 hours ago) <alice>
| * 45cdbf2 -Added banana(6 hours ago) <alice>
| * d96a45c -Added milk(6 hours ago) <alice>
|/
* 384b71b -Initial commit(6 hours ago) <alice>

This completes the bug fix. Dispose the bugfix1 branch:

$ git branch -d bugfix1

Deleted branch bugfix1 (was a407b79).

 

Troubleshooting

Error message when Github repository have not yet been created:

$ git remote add origin https://github.com/alice/My-Module.git
$ git push -u origin master

Username for ‘https://github.com’: alice
Password for ‘https://alice@github.com’: ********
fatal: https://github.com/alice/My-Module.git/info/refs not found:
did you run git update-server-info on the server?

Error message when pushing to local git depot server with wrong url:

$ git remote add depot git1@192.168.0.100:/srv/git1/My-Modules.git
$ git nbr next
$ git push -u depot next

git1@192.168.0.100’s password: *******
fatal: ‘/srv/git1/My-Modules.git’ does not appear to be a git repository
fatal: The remote end hung up unexpectedly

What is the url error in this case?

Error message if permissions is not correct for the depot directories:

$ git remote add depot git1@192.168.0.100:/srv/git1/My-Module.git
$ git nbr next
$ git push -u depot next

git1@192.168.0.100’s password: *******
fatal: ‘/srv/git1/My-Module.git’ does not appear to be a git repository
fatal: The remote end hung up unexpectedly

Ensure that git1 user ownerships are correct on the server:

# chown root:git1 /srv/git1
# chown -R git1:git1 /srv/git1/My-Module.git

 

References

[1] Git: http://git-scm.com

[2] Github: https://github.com

[3] Gitorius: https://gitorious.org

[4] nvie: http://nvie.com/posts/a-successful-git-branching-model

[5] Fine-grained access control: https://github.com/sitaramc/gitolite.git

[6] CPAN: http://www.cpan.org

 

Notes

Note1) Include current branch at your prompt with this text in your ~/.bashrc:

function parse_git_branch () {
    git branch 2> /dev/null | sed -e '/^[^*]/d' -e 's/* \(.*\)/ (\1)/'
}
YELLOW="\[\033[0;33m\]"
GREEN="\[\033[0;32m\]"
NO_COLOUR="\[\033[0m\]"
PS1="$YELLOW\u@\h$NO_COLOUR:\w$GREEN\$(parse_git_branch)$NO_COLOUR\$ "

Source: Github Gist Code snippets

Note2) Show commit history as in this howto with an alias in the ~/.gitconfig file:

[alias]
vhi = log --graph --pretty=format:'%Cred%h%Creset -%C(Yellow)%d%Creset%s%Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit --date=relative

For information about this git command see man git-log.

Comments

comments