scm harmony: git & github for sony teams
DESCRIPTION
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 toolsTRANSCRIPT
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