SCM Harmony: git & Github for Sony Teams
Upcoming SlideShare
Loading in...5

SCM Harmony: git & Github for Sony Teams



Source Code Management Harmony: ...

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



Total Views
Views on SlideShare
Embed Views



1 Embed 1 1



Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

SCM Harmony: git & Github for Sony Teams SCM Harmony: git & Github for Sony Teams Presentation Transcript

  • SOURCE CODE MANAGEMENT HARMONY Git & Github for Sony Teams Image from:
  • THE COMPONENTS Git | Github | Team Process Image from:
  • 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: • ssh:ssh://user@server/project.git • git: git://server/project.git
  • 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 + GITHUB Reasons 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 + GITHUB Reasons 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 PROCESS Reasons 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 PROCESS Questions Team Process Answers
  • TEAM PROCESS The Actual Process & Guidelines Image from:
  • 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:// 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
  • 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
  • 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
  • :SHIPIT:
  • 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
  • TEAM PROCESS Example Process Timeline Image from:
  • 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
  • 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
  • 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