Skip to content

Latest commit

 

History

History
118 lines (81 loc) · 2.73 KB

CONTRIBUTION_GUIDE.md

File metadata and controls

118 lines (81 loc) · 2.73 KB

Contribution Guide

git workflows

1. Fork the project

2. Clone and set the upstream

git clone <repo:forked>
cd repo
git remote add upstream <repo:forked from>

3. Get the latest changes from upstream

git checkout dev
git pull upstream dev

Regular git workflow

  1. Create a new topic branch (i.e. “issue[number]”, Example: “issue69”)
git checkout -b issue[number]
  1. Commit changes
git add .
git commit -m "commit message"
  1. Push origin
git push origin(your repo) issue[number]
  1. Fetch the Upstream/Dev
git fetch upstream dev
  1. Merge upstream/dev with the issue[number] branch
git checkout issue[number]
git merge upstream/dev
  1. After fixing conflicts, run all test to ensure nothing breaks and then just run
git add .
  1. Push to forked branch:
git push origin(forked br.) issue[number]
  1. Open a Pull Request with a clear title and description against the dev branch. Please make sure, your pull request have only your changes necessery files. Check it by command
git diff issue[number] upstream/dev

// Or
git diff filename.md
  1. Remove the issue branch after successful pull request
git branch -D issue[number]
git push origin :issue[number]

[House of rules]

  • Master branch always deployable. So, please never commit on master br. Introducing GitFlow
  • Test before you push. Do not push half-done work.
  • Features are developed in branches and merged into dev branch.
  • Create a pull request in dev branch.
  • Code will be reviewed by peers before the merge.

Commit and messages

Commit message should be brief but descriptive enough to convey the message of what has been done in this commit, for example

  • Add delete user option in the dashboard
  • Replace jQuery onReady listener with plain JS; fixes #13
  • Add issue number in final commit message when the task is complete

Coding style

PSR-2: Coding Style Guide

Project workflow

  • Tasks will be created as an issue with appropriate label and milestone, also be available in project board of the repository.
  • By default tasks will be at Backlog column.
  • You can self-assign yourself to a task or task can be assigned to you.
  • When a member start a task, the card should be moved to In Progress column.
  • When someone test a task other than the original contributor after task is complete it should be placed in In Review.
  • When a task is reviewed by a peer the task should be placed in Done column.
  • Only one member should work in a single task.

Thank you!

@bdjunayed