The document discusses lessons learned from using Git and GitHub Enterprise in two development projects. It describes problems that arose from their previous workflow including difficulty reviewing code changes, large commit granularity, and merge conflicts. The document then outlines their new workflow using GitHub Enterprise which focuses on trunk-based development, branching by issue, and initiating code reviews through pull requests. Key aspects of the new workflow include short-lived topic branches, resolving conflicts in branches before pull requests, and rewriting branch history before a pull request but not after. Overall, the new workflow and tools have helped improve code quality and reduced issues.

1. Dev with Github Ent.
Lesson Learned
Hiroshi Wada
10 min talk @ ATP - Jul 9, 2013

2. Projects and the dev environments
Web app: Ajax, REST, Spring, Puppet, AWS, ...
5-6 ppl, 1 yr
3500+ commits
Forge (git), Jenkins, JIRA, FishEye, and Crucible
Command line app: plain Java, VMware, ...
4 ppl, 4mo
1100+ commits
Github Enterprise, and Jenkins

3. Our bad agile days
Push commits to master when you like
Add a tag in commit comments to track by JIRA
e.g., "YDR-225 New exception in handler"
Pick up commits and create a review request
Big feature - branch and forget

4. Problem: hard to review code
Pain of using JIRA, Fisheyes and Crucible
Individual tools are nice - lack of workflow
Heavily depend on manual effort
Forget to write "YDR-XXX"
No force to create a review
We're lazy. This never work.

5. Problem: commit granularity
One JIRA issue =>
One big commit containing all changes?
or series of small commits?
Easy to review a series of commit
e.g. skip a refactoring making lots changes
But series of commits could be "contaminated"
YDR-X
Refactoring
YDR-X
Add func
Merge
Y and X
YDR-X
Fix a bug
YDR-Y
Change XXX

6. Problem: Merge hell

7. Problem: Merge hell

8. Problem: Merge hell

9. Problem: Cherry pick?
Hard to find which commits to cherry pick
Which commits addressing what issue?
Commits could be "contaminated"
Cherry pick often did not work
Conflict - mostly
No conflict - Can I trust?

10. We need to fix it - but w/ little effort
Trunk-based development *
No big branch
Branch-by-issue
Clear isolation of issues
Enterprise Github
Simple workflow by pull request
* paulhammant.com/2013/04/05/what-is-trunk-based-development/

11. Our current workflow
1. Identify an issue small enough to finish in
minutes to few days by one person
2. Record it and get the issue number

12. Our current workflow
1. Identify an issue small enough to finish in
minutes to few days by one person
2. Record it and get the issue number

13. Our current workflow
1. Identify an issue small enough to finish in
minutes to few days by one person
2. Record it and get the issue number
3. Create a branch and push commits

14. Our current workflow
1. Identify an issue small enough to finish in
minutes to few days by one person
2. Record it and get the issue number
3. Create a branch and push commits

15. Our current workflow
1. Identify an issue small enough to finish in
minutes to few days by one person
2. Record it and get the issue number
3. Create a branch and push commits
4. Send a pull request to initiate the review

16. Our current workflow
1. Identify an issue small enough to finish in
minutes to few days by one person
2. Record it and get the issue number
3. Create a branch and push commits
4. Send a pull request

17. Our current workflow
1. Identify an issue small enough to finish in
minutes to few days by one person
2. Record it and get the issue number
3. Create a branch and push commits
4. Send a pull request to initiate the review
5. Merge

18. Who resolve conflicts?
Mostly no conflict thanks to short turn-around
Branch owner resolve conflicts by rebase
before sending a pull request
Reviewer can just hit the "merge" button
Reviewer's job
Branch
owner's job
merge commit w/ conflicts merge commit w/o conflicts

19. Rewrite the history
Ok to rewrite the history in remote (`push -f`)
until sending a pull request - if you work alone
Allow us for working at night/weekend :)
Only adding commits after a pull request
Rebase alters commit ids -> bad
commit id = SHA1(parent commit id, content)
Commits get unreachable so as comments
i.e., no comment before a pull request

20. After merging (1/3)
Fix issues (if raised) in the topic branch then
merge (pull request) into master again
Mostly happen right after the first merge
No *new* conflict to solve

21. After merging (2/3)
If Master diverts largely
Merge master to the topic branch, or
Create a new issue & branch
Do same when master diverts while reviewing
(i.e., after a pull request)

22. After merging (3/3)
Delete the branch after few days
list of merged branches

23. Tip: Make commit ids the single truth
Puppetize the whole deployment
Get a consistent test env in minutes
Full stack, monitoring, ...
Not the AWS resources yet
Don't rely on other versionings
Int. tests on CI => test scripts
Release workflow => scripts

24. Other Tips
Command line is your best friend
Everyday git commands are just ~10
Hipchat !
Aggregate all you
need (and not)
Nagios
Github
Nonsense :)
Discussion

25. autosetuprebase = always
No merge commits within one branch
Show status on console
e.g., github.com/olivierverdier/zsh-git-prompt
*MUST* for those switching branches often
git fetch -p
Remove tracking branches no longer exist