Commit c503174d authored by Scott Matthew Collis's avatar Scott Matthew Collis
Browse files

Merge branch 'scollis_ins' into 'master'

Instructions for the Collis radar group

See merge request !1
parents 89816bef c822ae54
How to interact with group level repositories
Coming soon
Instructions on how to work on a repository in your own user space
These instructions pertain to working on a repository you have created in your
own user account.. For example collis/a-cool-repo. NOT for working with a
repository in a group area, for example this repository which is in share.
Getting started
First you need to create a new repository. Go to
Pick a descriptive *but not too long* project name. No spaces, no special
characters, you have to be happy to type this many times. Keep permissions to
internal, not private or public.
You also need to have your SSH keys set up so you can transfer to your local
machine using SSH protocol (no https!). Setting this up is under your settings.
Click on your avatar (which defaults to a pattern-ish thing) upper right hand
corner. Click "settings". The task bar just under the "Fox" GitLab logo will
then have a "SSH Keys" option.
There is an instruction on generating a key on the page. If you have already
generated a key copy paste from ~/.ssh/ **note: On some systems you
may want to open in an editor and copy paste instead of doing "more"
in the terminal as this can add carriage returns**.
Now you are ready to clone your repo for the initial commit. Go back to the repo
page ( and just under the title there is
a text box with "SSH" next to it and a link.
Copy that and go to your local shell, go to where you want your repo to reside and
type "git clone" and paste in the location. You will get some warnings that your repo is empty..
Change directory into the repo directory. **Warning: GitLab, unlike GitHub does
not create master for you**. You need to create the master branch. Type:
.. code-block:: shell
git checkout -b master
touch README.rst
-Edit README.rst with your favourite editor-
.. code-block:: shell
git add README.rst
git commit -m"INIT: Initial commit creating master"
git push origin master
*This will be the first and only time you work directly on master.* In the
Argonne group we use branches.
Doing work with branches on
Branches are great. They enforce discipline, avoid conflicts and keep master
clean. here are the steps to "adding a feature":
One: create the branch from master
Make sure you are on master
.. code-block:: shell
git checkout master
If you are unsure you can check!
.. code-block:: shell
git status
Two: Do brilliant work
So, say, we want to create a feature that allows us to create a beam blockage
map from a shell command, we will create a branch for the initial work:
.. code-block:: shell
git checkout -b bb_from_cline_init
Now you are good to do work. *Hint: Git push makes a geat backup system*. As you
are doing work and you come to the end of a "natural task" you should commit
your changes and, before you log off, catch a flight or go home (or anything
where your system may become compromised and data loss may occur) you should
push your repo to a remote. To Commit the change:
.. code-block:: shell
git add path_to/file.ext
git commit
In the Argonne group, unless the work is very incremental we discourage command
line commit messages. Make sure your editor is set in git (Google: Setting my
editor in git) and add a nice descriptive commit message so we can see what you
have done. For example:
.. code-block::
ADD: Added gatefilter to time series plot
Added the ability for graph.radardisplay.plot_vpt to accept a gatefilter to
conditionally plot data.
Once you exit the editor the change is committed.. Keep working or push the
result to origin
Three: Push the result to origin
The changes exist on your branch on your repo but are not reflected in origin
and at the moment any changes you have made are not safe yet. But pushing the
changes to a remote is easy.. in our case the remote is origin so simply
.. code-block:: shell
git push origin BRANCHNAME
or in our example
.. code-block:: shell
git push origin bb_from_cline_init
Will push changes.. Note: You can keep doing this to your heart's content and
changes remain in the branch in origin and do not impact the master branch or
any other branches. But beware.. When you have something you are happy with you
should *merge* you work back to the master branch and start a new branch for new
Four: merge request
Go to your repo after your latest push to origin (making sure you remembered to
add and to commit the changes). GitLab should see that there has been a change
made to a branch and there should be a button on the right hand side of the
screen "Create Merge Request". Click it.
You then get a nice descriptive screen that tells you all you have done. Make
sure the "From" is your branch and the "into" is master. **Note:
GitLab does not let you merge if the last commit starts with WIP so make sure your
latest commit does not start with WIP**. Edit some text in the description
(note: you will not be doing yourself a favor leaving this blank) and click
"Submit merge Request"
This will take you to a page where there is a button "Accept merge request". If
you were reviewing a request from some one else you would carefully review the
code, test it etc.. However since you are working on a personal project for now
you can just accept it once you are happy. Now master is update with your
changes and users of your code can use your added feature.
Five: Syncing your master to origin
Your changes are now up on origin but your local master branch is behi
.. code-block:: shell
git fetch origin master
git merge --ff-only origin/master
You are now good to go back to step one!
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment