SOURCE CODE MANAGEMENT HARMONY

Git & Github for Sony Teams

Image from: http://en.wikipedia.org/wiki/File:Clingmans-dome-spruce-fir-tn1.jpg

THE COMPONENTSGit | Github | Team Process

Image from: http://farm6.staticflickr.com/5446/9195568635_a2f407dc97_o.jpg

THE COMPONENTS

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

THE COMPONENTS

Github

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

• 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 + GITHUBReasons Using git + Github is Necessary

• 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 + GITHUBReasons Using git + Github is Necessary

THE COMPONENTS

Team Process

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 PROCESSReasons Team Process is Necessary

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 PROCESSQuestions Team Process Answers

TEAM PROCESSThe Actual Process & Guidelines

Image from: http://farm8.staticflickr.com/7245/7344779672_f6fbc90949_o.jpg

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 PROCESSThe Actual Process & Guidelines

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 PROCESSThe Actual Process & Guidelines

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 PROCESSThe Actual Process & Guidelines

: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

16. When someone breaks the master branch, they need to be punished in some fashion. This is up to the team to decide

TEAM PROCESSThe Actual Process & Guidelines

TEAM PROCESSExample Process Timeline

Image from: http://farm8.staticflickr.com/7245/7344779672_f6fbc90949_o.jpg

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 PROCESSExample Process Timeline

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 PROCESSExample Process Timeline

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 PROCESSExample Process Timeline