by admin

A successful GIT branching model

July 12, 2013 in Git, SCM, Tips & Tricks by admin

An interesting model of GIT branches.

For more info follow this link.

by admin

Using Google’s repo tool with in own projects on BitBucket

April 12, 2013 in Code Snippets, Source Code, Tips & Tricks, Tutorial by admin

Using Google’s repo tool with in own projects on BitBucket

There are couple of ways to manage projects which are split in multiple repositories, of which the two most known are probably git submodule, git subtree, each with it’s own list of pros and cons. One such tool is Google’s Repo wich was created to manage the large Android project in a way which would allow easy replacement of modules, easy addition of new modules, access control, and so on. Some of the things which repo allows are checking out multiple projects from a manifest file, updating them, branching, sending changes from multiple different projects as a single changeset.

A more detailed description of the this command and various other information related to using repo with the Android project can be found here.

Let’s consider a project composed of two repositories, test/a and test/b stored on bitbucket. Once created, their URL will be something like:[an user name]/test-a.git[an user name]/test-b.git

where the ‘/’ in the project’s name was replaced with ‘-‘.

In order to be able to use Repo, you’ll need to download it from, copy it to a suitable location and make it executable or from command line:

curl[the last version] > repo
chmod a+x repo

Repo’s information about a project is stored in a manifest file, default.xml by default if no other name is specified. The file structure is rather simple. Bellow is a sample file for a hypotethical project hosted ob BitBucket []:

<?xml version="1.0" encoding="UTF-8"?>
     <remote name="bitbucket" fetch=".."/>
     <default revision="refs/heads/master" remote="bitbucket" sync-j="4"/>
     <project name="test-a" remote="bitbucket" path="a>
     <project name="test-b" remote="bitbucket" path="b"/>

As you can see, first at least one remote needs to be defined, which will be used to fetch the projects. The name should be something meaningful for you, while fetch should contain the URL to the repository from where the projects will be fetched. The reason why we specified “..” will be explained bellow.
Then we need to add a default revision definition for the remotes we defined, and then follow the list of projects. The defaults are useful since in case no revision is defined for a project, the default one will be considered.

In the project definition the path specifies the path where the given project will be cloned and will be automatically created if does not exists. The project name is the path and the name of the project, without the .git part, which will be appended automatically. The full URL of the project’s repository will be {the url provided to remote fetch}/{projec name}.

Once this file is created, we need to store it on bitbucket in a repository, for example test/repo, the repository URL being like:[an user name]/test-repo.git

This being complete, the configuration part is done. Time to clone the project. For this, we need to create a folder, and inside that folder we’ll need to initialize repo by running this command:

repo init -u[an user name]/test-repo.git

This will download the manifest from the specified URL using git and create a .repo folder inside your folder, then will clone the project you specified after the -u flag and try to find and store the manifest file (default one being default.xml).

The reason why we specified the “..” for the fetch is as because in this case the it will be considered relative to the URL we specified at the init moment. Remember that earlier I said the project’s repository will be {the url provided to remote fetch}/{projec name} ? In our case {the url provided to remote fetch} will be[an user name]/test-repo, and in order to be able to specify an another project, we need to go one folder higher, which would mean relative path “..”. When composed together with the project name, we’ll end up with something like[an user name]/test-repo/../test-a.git which is same as[an user name]/test-a.git, the right path for our test/a project.

Once this is complete, we can download the projects by running

repo sync

which will clone all the configured projects. From here you can use the usual git commands to commit & push stuff in various projects or use the repo commands for the repo’s functionality.

Note: while git allows you to clone a bitbucket repository with ssh://git@…., it won’t work with repo. If you specify the repository for the manifest file, the repo won’t be able to find te repos of the configured projects.

More information about Repo’s commands can be found here

Source here.

Git Is The Answer part 1-2-3

March 22, 2013 in Tutorial, Uncategorized by Adrian Marius

Articles via ROSEdu Techblog (from here and here)

We focus again on git. This time, we will present some real-world scenarios where knoweldge of advance git topics helps. In order to keep down the length of the article, our presentation is divided in 3 parts, this being the first one of these.

The second article on advanced git topics is focused on cases where multiple branches are involved.

Finally, the third article on advanced git topics will focus on things that many will use only in some very special cases.

ROSEdu Techblog is licensed via CC-BY.

Skip to toolbar