Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Git & Open Source & Collaboration

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.

William Durand

January 28, 2016

More Decks by William Durand

Other Decks in Programming


  1. dž

  2. 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)
  3. GitHub is the largest code host on the planet with

    over 29.5 million repositories.
  4. GitLab is an Open Source (MIT licensed) web-based Git repository

    manager with wiki and issue tracking features.
  5. 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.
  6. GIT FLOW " " A successful Git branching model Well...

    Maybe not. See instead. this simple git branching model
  7. 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
  8. 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

    email" Emojis all the things! (like ) Atom
  10. (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!
  11. 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
  12. 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

    REQUESTS? Å http://www.gousios.gr/blog/How-do-project-owners-use-pull-requests-on-Github/
  14. 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
  15. ## 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