git rebase talk

clean-git.md

Clean Git : Craft beautiful commits with git rebase

Development is an iterative process, you constantly change your code after better understanding of business/requirements. git rebase is the mean to do these changes.

git as a documentation tool

Devs hate to write docs: No more java docs, no more UML docs ... Only documenation that is left is ..........

The COMMIT MESSAGE (provide context to the code change for future dev(including yourself)).

What is a good commit message

(http://chris.beams.io/posts/git-commit/)

• subject : 50 chars (If applied, this commit will ----)
• blank line
• more description on the title if it was not explicit enough something 50 chars is not enough
• problem statement (Most important) / hafira is recommended here describe the context in details WHY and not HOW

What I like to add

• (My personal fav list of responsibilities of each class) (if a class name and the responsibility do not align, if not single resp principle respected , you will spot it here)

• (flow of types for scala ) (if the types can be simplified will also be spotted here)

• IO chart : rabbit -> kafka -> rabbit

• complex scenario involving events and time snooze -> unsnooze -> snooze ....

• Resolves JIRA: #123

• See also JIRA : #456, #789

git as a review tool

Always write for the reviewer

• Use git web (https://github.com/motemen/git-browse-remote) to check you last commit in github, pretend you are the reviewer and see if anything bothers you or is out of place
• Work around github horrible PR features (no commit specific review, looses comments after rebase , ...)
• [PR-FIX] - prefix PR fixes commits and add them after the appropriate commit
• Make sure to check both main thread and each commits

git as a design tool

Before you write any code open up a file and write your ideal commit log (target commit log) for the feature you are going to do

1. Design features with cdd (commit driven design)

• Split your feature in logical changes
• Each commit receives its title no more than 50 chars
• check that your commit is not too fat , split if needed
• Fill in the problem statement part, Explain the problem that this commit is solving Focus on why not how

2. What goes in a commit . i.e (Structural split of changes)

• Only one "logical change" per commit smaller the amount of code being changed, the quicker & easier it is to review & identify potential flaws.

git rebase design patterns (live coding/examples)

Common recurring patterns and tips to use your tools to solve them easily

1. reformat only commit (if file was badly formatted before)
2. retrofit refactoring (future -> past ) (use rebase e and intellij local history) 2a. pushdown refactoring (past -> future) overwrite with old commit using intellij get (commit and then use local history to resurect the change isolate the refactoring in its own commit , move it to where it should be)
3. split fat commits : rebase e , reset --hard HEAD
4. move code from one commit to another one (use git add interactive and patch)(gitx)
5. PR fix commit with rebase e and git commit --amend
6. Add a temp commit the beginning (enable debug logs/ various speedup for dev) that will be deleted after final review
7. resolve rebase merge conflicts with Intellij and local history
8. abort when it's too hard
9. use rebase execute to make each commit compile/test independently
10. split test commits to their own (more important than it looks like)

git power user : Commit often, deploy often (thanks robin), fixup/squash constantly, use aliases

Will show my regular flow here

1. Each commit should provide executable value, you should be able to deploy to robin after each commit and validate your change there, sometimes it means adding a code that exercise your change and that will be removed in a later commit (should usually happen in long features and in the early commits) (Having executable code running in staging after each commit allows to spot faster implementation errors and fix them fast)

2. Run Fast, commit even if your not happy with the solution prefix the commit with [WIP], progress as fast as possible to the end of your target commit log . (reaching the end of your target log even in [WIP] let you spot all the design flaws and fix them fast)

3. Go back and use rebase e to edit and move your [WIP] commits to production grade commits .

Appendix useful git aliases

.gitconfig

# This is Git's per-user configuration file.
[user]
# Please adapt and uncomment the following lines:
	name = Daniel Sebban
	email =
[core]
	editor = subl -n -w
[alias]
	r = rebase -i develop
	fixup = "commit --fixup HEAD "
	auto = "git rebase -i develop --autosquash "
	squash = rebase -i develop --autosquash
	grog = log --graph --abbrev-commit --decorate --all --format=format:\"%C(bold blue)%h%C(reset) - %C(bold cyan)%aD%C(dim white) - %an%C(reset) %C(bold green)(%ar)%C(reset)%C(bold yellow)%d%C(reset)%n %C(white)%s%C(reset)\"
	fsquash = commit --fixup HEAD && rebase -i develop  --autosquash
	web = browse-remote --rev
	lg = log --color --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit
	stat = log --stat --oneline
	ls = log --pretty=format:"%C(yellow)%h%Cred%d\\ %Creset%s%Cblue\\ [%cn]" --decorate
	ll = log --pretty=format:"%C(yellow)%h%Cred%d\\ %Creset%s%Cblue\\ [%cn]" --decorate --numstat
	lnc = log --pretty=format:"%h\\ %s\\ [%cn]"
	lds = log --pretty=format:"%C(yellow)%h\\ %ad%Cred%d\\ %Creset%s%Cblue\\ [%cn]" --decorate --date=short
	ld = log --pretty=format:"%C(yellow)%h\\ %ad%Cred%d\\ %Creset%s%Cblue\\ [%cn]" --decorate --date=relative
	le = log --oneline --decorate
	dl = "!git ll -1"
	dlc = diff --cached HEAD^
	f = "!git ls-files | grep -i"