Skip to content

Commit 979648b

Browse files
authored
Merge pull request #17 from csesoc/dev
Create CONTRIBUTING.md
2 parents b8aaba4 + 2bf5071 commit 979648b

File tree

1 file changed

+39
-0
lines changed

1 file changed

+39
-0
lines changed

CONTRIBUTING.md

Lines changed: 39 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,39 @@
1+
## Our Git workflow
2+
3+
### Setup
4+
You should only need to complete this setup once. 
5+
6+
If you'd like now is the time to set up SSH and GPG keys.
7+
8+
1. `git clone` the URL given on the Github repo into a directory of your choice.
9+
10+
### Branches
11+
We will be using the [GitFlow](https://nvie.com/posts/a-successful-git-branching-model/) branching model.
12+
13+
We have **two** evergreen branches (persistent branches). 
14+
15+
- `master` always points to our `latest` release. Merge commits on `master` are always tagged with the version.
16+
- `dev` is the branch you `checkout -b` and pull request merge into. `dev` should always be a `green` build (all checks are green)
17+
18+
We can make **three** types of temporary branches:
19+
20+
- `feat/branch-name`: A feature branch is used for most additions. A feature branch always branches off `dev` or another feature branch.
21+
- `fix/branch-name`: A fix branch is identical to a `feat` branch except it indicates the branch is used only for fixing a bug.
22+
- `hotfix/branch-name`: A hotfix branch is used for **critical** fixes such as high severity security flaws. Hotfixes are always merged directly into `master` and `dev`.
23+
24+
N.B1 Note all these branches are made using `checkout -b` from the appropriate base branch. This naming scheme isn't enforced by Git or Github and is only for clarity.
25+
26+
N.B2 We do not use release branches (we go directly from `dev` to `master` to reduce complexity)
27+
28+
## Typical Workflow
29+
1. `git checkout dev` (moves to the `dev` branch)
30+
2. `git pull` (ensures your local branch is up to date with the remote branch)
31+
3. `git checkout -b your-feature/fix-branch-name` (checkouts to a new branch to you to do your work on)
32+
4. Make one **atomic** change to your files (typically you should contain your changes to one purpose at a time)
33+
5. `git add -A` (stages all the changes in your working directory for commit). You can also do `git add file1 file2` to stage individual files.
34+
6. `git commit -m "Your commit message describe your changes"` (commits your changes locally)
35+
7. You can share your changes with remote at any time by doing a `git push`
36+
8. When you are done do a `git rebase -i origin/dev` (rebases your branch on the latest `dev` branch). The `-i` means you can see the changes.
37+
9. `git push --force-with-lease` (this is a special push command which allows you to update the remote even if you have diverging histories) It *should* only push changes if it won't overwrite another person's commits BUT only do this is you are certain you won't overwrite anything. There is no easy way to undo this.
38+
10. Open a pull request for your branch into the `dev` branch. Typically the pull request opener also merges the PR after all checks are passed.
39+
11. Rinse and repeat.

0 commit comments

Comments
 (0)