compared with
Version 63 by Emily Hahn
on Aug 18, 2014 14:15.

This line was removed.
This word was removed. This word was added.
This line was added.

Changes (5)

View Page History
For example ctdpf_ckl_wfp_stc will become CtdpfCklWfpStcDataSetDriver

h2. Useful GIT Commands
h2. GIT Commands and Branching

In order to check how your remotes are set up you can run:
See the [GIT Help Page|]

'git remote \-v'

You should have an origin pointing to your fork on github, and an upstream which points to ooici on github, and should produce something like the following: 

origin &nbsp;<your git name>/marine-integrations.git (fetch)

origin &nbsp;<your git name>/marine-integrations.git (push)

upstream &nbsp; &nbsp; &nbsp; &nbsp;git:// (fetch)

upstream &nbsp; &nbsp; &nbsp; &nbsp;git:// (push)

In order to pull changes that have been made to the main repository into your working area, you can run the following which will stage the changes:

'git fetch upstream'

At this point the upstream changes are staged, but not committed (you can see them with 'git status'). &nbsp;Then to merge the staged changes into your master branch:

'git merge upstream/master'

If there are any conflicts merging, they will be given here. &nbsp;If there are, you will have to manually resolve them by going into the files with the conflicts and editing them (removing the added comments which mark the conflict areas)

The above two steps should be run frequently to keep your branch up to date, otherwise you may end up with many conflicts when you do run this.&nbsp;

To see the status of your files:

'git status'

To stage your changed files:

'git add <filename>'

Never commit any changes to any extern submodules.

To commit all your changed files:

'git commit'

To push your committed changes from your virtual machine onto your fork of the github repository (unless you do this changes are only on your virtual machine and can't be seen by anyone else):

'git push origin'

To help in resolving merge conflicts, if an entire version should be selected, you can use the shortcut:

git checkout \--theirs <filename>


git checkout \--ours <filename>&nbsp;

to select either our version of the file or the other version of the file. &nbsp;

h2. GIT Branching

Each task a developer is working on (i.e. each driver or bug fix) in git should be worked on in its own branch. &nbsp;By default, the master branch in git is selected, but additional branches can be created. &nbsp;It is best practice to not work on your master branch at all, and create different branches for each task you work on. &nbsp;To create a branch:

git branch <branch name>

To switch to working on a branch:

git checkout <branch name>

If you want to create a branch and switch to that branch all in one command:

git checkout \-b <branch name>

When you create a branch, it will use the currently selected branch as the baseline for that branch, so it is recommended that you make sure your master branch is up to date (with "git fetch upstream" then "git merge upstream/master"), then create the new branch while your master branch is selected.&nbsp;

To see which branch you have selected you can type:

git branch

which will provide a list of branches on your VM, with a star next to the currently selected branch. &nbsp;

"git status" will also display the currently selected branch on the first line. &nbsp;

To push a particular branch to github:

git push origin <branch name>

A pull request can be done directly from that branch, and after the code is pulled from there the code in that branch will be present in ooici. &nbsp;If the branch is no longer needed, it can be deleted. &nbsp;To delete just a local branch:

git branch \-d <branch name>&nbsp;

To delete the remote branch on github:

git push origin \--delete <branch name>

You can also merge branches with each other. &nbsp;To merge a branch into your master:

git checkout master

git merge <branch name>

h2. Submodule Updates