|
|
# Project Structure
|
|
|
In order to compartmentalize changes to the codebase, the NoMAD project uses a feature branch workflow in git. This isolates and documents change, makes merging easy, and documents the code changes as they happen.
|
|
|
NoMAD uses a simple two branch structure. Combined with a feature branch workflow changes are encapsulated and easy to merge. At the same time all code changes are documented by the workflow.
|
|
|
|
|
|
The project contains two main branches:
|
|
|
|
|
|
* Master
|
|
|
* The current release code
|
|
|
The basic branches are:
|
|
|
* Master
|
|
|
* This is the branch that only ever holds finished release code
|
|
|
* Experimental
|
|
|
* The development branch. (This code should **always** build clean!)
|
|
|
* The development branch. (This branch should **always** build clean!)
|
|
|
|
|
|
# Making Changes
|
|
|
The feature branch workflow is very easy to use:
|
|
|
# Feature Branch Workflow
|
|
|
Using feature branches in git is very easy.
|
|
|
|
|
|
1. Open a ticket that describes the changes to be made to the code.
|
|
|
![Screen_Shot_2016-10-31_at_2.27.13_PM](/uploads/b54a14b59800ddc7cf3ee07ade79cd34/Screen_Shot_2016-10-31_at_2.27.13_PM.png)
|
|
|
|
|
|
2. Pull the Experimental branch to ensure you are up to date with the latest.
|
|
|
3. Create a new branch from Experimental. Use the naming format Username-Issue-Description.
|
|
|
2. Pull to update your local copy of Experimental, then make a new branch with the naming syntax of Username-Issue-Description.
|
|
|
![Screen_Shot_2016-10-31_at_2.28.15_PM](/uploads/fdb7b992e2c7f051005fe4e3dd48b22c/Screen_Shot_2016-10-31_at_2.28.15_PM.png)
|
|
|
4. Make your changes, committing and pushing like normal.
|
|
|
3. Edit code in the feature branch, committing and pushing like normal.
|
|
|
![Screen_Shot_2016-10-31_at_2.30.54_PM](/uploads/b54d55f05c81586c7fb6308560fd0cc9/Screen_Shot_2016-10-31_at_2.30.54_PM.png)
|
|
|
5. When the feature is complete, submit a merge request that references the ticket. (Gitlab makes this easy with issue auto-complete.)
|
|
|
4. When you are satisfied with your changes, submit a merge request that references the issue ticket. (Gitlab makes this easy to do with issue number auto-complete.)
|
|
|
|
|
|
*Opening a merge request*
|
|
|
![Screen_Shot_2016-10-31_at_2.32.45_PM](/uploads/de24cf6df3908167935feb3cdaa16017/Screen_Shot_2016-10-31_at_2.32.45_PM.png)
|
|
|
|
|
|
*Filling in merge request info*
|
|
|
![Screen_Shot_2016-10-31_at_2.54.44_PM](/uploads/bef9531b77abf049beba51ddce2378e4/Screen_Shot_2016-10-31_at_2.54.44_PM.png)
|
|
|
|
|
|
Once the code is reviewed it can be merged back into the branch that the feature branch was based on.
|
|
|
|
|
|
6. Close the ticket and indicate which git commit the changes landed in. |
|
|
\ No newline at end of file |
|
|
5. Once the request is accepted, update the ticket with the git commit that the changes landed in if Gitlab didn’t associate them automatically.
|
|
|
![Screen_Shot_2016-10-31_at_3.33.13_PM](/uploads/569fce0d37e306bc81af84601f9797cd/Screen_Shot_2016-10-31_at_3.33.13_PM.png)
|
|
|
![Screen_Shot_2016-10-31_at_3.55.02_PM](/uploads/8a8f6f36b409da89938ef436e874d68b/Screen_Shot_2016-10-31_at_3.55.02_PM.png)
|
|
|
6. Delete the feature branch if it wasn’t automated in the merge accept. |
|
|
\ No newline at end of file |