Git & Open Source & Collaboration

Talk on Git, Open Source, and collaborative patterns (a.k.a. workflows). This is a short-version of my "Git & GitHub & Open Source" talk I gave at LavaJUG: https://speakerdeck.com/willdurand/2015.

Transcript

1. GIT & OPEN SOURCE & COLLABORATION William Durand - January 28th, 2016 @ Michelin
2. DISCLAIMER: I am not working at GitHub.
3. "MACRO" AGENDA 1. Git 2. Git(Hub|Lab) 3. Workflows 4. Open Source
4. dž
5. Git is a widely used version control system for software development. It is a distributed revision control system. Å https://en.wikipedia.org/wiki/Git_(software)
6. Credit: https://aht.github.io/whatisgit/
7. GIT FOR NEWCOMERS Å try.github.io
8. ® GITHUB
10. GitHub is the largest code host on the planet with over 29.5 million repositories.
11. SOCIAL CODING
12. INTEGRATED ISSUE TRACKING
13. INTEGRATED ISSUE TRACKING
14. SYNTAX HIGHLIGHTING
15. COLLABORATIVE CODE REVIEW
16. COLLABORATIVE CODE REVIEW
17. PULL REQUEST (PR) Pull Request = Code + Issue + Code Comments
18. COMPARE VIEW
19. RELEASE MANAGEMENT
20. TEAM MANAGEMENT
21. OUTSIDE COLLABORATORS
22. PER PROJECT COLLABORATORS
23. PROTECTED BRANCHES
24. DEPLOYMENT MANAGEMENT
25. HUB git + hub = github \o/ Å hub.github.com
26. GITLAB (quickly)
28. GitLab is an Open Source (MIT licensed) web-based Git repository manager with wiki and issue tracking features.
29. GitLab started a side project in 2011. In 2015, more than 800 (worldwide) contributors, 10+ employees, and 1.5M raised in seed funding in July.
30. GETTING STARTED On your In your company gitlab.com git.framasoft.org Raspberry Pi Pro-tip: Merge Request ≈ Pull Request
31. WORKFLOWS a.k.a. collaboration patterns
32. CENTRALIZED Shared repository (subversion-style)
33. RELEASE (OR INTEGRATION) MANAGER Blessed repository + a release manager
34. DICTATOR AND LIEUTENANTS Blessed repository + trusted lieutenants and a dictator
35. GIT FLOW " " A successful Git branching model Well... Maybe not. See instead. this simple git branching model
36. GITHUB FLOW Å Understanding the GitHub Flow
37. GITLAB FLOW Å GitLab Flow
38. POUCE DRIVEN DEVELOPMENT › + › = Good to merge/ship
39. OPEN SOURCE
40. In production and development, Open Source as a development model promotes a universal access via a free license to a product's design or blueprint [...]. Å http://en.wikipedia.org/wiki/Open_source
41. Open-source software is very often developed in a public , collaborative manner.
42. HOW TO CONTRIBUTE?
43. Everyone can contribute.
44. FORK THE REPOSITORY
45. CREATE A BRANCH git checkout -b feature-branch
46. EAT, SLEEP, CODE, REPEAT.
47. SUBMIT A PULL REQUEST But, how?
48. LOOK AT THE CONTRIBUTING FILE (If it does not exist, contribute by adding it!)
49. WRITE GOOD COMMIT MESSAGES Capitalized, short (50 chars or less) summary More detailed explanatory text, if necessary. Wrap it to about 72 characters or so. In some contexts, the first line is treated as the subject of an email and the rest of the text as the body. The blank line separating the summary from the body is critical (unless you omit the body entirely); tools like rebase can get confused if you run the two together. Write your commit message in the imperative: "Fix bug" and not "Fixed bug" or "Fixes bug." This convention matches up with commit messages generated by commands like git merge and git revert. Further paragraphs come after blank lines. Å A Note About Git Commit Messages
50. FIRST LINE ≤ 50 CHARS, PRESENT IMPERATIVE "Subject of an email" Emojis all the things! (like ) Atom
51. (Blank line before details) DETAILS LINES ≤ 72 CHARS: EXPLAIN WHAT YOU DID "Body of an email" (GFM): G itHub F lavored M arkdown Italics, bold URL autolinking Syntax highlighting Auto-close issues : Fix #123 and more!
52. REBASE YOUR BRANCH
53. SQUASH YOUR COMMITS git rebase -i HEAD~2 pick 5335450 add test pick 4c20f8d Fix undefined variable # Rebase 35124cb..4c20f8d onto 35124cb # # Commands: # p, pick = use commit # r, reword = use commit, but edit the commit message # e, edit = use commit, but stop for amending # s, squash = use commit, but meld into previous commit # f, fixup = like "squash", but discard this commit's log message # x, exec = run command (the rest of the line) using shell # # These lines can be re-ordered; they are executed from top to bottom. # # If you remove a line here THAT COMMIT WILL BE LOST. # # However, if you remove everything, the rebase will be aborted. # # Note that empty commits are commented out Å Squashing commits with rebase
54. PUSH & CREATE
55. PROFIT!
56. WHAT HAPPENS THEN?
57. An Open Source maintainer will look at your work.
58. PULL REQUEST REVIEW Understand the goal of the PR Try to reproduce the issue Try the fix Test the new feature Think about edge cases Write documentation if not provided
59. WHAT KEY CHALLENGES DO INTEGRATORS FACE WHEN WORKING WITH PULL REQUESTS? Å http://www.gousios.gr/blog/How-do-project-owners-use-pull-requests-on-Github/
61. HOW TO OPEN SOURCE?
62. LICENSE
63. NO LICENSE == ALL RIGHTS RESERVED © Å https://github.com/blog/1964-license-usage-on-github-com
64. Å TLDRLEGAL.COM
65. Å CHOOSEALICENSE.COM
66. THE README FILE
67. project-x ========= project-x is a better way to achieve this and that, by leveraging the new API, bla bla bla. ## Usage ... ## Installation ... ## Requirements ... ## Contributing See CONTRIBUTING file. README example 1/2
68. ## Running the Tests ... ## Credits ... ## Contributor Code of Conduct Please note that this project is released with a [Contributor Code of Conduct](http://contributor-covenant.org/). By participating in this project you agree to abide by its terms. See CODE_OF_CONDUCT file. ## License project-x is released under the MIT License. See the bundled LICENSE file for details. README example 2/2
69. THE CONTRIBUTING FILE
70. Also, checkout ! Atom's one
71. THE CODE_OF_CONDUCT FILE
72. Å CONTRIBUTOR-COVENANT.ORG
73. WRITE TESTS & AUTOMATE
74. BE STANDARD
75. ATTITUDE
77. COMMUNICATION IS KEY!
78. HIRE PEOPLE
79. All of this can be applied to your "internal" projects too ė
80. ONE MORE THING
81. Open Source is more than making code available for free.
82. It is a lot of work!
83. Care about the people first.
84. Communication is essential!
85. Everyone can contribute! Å Your First PR
86. Open Source is more than downloading code available for free.
87. Give, don't (only) take.
88. There are people behind Open Source projects.
89. Money is still an issue in OSS... Å https://coderanger.net/funding-foss/
90. ...which is not the case in a company.
91. THANK YOU. QUESTIONS? ¾ ® ¬ Â williamdurand.fr github.com/willdurand twitter.com/couac TailorDev SAS
92. LINKS http://williamdurand.fr/2013/07/04/on-open-sourcing-libraries/ http://williamdurand.fr/2013/11/20/on-creating-pull-requests/ http://gitready.com/advanced/2009/02/10/squashing-commits-with-rebase.html http://git-scm.com/book/en/v2/Git-Branching-Rebasing http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html https://github.com/blog/1530-choosing-an-open-source-license https://help.github.com/articles/open-source-licensing/ http://www.codinghorror.com/blog/2007/04/pick-a-license-any-license.html https://medium.com/code-zen/how-to-maintain-a-successful-open-source-project- aaa2a5437d3a http://ryanbigg.com/2015/11/open-source-work/ https://robots.thoughtbot.com/git-bisect https://git-scm.com/book/en/v2/Git-Tools-Debugging-with-Git https://git-scm.com/docs/git-archive http://writing.jan.io/2015/11/20/sustainable-open-source.html