Anuket Project

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Next »


This guide is still under development Trevor Bramwell

There are two main workflows when contributing code on Gitlab: branching and forking. Which one you use will depend on your need and level of access to a project. In all
cases the fork workflow is preferred.

The first step is to create a Gitlab account. You'll need to have verify your account with a credit card (no charge) before CI jobs can be ran in your personal or project forks.
If you'd prefer not to have to add a credit card, after making an account click "Request Access" on the Anuket group. Once your access is approved, CI for any MRs you make against
Anuket projects should run.

Gitlab Branch Workflow

  1. Clone the project
  2. edit, git add, commit
    Write you change (remember to include `-s` to sign off commits: `git
    commit -s`)
  3. git push
  4. Click the link from the message to open a merge request to the
    upstream repository
  5. If you have multiple commits, write a detailed explanation about what you're asking to be merged in.
    Set the change to "Draft" if its still being worked on.
  6. Wait for CI to pass and a CODEOWNER to review.
    If the project is utilizing hardware for their CI, a developer will need to approve your pipeline to run before it is tested.

Gitlab Fork Workflow

  1. Fork the project
  2. Setup mirroring
    Alternatively manage this yourself by adding an extra 'upstream'
    remote and routinely 'git pull upstream/master','git push origin master'
  3. Clone your fork
  4. Checkout a new branch to make your change
  5. edit, git add, commit
    Write you change (remember to include `-s` to sign off commits: `git
    commit -s`)
  6. git push
  7. Click the link from the message to open a merge request to the
    upstream repository
    Make sure the source branch comes from your fork and the target is the upstream repository
  8. If you have multiple commits, write a detailed explanation about what you're asking to be merged in.
    Set the change to "Draft" if its still being worked on.
  9. Wait for CI to pass and a CODEOWNER to review.
    If the project is utilizing hardware for their CI, a developer will need to approve your pipeline to run before it is tested.


  • No labels