Source Code Management Harmony: Git & Github for Sony Teams Git: The command line interface & network protocols Github: The code sharing, review and GUI tool Team process: the standards & guidelines with which we collaboratively interact with and operate these tools

1. SOURCE CODE
MANAGEMENT HARMONY
Git & Github for Sony Teams
Image from: http://en.wikipedia.org/wiki/File:Clingmans-dome-spruce-fir-tn1.jpg

2. THE COMPONENTS
Git | Github | Team Process
Image from: http://farm6.staticflickr.com/5446/9195568635_a2f407dc97_o.jpg

3. THE COMPONENTS

4. 1. The command line interface
• clone, checkout, push, merge, fetch, config, et al
2. The network communication
• local: /opt/git/project.git or file:///opt/git/project.git
• https: http://example.com/gitproject.git
• ssh:ssh://user@server/project.git
• git: git://server/project.git

5. THE COMPONENTS
Github

6. Many people think
these are part of git
itself because Github
is how they learn
about git
1. Pull Requests
• A Github idiom for merging from a branch or another repo
2. Forking
• Cloning a repo under a user or organization name
3. Code viewing and commenting
• Comment on specific lines of code
• View excellent visual diffs
• Emoji
4. Integrations
• Travis CI, et al

7. • The following important processes are much less common in
teams using SVN
1. Branching per task / small branches
2. Reviewing and fixing code in detail prior to commits to
master
3. Tight integration of SCM into project management
(PM) & bug management tools
4. Full team engagement in code process. Including
designers, PMs, senior managers etc. Github is so
visual that engagement is higher.
GIT + GITHUB
Reasons Using git + Github is Necessary

8. • Flexibility
1. More network protocols
2. SVN integration for people reluctant to learn git
3. Far more integration options
4. Nearly all respectable projects use git
• Speed & Agility
1. The process can match the agile team style
2. Code reviews can be done asynchronously
3. Branches are small and review of only 2 team
members is required so leviathan code reviews that
take up everyone’s time are no longer required
GIT + GITHUB
Reasons Using git + Github is Necessary

9. THE COMPONENTS
Team Process

10. 1. Standards are clear
2. Fewer team arguments, greater team harmony
3. Code reviews are more structured, more consistent and less
hurtful to the person being reviewed
4. Code quality and consistency is greatly increased
5. Cooperation in large organizations is easier
6. Cooperation in cross-functional teams is easier
TEAM PROCESS
Reasons Team Process is Necessary

11. 1. When do you open a pull request (PR)?
2. When do you fork, tag or branch?
3. What code formatting tools must be run prior to a commit?
4. What are the team guidelines for code consistency?
5. How many team members must review each PR?
6. What officially signifies approval of a PR?
7. What level of code coverage is required for a merge?
8. Who is responsible for the merge (committer/reviewer)?
9. What happens when someone breaks the build?
TEAM PROCESS
Questions Team Process Answers

12. TEAM PROCESS
The Actual Process & Guidelines
Image from: http://farm8.staticflickr.com/7245/7344779672_f6fbc90949_o.jpg

13. 1. Each task within your PM tool results in a branch
2. Each bug fix results in a branch
3. You fork (instead of branch) when you are contributing to
code created by someone in a different team/organization
4. You tag when a release has been approved by QA & your PM
5. Tags follow the semantic versioning policy (http://
semver.org)
6. Code consistency/quality tools agreed upon by the team
must be run before every commit that hits the server. Local
commits are up to your discretion
TEAM PROCESS
The Actual Process & Guidelines

14. 7. Branch name format: IDFromPMTool_branch_purpose
8. Commit messages must be in imperative form and be less
than 72 characters long
9. Your commit history must be rebased before pushing to a
remote branch.You should generally squash commits of
fixing minor mistakes, reverting code etc. Make your
commit history easy to read and concise
10. Code that violates code formatting standards cannot be
merged, no exceptions unless there is a truly good reason
and comment is left in the code documenting why
TEAM PROCESS
The Actual Process & Guidelines

15. 11. Two team members should look at any PR where the LoC
changed is greater than 6
12. Only one team member needs to approve a PR.They
approve a PR by using the :shipit: emoji or a variation
thereof
13. The person who presses merge is responsible for the quality
of the PR
14. Tests must be written for each module added
15. Tests must be run, automated, on each commit to a branch
TEAM PROCESS
The Actual Process & Guidelines

16. :SHIPIT:
http://www.quora.com/GitHub/What-is-the-significance-of-the-Ship-It-squirrel
http://shipitsquirrel.github.io
http://www.emoji-cheat-sheet.com

17. 16. When someone breaks the master branch, they need to be
punished in some fashion.This is up to the team to decide
TEAM PROCESS
The Actual Process & Guidelines

18. TEAM PROCESS
Example Process Timeline
Image from: http://farm8.staticflickr.com/7245/7344779672_f6fbc90949_o.jpg

19. 1. Team member receives a task for refactoring an album view,
with the ID in Rally (PM tool) of TA306
2. …pulls latest from master: git pull master
3. …creates branch TA306_album_view_refactor off of
master: git checkout -b TA306_album_view_refactor
4. …pushes branch name to remote repo: git push origin
TA306_album_view_refactor
5. Team member sets local branch to track origin: git branch —
set-upstream-to=origin/TA306_album_view_refactor
TA306_album_view_refactor
TEAM PROCESS
Example Process Timeline

20. 6. …creates several local commits without pushing to origin
7. …pulls master back in: git checkout master && git pull &&
git checkout TA306_album_view_refactor && git merge
(resolving any conflicts that arise)
8. …runs `git rebase -i` to choose which commits to keep
history for and which to squash
9. …runs git push origin TA306_album_view_refactor
10. …goes to Github and compares
TA306_album_view_refactor to master, ensuring there
aren’t any mistakes
TEAM PROCESS
Example Process Timeline

21. 11. …opens a pull request and notifies his/her team
12. …1 or 2 team members reviews the code against team
guidelines and their experience, and runs the code locally to
verify it works
13. …responds to any feedback on the PR by either changing
the code or coming to an agreement with the reviewer(s)
that it should not be changed
14. …once all feedback is addressed, the main reviewer will
post a :shipit:. If the committer is done, one of the reviewers
then merges the branch into master and deletes the branch
TEAM PROCESS
Example Process Timeline