For each feature being implemented, convention is that a new branch must be forked; only to be merged back into the development branch once testing has been completed.

Development branch is to be merged into the release branch upon completion of integration testing.

It is important that the branching protocol is observed, as it will keep people's test environments consistent to where they are individually in their implementations.

reemlab & reemlab2 now have SSH deploy keys tied to the github account, there is only read access from github for these machines. The workspace can be located in "~/REEM\ workspace" on the VxLab machine, and automated build scripting is a thing tailored for these devices. To access reemlab & reemlab2, refer to ssh_config_details.txt

###Basic process is after doing your changes in your client: NOTE: Make sure that prior to making the changes, that you are checked out on the relevant branch, use git checkout <branchname> to swap between branches

####Add any autogenerated build files to a .gitignore, which is specifically required for any directory in the repository. You may need to create the .gitignore, semantics are:

Filename to ignore specific files

Folder/ to ignore folders and everything contained

The .gitignore will prevent pushing extraneous files onto the server. General rule is that if you didn't modify the code manually: it goes in the .gitignore. You can use git status to determine what is currently untracked by git.

If you had to modify a file manually to get things operational after an automated build procedure, only then remove it from the .gitignore

####Get git to add the files you have modified

git add . Will add everything not specified in the gitignore

git add <file1> <file2> <etc> Adds files individually

This tells git to take notice of the alterations in the files you have been working on. Note: .gitignore also needs to be added in this procedure

####Make sure that you are syncronised with the head of the remote

git pull origin <branch_name>

If you have merge-conflicts, take note of the file names throwing the error, then open them in a text editor; you will notice some weird shit with hashes, "======" and words like HEAD, manually delete that crap and make it look functional then save and exit. This will resolve the merge conflict, congrats.

####Commit the changes

git commit -m "A meaningful commit message"

This creates a commit on your local machine with the files you have specified to add. You may then continue working locally if you please, as this creates a neat history that can be rolled back if it's a partial working implementation.

####Push the changes to the remote repository

git push origin <branchname>

Puts the changes on github so other teammembers can pull.

####Create some sort of build documentation

A quick and dirty readme in each package you make explaining the build procedure can go a long way in helping others get your code working on their machines. Please try to include this, as everyone will be building from source.

(Good job for reading this far)