basic rules

from high priority to lower priority

• git-history aims to help you understand life-time of the project (3)
• keep that (history of code) clean
• git aims to help developers' life easier (1)
• you must pay for something (life-easy) before having it, so let's learn to using git first
• we (you and me) don't have much fuck to give, so let's make less fuck (2)

more details

from my experience + IMO

• prefer rebase to merge (follow 2)
• avoid merging (IMO it provides a useless commit, however, if you think merging commit is useful, use it)
• learn/google these keywords if you don't know about it before: rebase, squash, fixup, cherry-pick

branch

• branch name: your_acount/your_stuff (example: quannk/test1, quannk/test2)
• play in your folder your_acount, no one care about it (follow 2)

while develop

• start coding from origin/master
• make small commits (follow 1)
• with stupid messages (fix, update, magic, temp, test, t, etc) (follow 1)
• no one care what you are doing in your branch, again (follow 2)

before make pull request (PR)

• remove all merging commits (follow 2)
• refactor your code (format, organize imports)
• squash/fixup stupid commits (follow 2)
• give commits meaningful messages (follow 3)
• add [Jira issues number] as prefix of your commits. Example: [AD-12] this is a nice commits (follow 3)
• if you don't know, your commits can have more than one lines, make use of it (follow 3)

[AD-12] refactor XXX

- rename zzz to aaa
- remove xyz
- etc 

update changes in PR

when you need update your code in PR

• force push if you update too much
• if it's simple change, use a commit (you can always fixup it later)
• github have a button to re-request to review PR with a single click
• in github, you don't need to answer all comments from reviewer
• if you don't answer a comment, it means you agree with it
• else comment back, or ping the reviewer in slack (don't boom each other with tons of github's mail) (follow 2)

before merge your PR

• remove all shitty commits (fix, test, etc) (follow 2)
• choose rebase or squash+rebase
• only choose merge if your branch is too messy, and you want to keep that mess for other

PR requester

• it's your responsibility to make sure your code works and properly tested
• it's your responsibility to rebase your code onto origin/master regularly, this help to avoid conflict ASAP (follow 1)
• it's your responsibility + right to merge your code to target branch
• it's your responsibility to delete your branch after merging (follow 2)

PR reviewer

• it's your responsibility to make sure new code follow code-base's convention, language's best practice, etc
• it's your responsibility + chance to understand/ask why the requester doing that magic
• try to check/improve correctness about business+logic and simplicity of code

bonus

• add jokes in comments (not your running code), it's fun to read!
• don't work where you shit (wc)
• don't shit where you work (git)
• we (you and me) don't have much fuck to give, so let's make less fuck (again)

example

refactor commits

let say your branch have this commits

pick implement XXX
pick fix xxx 1
pick fix xxx 2
pick fix yyy (yyy is a merged feature)
pick implement ZZZ
pick fix xxx 3
pick fix zzz 
pick fix xxx 4

let rebase -i it like this

pick implement XXX
fixup fix xxx 1
fixup fix xxx 2
fixup fix xxx 3
fixup fix xxx 4
pick fix yyy
pick implement ZZZ
pick fix zzz

then you will have this

pick implement XXX
pick fix yyy
pick implement ZZZ