Using Git and Bitbucket as Distributed Version Control System

Initially published on July 15th, 2015 but updated on August 4th, 2015.

Git was introduced by Linus Torvalds in 2005 after many developers of the Linux kernel gave up to access to BitKeeper. Git is a fast and reliable Distributed Version Control System able to handle very large projects. Git is free, open-source, portable and easy-to-learn.

Personally, I adopted Git when I was trying to setup my first homelabs in 2010. I was looking for a free repo on Internet when I found Bitbucket. At that time, I wanted to be able to work on the same code from multiple workstations while keeping some privacy. I was then forced to pass from some more familiar SCM tools like Perforce or SourceSafe to Git. I have no regret.

The architecture of my development landscape is quite common to see. It consists in managing three branches per application release:

  • Unstable: directly updated by developers in a continuous integration perspective,
  • Testing: automatically updated based on nightly builds to successfully pass the multiple test and acceptance stages,
  • Stable: once the release has been verified and is ready to be deployed in production.

Scenario

Developers clone the unstable reference repository from the Git Server to their Workstation. They manage to commit their code to their respective branch as per their convenience. Once developer tests are successful, they can merge their branch with the unstable reference one in order to participate to the next nightly build. During the night, automatic unittests and assembly tests are executed on the integration server. Then according to the nightly build status, a new version replace the existing unstable one before being merged with the testing branch.

The testing branch is regularly pushed to quality where multiple series of tests are executed:

  • Regression testing,
  • Functional testing,
  • Acceptance testing and,
  • Performance testing.

Finally, once the complete set of tests has been successfully executed, the testing branch is merged with the stable one. All branches are daily synchronized with Bitbucket to back up the server.

Homelabs: Git Landscape

How to install Git?

On bitbucket:

  1. Create a new Repository [MY_BITBUCKET_REPOSITORY],
  2. Create 3 branches for the first release (e.g., S1, T1 and U1) and,
  3. Assign S1 as main branch.

On Debian Git Server:

  1. Please make sure defining both Git group and Git user then create a git repository (e.g., /mnt/gitHome/):

    ~: cd /mnt
    /mnt: sudo apt-get install git
    /mnt: sudo mkdir gitHome
    /mnt: sudo chown [MY_GIT_USER] gitHome
    
  2. Generate an ssh key which will be directly imported into Bitbucket:
    /mnt: cd ~/
    ~: ssh-keygen
    ~: cat ~/.ssh/id_rsa.pub
    
  3. Then configure Git:
    ~: cd /mnt/gitHome
    /mnt/gitHome: git config --global user.name "[MY_GIT_USER_NAME]"
    /mnt/gitHome: git config --global user.email "[MY_GIT_USER_EMAIL]"
    /mnt/gitHome: git git@bitbucket.org:[MY_GIT_USER_NAME]/[MY_BITBUCKET_REPOSITORY].git
    /mnt/gitHome: git fetch && git checkout S1
    /mnt/gitHome: git fetch && git checkout T1
    /mnt/gitHome: git fetch && git checkout U1
    /mnt/gitHome: git checkout -b [BRANCH_NAME] #For each developer
    

On each Windows developer workstation:

  1. Download and install Git
  2. Download and install Tortoise Git and its language pack
  3. Create a local Git Repository, right click on it and run Git Clone (thanks to TortoiseGit) to retrieve the reference branch U1,
  4. Finally create a branch in relation with the developer ID (e.g., 1D1). Have Fun!

Further readings?


About the author

Freelancer, IT Architect and Program Manager, Ludovic Fernandez is specialized in designing and realizing innovative and reliable enterprise applications.

Feel free to refer to this page on