Using the Repository - ababaian/serratus GitHub Wiki

Serratus requires git for version control and to manage contributions from many authors.

To clone the serratus repository locally, run:

git clone https://github.com/ababaian/serratus.git

Repository organization

serratus/
β”œβ”€β”€ bin                     # Binaries and executable tools/modules         
β”œβ”€β”€ containers              # Container make files and scripts for production
β”œβ”€β”€ data                    # For _local_ storage of data (.gitignore)
β”œβ”€β”€ doc                     # Documentation files
β”œβ”€β”€ img                     # Visual assets and workflow diagrams
β”œβ”€β”€ local                   # For _local_ storage of files (.gitignore)
β”œβ”€β”€ notebook                # Shared electronic lab-notebook and associated data files.
β”œβ”€β”€ packer                  # Creating standardized node images (AMI)
β”œβ”€β”€ src                     # Source code for modules/tools used in Serratus
β”œβ”€β”€ terraform               # Cloud resource definitions for cluster
β”œβ”€β”€ CONTRIBUTING.md         
β”œβ”€β”€ LICENSE
└── README.md

Gitflow

This project is managed by the GitFlow pattern of git-branching. The only difference is that master/origin is for development and there is a seperate production branch for tagged versions being deployed until version 1.0.

The main or master branch is the development backbone. This is the operational code with completed experiments. You should not "push" directly to master but instead issue a "pull request" to merge your work

  β”Œβ”€β— 0.1.4          β”Œβ”€β— 0.1.5     # Tagged release used in production
master/origin───●────●───●──●──..  # master/origin : Production Ready Serratus    
 β”œβ”€β— suzyβ”€β”€β”€β”€β”€β”€β”€β”˜    β”‚   β”‚  β”‚      # Suzy's experimental working branch
 └──●───gui-devβ”€β—β”€β—β”€β”€β”˜   β”‚  β”‚      # Frank is working on the GUI feature
                   hotfixβ””β”€β—β”˜      # Suzy issues a tested hotfix to production

Experiments and Development are on Branches

In git there are independent working copies of the code-base called branches. Each contributor works on his/her own branch, and this does not interact with other branches.

# Create a development branch called `suzy` to run an experiment
git branch sally
# Move to your branch
git checkout sally

Name Branch

For Running an Experiment you should work on your own branch named with your initials/id.

feature-dev Branch

If you're developing a feature for integration into the Serratus codebase, you should name your branch <feature_your_developing>-dev or <name>-dev if it's multiple things.

Now you can modify any of the files in your local serratus/, when you're ready to save your work (say I modified serratus/docker/Dockerfile)

Stage your changes:

git add docker/Dockerfile

Check the status of what changes are staged and what is not staged:

git status

Commit your changes to version control:

git commit -m "Short description of what these changes accomplished"

End of the work-day, back-up your changes to the online GitHub repository:

git pull # download others changes from the online repo
git push # upload your changes to the online repo

Creating Pull Requests

Create a Pull Request when you've finished a larger unit of work, like completing a feature. Your branch changes can be combined with the master branch and into production code.

Add a custom footer
⚠️ **GitHub.com Fallback** ⚠️