Difference between revisions of "Git / Gitlab"

From LinuxMCE
Jump to: navigation, search
Line 15: Line 15:
 
As soon as your account was created you'll receive an E-Mail containing a link to set your password.
 
As soon as your account was created you'll receive an E-Mail containing a link to set your password.
 
Klick on that link and set your password, then you are ready to login.
 
Klick on that link and set your password, then you are ready to login.
 +
 +
== Workflow ==
 +
 +
We have no fine grained workflow at the moment and no continous integration.
 +
 +
=== With no write access ===
 +
 +
Even if you have write access you can use this method.
 +
 +
# Fork a repository
 +
# Do your stuff, implement features, fix bugs etc.
 +
# Make "Pull Request" fo your changes
 +
# "Pull Request" will be verified and merged by a LinuxMCE Dev, please be patient
 +
 +
=== With write access ===
 +
 +
Master is always deployable, so we must not work on Master at any time!
 +
 +
# Clone a repository
 +
# Branch of from Master
 +
# Do your stuff, implement features, fix bugs etc.
 +
# Commit/Push your branch - on bigger changes i would recommend doing a test build using this branch
 +
# Merge your changes into Master
 +
# Push the verified changes to master
  
 
== Useful links ==
 
== Useful links ==

Revision as of 07:32, 6 January 2016

GitLab / GIT

GitLab is the web interface of choice for managing GIT repositories.

A list of features: https://about.gitlab.com/features/

Get access to GitLab

Go to IRC #linuxmce-devel and ask for a Account.

To create an account we need following information:

  1. Name
  2. Username
  3. E-Mail

As soon as your account was created you'll receive an E-Mail containing a link to set your password. Klick on that link and set your password, then you are ready to login.

Workflow

We have no fine grained workflow at the moment and no continous integration.

With no write access

Even if you have write access you can use this method.

  1. Fork a repository
  2. Do your stuff, implement features, fix bugs etc.
  3. Make "Pull Request" fo your changes
  4. "Pull Request" will be verified and merged by a LinuxMCE Dev, please be patient

With write access

Master is always deployable, so we must not work on Master at any time!

  1. Clone a repository
  2. Branch of from Master
  3. Do your stuff, implement features, fix bugs etc.
  4. Commit/Push your branch - on bigger changes i would recommend doing a test build using this branch
  5. Merge your changes into Master
  6. Push the verified changes to master

Useful links