SCM Harmony: git & Github for Sony Teams


Published on

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

Published in: Engineering, Technology
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

SCM Harmony: git & Github for Sony Teams

  1. 1. SOURCE CODE MANAGEMENT HARMONY Git & Github for Sony Teams Image from:
  2. 2. THE COMPONENTS Git | Github | Team Process Image from:
  4. 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: • ssh:ssh://user@server/project.git • git: git://server/project.git
  5. 5. THE COMPONENTS Github
  6. 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. 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. 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. 9. THE COMPONENTS Team Process
  10. 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. 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. 12. TEAM PROCESS The Actual Process & Guidelines Image from:
  13. 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:// 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. 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. 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. 16. :SHIPIT:
  17. 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. 18. TEAM PROCESS Example Process Timeline Image from:
  19. 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. 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. 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