Documentation: Difference between revisions

Revision as of 21:41, 12 January 2017

Mailing lists and collaborative tools

Project web page: has to come
General mailing list: pCT@uib.no
Slack project

Software installation

Software repository

We use the gitlab server hosted by IT of University of Bergen. We start with a repository per work package (wp). As there is overlap in terms of software, this structure might change in the future. Log in with your UiB account, then the administrators will give you access to the pCT group. If you don't have an account yet, get in contact with the group over the general channels. There might be an admin mailing list later.

UiB gitlab web interface.

Further information:

Gitlab best practice

Development workflow

Every logged-in user can access the main repository, however only a small group of administrators has write access. To contribute, a user creates a fork from the repository. This is a copy where a single developer or a group of developers have full access.

The main repository has the following branches:

production: the latest production code, in this branch we have release tags
master: the latest stable release
dev: the development branch

In addition to those main branches there can be feature branches where development happens detached from the main branches. A feature branch is based on the dev branch and has a limited lifetime.

Creating a project fork

A project fork or repository fork is a copy of the original repository where a user or a group of users has/have full control. All development in our project is carried out in the individual forks. Branches of project forks are merged back into the main repository by merge requests, preferably via fast forward merges. That requires developers to rebase project forks to the main repository and resolve all conflicts before requesting a merge.

How to fork a project

Your repository fork is your sandbox, you can do whatever you want. Unless you have your own rules at hand right now you can apply the following:

leave the master branch in sync with the main repository, do not make commits to it
commit your changes to the dev branch
if you start a new feature, and it's expected to take a while, make a feature branch, e.g. dev-feature and give the feature a name
synchronize regularly to the main repository by rebasing (tutorial coming soon)

Making local development copy

From development fork

Clone directly from your development fork, replace user and wpn (e.g. wp7) appropriately. Note: the gitlab offers two modes for the link to be cloned, you can choose ssh (default setting) or https. If you can not clone with the proposed default link, try option https://.

 git clone https://user@gitlab.uib.no/user/wpn.git

This will create a local directory wpn, an optional argument after the link allows to change the directory name, e.g.

   git clone https://user@gitlab.uib.no/user/wpn.git mywork

The remote repository will get the identifier origin in your local clone, check with

   git remote -v

From the main repository

The main repository is cloned like

   git clone https://gitlab.uib.no/pct/wpn.git

The upstream link can be changed later to any other repository like e.g. a development fork as follows (given the clone directory is the current working directory)

   git remote set-url origin https://user@gitlab.uib.no/user/wpn.git

As a more advanced option, multiple remote repositories can be added to the clone. All remote repositories are referenced through their identifiers, e.g. origin pointing to the fork and pctgroup pointing to main repository.

   git remote add pctgroup https://gitlab.uib.no/pct/wpn.git

Pushing to development fork

Once you have added commits to e.g. the dev branch, those commits can be pushed upstream to the fork (if origin refers to the fork)

   git push origin dev

Or using the direct link

   git push https://user@gitlab.uib.no/user/wpn.git dev

Pull/Merge request

All updates to the main repository are made via merge requests (github refers to them as pull requests). A merge request requires the code update to be in a mergable branch in a development fork.

Merge request are also used widely to share work-in-progress with your colleagues and for code reviews. Mark such Merge request with "WIP:".

Preparation

In order to avoid conflicts, first the fork has to be updated to the main repository. The idea behind this is that all potential conflicts can be resolved by the developer with the best knowledge about the matter, while the maintainer can simple merge fast-forward.

This description expects origin pointing to the fork and pctgroup pointing to main repository (see here).

Synchronize with main repository
```
 git remote update
```
Rebase your development to the main repository, rebase means that all the new commits are done with respect to the tip of the specified branch. There can be merge conflicts which need to be resolved with appropriate changes and commits.
```
 git rebase remotes/pctgroup/dev dev
```
- replace pctgroup with appropriate remote repository identifier
- replace dev with appropriate branch name if other then dev is used; it is also possible to rebase a branch with other name to the remote branch, e.g.
```
 git rebase remotes/pctgroup/dev feature-name
```
Check your commits and commit messages, eventually squash (combine) or reword. This advanced option is described later.
Push to fork. As the commit history has most likely been changed, the option -f (force) has to be used
```
 git push -f origin dev 
```

The branch dev in the fork is now ready for a merge request. The branch name can be adjusted, there is nothing preventing other branch names.

Example workflow for a Merge request

Go to your gitlab user space at https://gitlab.uib.no/user (replace user appropriately.
Find the project fork, e.g. in the list of projects associated with you from the upper main menu.
In the line with the many columns regarding the repository, click on the "+"-symbol on the right hand side and choose "New merge request"
Select project and branch for both source and target, and click "Compare branches and continue"
Review the list of commits in this merge request, give it a descriptive title and description, pick an assignee
Submit the merge request

Importing an external package

The project will use a couple of external packages which are hosted in a different master repository. Copies of such external packages can be added to the gitlab server under our project group to provide a consistent package.

Here is a proposed workflow for importing a package which is already hosted in git.

Create new repository in the pCT group or ask for creation, lets call it newPackage
Fork the repository to your user space

Clone the package you want to import

 git clone <some_external_link> newPackage # we give it the new name

 cd newPackage

Redirect upstream URL to the fork in your gitlab user space

 git remote set-url origin https://user@gitlab.uib.no/user/newPackage.git

Now make a forced push (option -f) to import the repository to your fork
```
 git push -f origin
```
Create merge request to branch import (if not existing, master or any other appropriate branch) by following the instructions Pull/Merge request

@@ Line 47: / Line 47: @@
 ==== From development fork ====
 Clone directly from your development fork, replace ''user'' and ''wpn'' (e.g. wp7) appropriately. '''Note''': the gitlab offers two modes for the link to be cloned, you can choose ''ssh'' (default setting) or ''https''. If you can not clone with the proposed default link, try option ''https://''.
-    git clone https://user@gitlab.uib.no/user/wpn.git
+<pre> git clone https://user@gitlab.uib.no/user/wpn.git</pre>
 This will create a local directory ''wpn'', an optional argument after the link allows to change the directory name, e.g.