git_workflow

Git workflow

1. New issue arise (ie. Pivotal task is created).
2. Developer creates new branch from latest master branch.

git checkout master
git pull origin master
git checkout -b branch_name

3. Developer writes the code.
4. Developer writes tests for the code.
5. Developer commits the code and pushes to remote branch.

git add -A .
git commit
git push -u origin branch_name

6. When Developer consider his code ready, he checks that:
   1. His implementation matches issue description, that nothing was skipped. If something in his implementation differs from issue description, he explains those differences shortly in comment (TODO: Comment where ? In pivotal, PR, or commit ?).
   2. He makes sure that he creates his branch is based on master or other branch described in pull request (ie. by looking at git log --graph --decorate).
   3. He makes sure that all tests are passing and there are no linting issues by running ./full-check.sh
   4. In cooperation with Cluster Management Team he makes test deployment to cluster devel.concent.golem.network.
   5. He reviews his own code, commit after commit, and checks if there are no unsquashed commits, no [TMP] commits, TMP marks in code, commits that are not related with current issue he is working on. If there are any of those, he fixes them.
7. Developer creates pull request in Github, adds link to Pivotal issue in comment if there is any, adds at least one reviewer.
8. Developer stops working on this branch.
9. Reviewer looks over the code and add his comments over issues he finds.
10. Developer:
    1. Fixes each issue in separate commit using --fixup with the original issue commit id. The cause of that is that reviewer will see only this modification in next review.

    git commit --fixup original_issue_commit_id
    

    2. Rebases master to his branch if there are any new commits on master.

    git rebase master --interactive
    

11. Reviewers looks over fixes. Steps 9-11 are repeated until code is free of issues.
12. One of the reviewers squashes fixing commits, rebases master and merges. Assuming that he have the latest master, merge is done using:

    git checkout master
    git merge --no-ff branch_name
    

13. Github pull request is closed,
14. Developer marks Pivotal task as Finished and adds Github pull request link to Pivotal task in comment.

Checklista code review

• Wszystkie testy powinny przechodzić.
• Linter nie powinien zgłaszać warningów.
• Migracje powinny przechodzić poprawnie, zarówno na czystej bazie jak i bazie z danymi.
• Migracje powinny być zsynchronizowane z kodem. manage.py makemigrations nie powinno wykrywać żadnych nowych zmian.
• Zależności w requirements.txt powinny być zsynchronizowane z requirements.lock. Wynik odpalenia pip freeze > requirements.txt na czystym virtualenvie powinien być identyczny przed i po pip install -r requirements.lock.
• Nowy kod nie powinien obniżać znacząco procentowego pokrycia kodu testami.