Home

Branches

1. master branch has releases; kept stable
2. develop branch has development commits; more unstable
3. developers work on their own branches which are merged to develop
4. release- branches are created from develop branch and merged to master

Development Workflow

Developers pull develop branch, copy it to a new branch (eg. dev1guy-description-of-feature). When feature or bugfix is done, create a pull request from the new branch to the develop branch. The new branch is then rebased on top of develop branch and then merged to the develop branch, the new branch is removed and the pull request is closed.

In terms of commands it is something like.

1. git clone [email protected]:ENSL/NS.git
2. git checkout develop
3. git checkout -b dev1guy-new-movement develop
4. (add changes to files)
5. git commit -a
6. git push origin dev1guy-new-movement
7. (optional step: git rebase develop in case develop has new changes after creating the branch)
8. (go to website and create a pull request from new branch to develop)

The idea here of both rebase and pull request is to keep the git history clean but create a merge so commit history has link to Github's pull request.

Release

When develop branch is ready for release, we create a release branch from develop, merge to master, and tag the merge commit with a version. Release is created through the website.

Other rules

1. No binary blobs to the git tree
2. No temporary or backup files
3. Do not include extra libraries unless absolutely necessary
4. Use LF line endings (Linux-style) in repository. Then git can checkout Windows-style (CRLF) when it needs them and commit LF line endings back to repo. This should be transparent to the developer. The .gitattributes and .gitignore files have been configured to enforce this style.