Version Control

Subscribe to this topic:

• Entry #1: Serving a Private Git Repo With Sharing

  Fri, 29 Jun 2012:

  This is pretty much a sumary of what was already said at ...

  http://git-scm.com/book/en/Git-on-the-Server-Setting-Up-the-Server

  ... plus a few customizations and a suggested method of how to init a bare git repo for a user that is restricted by git-shell.

  Step 1)

  Install Git server:

  sudo apt-get install git-server
  

  after installing git-server create a user account which will own the shared repo. Usually just using 'git' is ok, but if you are serving to different organizations, then you would liek to give them their own username so that they cannot access all the other projects ( I would prefix their username with git so that I can recognize why that user is on my system... something like gitjsdesign). If you're on a shared server or cloud, you can protect the data by encrypting their home folder... using (in Ubuntu at least)..

  adduser --encrypt-home gitjsdesign

  without encryption, you can use:

  adduser gitjsdesign

  step 2)

  ask gitjsdesign to use ssh and create a public key which they can send(email) you. Add their public key to the authorized_keys file at /home/gitjsdesign/.ssh/authorized_keys. add your own public key in there too.

  step3)

  protect your shell by restricting their access.

  find our where the git-shell is:

  which git-shell

  lets say we got /usr/bin/git-shell

  now we edit the /etc/passwd file

  sudo vi /etc/passwd

  then change

  gitsjdesign:x:1000:1000:,,,:/home/gitsjdesign:/bin/sh

  to

  gitsjdesign:x:1000:1000:,,,:/home/gitsjdesign:/usr/bin/git-shell

  step 4)

  create the project repo.

  using your regular user account, go to the home directory of the git user,

  cd /home/gitjsdesign/

  initialize a bare repo... ** run sudo as gitjsdeign so that they own it.

  sudo -u gitjsdesign git init ourProject.git --bare

  Now, the user can go to their project root and run

  git init git add . git commit -m 'initial commit' git remote add origin gitjsdesign@gitserver:ourProject.git git push origin master

  
  

• Entry #2: Snippets From A Great Git Branching Model

  Fri, 29 Jun 2012:

  A great git branching model was proposed on nvie.com and can be found here:

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

  I highly recommend anyone to first go and read it since it is very elegantly explained, along with pleasant diagrams. Here, I'm just going to highlight a few of the code snippets for my own reference.

  A] Main Branches

  - There are 2 main branches... develop and master.
  - Master is assumed to be production ready, develop is branched from master and merged back to master when it is stable enough.
  - Master is tagged with a version each time it is updated.

  Using my private repo that I set up in my last entry, I'll switch to the master branch(probably already starts there but I'll be explicit), then tag my first version of master

  git checkout origin master
  git tag -a '0.01' -m 'first version 0.01'
  

  next, I would create and checkout a dev branch

  git checkout -b develop master

  which is just short for

  git branch develop master
  git checkout develop

  so, if you don't need to checkout develop, you can jsut create it with 'git branch develop master'

  push your local development branch to remote:

  git push origin develop
  

  B] New Features

  -create and checkout a feature branch off of the develop branch

  git checkout -b newFeature develop

  -do work on the feature branch.. then update the feature branch

  git add . 
  git commit -m 'added blah to my feature'
  

  - merge my feature branch with develop using no fast-forward, then delete the newFeature branch

  git checkout develop
  git merge --no-ff newFeature

  -delete teh feature branch

  git branch -d newFeature

  -push back to develop

  git push origin develop

  C] Release Branch -> Production.

  git checkout -b release-0.02 develop

  - test the release branch. creating a new release branch is good practice so that the develop branch can still be worked on while testing is going on release. I'd imagine that on a smaller project one can just merge the develop branch into master
  - merge release into production (master)

  git checkout master
  git merge --no-ff release-0.02
  git tag -a 'version 0.02'
  

  - merge back into develop

  git checkout develop
  git merge --no-ff master

  -delete release branch

  git branch -d release-0.02

  D] Hotfixes

  Just create a branch off of develop, release, or master, and merge it back after fixing the bug.

  E] Some Other Usefull Git Commands

  - view remote names with locations using

  git remote -v

  - view all local and remote branches with

  git branch -a

  - view remote branches with

  git branch -r

  + add 'v' for some more info.. ie:

  git branch -rv
  

  - add remote branches:

  git push <remote-name> <branch-name>

  - delete remote branches:

  git branch -d -r remote_name/branch_name

  - reset your current project to match the repo (on origin master):

  git reset --hard origin/master