Documentation: Difference between revisions

From pCT
← Older editNewer edit →
VisualWikitext
Mri083 (talk | contribs)
205 edits
→‎Creating a project fork: moved to GitLab developer AQ
Mri083 (talk | contribs)
205 edits
→‎Pull/Merge request: moved to GitLab developer FAQ
Line 94: Line 94:
Or using the direct link
Or using the direct link
     git push https://user@gitlab.uib.no/user/wpn.git dev
     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 developers fork. All contributions are done to branch ''dev'', thus it must be updated with the latest version of branch ''dev'' of main repository.
# Fetch update from main repository
#: <pre> git fetch https://gitlab.uib.no/pct/wpn.git dev</pre>
#:* the update is now stored in the local index, we have fetched branch ''dev'' of the main repository
#:* check the log of this latest fetch
#: <pre> git log FETCH_HEAD</pre>
#:* FETCH_HEAD is a shorthand for the head of the last branch fetched and is valid only immediately after a fetch operation
# 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.
#: <pre> git rebase FETCH_HEAD dev</pre>
#:* keep in mind that FETCH_HEAD is only temporarily valid, so you should do this immediately after ''fetch'' (''log'' does not change anything)
#:* 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.
#: <pre> git rebase FETCH_HEAD feature-name</pre>
# 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
#: <pre> git push -f origin dev </pre>
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 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". '''Remember''': in almost all cases you have to merge to branch ''dev'' or other feature branch, only in very rare cases to branch ''master''
# 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 ===
=== Importing an external package ===

Revision as of 10:10, 10 February 2021

Main Page -> Documentation

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.

Get access to the repositories - with UiB account

Open the UiB gitlab web interface.

Log in with your UiB account, then the administrators will give you access to the pCT group. Since authentication goes via Dataporten service, accounts from other Norwegian universities or institutions can be used in the same way.

Get access to the repositories - without UiB account

It is possible to use a github user account to login to the UiB gitlab, however such external users are not allowed to create forks in the gitlab domain. Since forks are mandatory for the development cycle, github logins can effectively only be used for read access. Again the repository administrators need to add you to the pCT group.

Guest accounts for external developers can be set up, get in contact with the group over the general channels

Further information:

GitLab best practice

GitLab Developer FAQ

Gitlab Master FAQ

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 (see here) from the repository. This is a repository copy in the Gitlab system where a single developer or a group of developers have full access.

A local copy of the repository is required on the working machine in order to work on the project. This copy is referred to be a clone (see here).

Making local working copy

A project is utilized through a local working copy referred to be a clone. The project can be cloned from either the main repository in the group space or the fork in the user space depending on the role.

In the examples 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://.

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

The originally cloned remote repository will get the identifier origin in your local clone.

From development fork

Clone directly from your development fork 

   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

Multiple upstream repositories

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 (chosen as an example). 

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

Check configured upstream repositories

The configured upstream repositories can be checked with 

   git remote -v

This will display the identifier and link to the configured upstream repositories.

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

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.

  1. Create new repository in the pCT group or ask for creation, lets call it newPackage
  2. Fork the repository to your user space
  3. Clone the package you want to import 
     git clone <some_external_link> newPackage # we give it the new name
     cd newPackage
  4. Redirect upstream URL to the fork in your gitlab user space 
     git remote set-url origin https://user@gitlab.uib.no/user/newPackage.git
  5. Now make a forced push (option -f) to import the repository to your fork 
     git push -f origin
  6. Create merge request to branch import (if not existing, master or any other appropriate branch) by following the instructions Pull/Merge request

User documentation

Retrieved from "https://pct.wiki.uib.no/index.php?title=Documentation&oldid=853"