Github Project Flow

Github Project Flow

Often we wonder what is the best way to manage our software project version control. We have branches, tags and Github even introduced pull requests on its website - there are so many ways to manage our code's changes.

In this presentation, I will be sharing on a way of managing your Git project flow from my experiences as an open source developer on Github. This flow will greatly help you to neatly manage your project well so that others can easily understand the flow.

The full updated presentation was presented to the Singapore PHP User Group at Mountbatten Square on the 26 Feb 2013 Meetup.

4749d60af0d45cc6ed8eaf014edb1f65?s=128

Sam-Mauris Yong

February 26, 2013
Tweet

Transcript

  1. Github Project Flow Sam-Mauris Yong HeartCode Pte. Ltd. http://heartcode.sg/

  2. Hello, I'm Sam Yong I'm a software developer

  3. Hello, I'm Sam Yong I'm a software developer + Project

    Manager
  4. Projects can snowball into mess

  5. How can I improve my source control flow?

  6. None
  7. None
  8. $ git init master

  9. $ git commit master

  10. $ git tag 1.0.0 1.0.0 master

  11. $ git branch develop 1.0.0 master develop

  12. $ git commit 1.0.0 master develop

  13. Github Pull Request 1.0.0 master develop

  14. Github Merge Request 1.0.0 master develop

  15. $ git tag 1.0.1 1.0.0 master develop 1.0.1

  16. Readme updates 1.0.0 master develop 1.0.1

  17. readme can just exist on master branch.

  18. Subsequent Releases 1.0.0 master develop 1.0.1 1.0.2

  19. Neat & Manageable Project Graph

  20. • modify code from branches other than master. • add

    tags at pull request commits • always build from tags • use Semantic Versioning see http://semver.org/
  21. • use Semantic Versioning see http://semver.org/

  22. • use Semantic Versioning see http://semver.org/ Version numbers Ease of

    moving forward DEPENDENCY HELL Standard set of rules
  23. My Software Public API

  24. X . Y . Z Patch version Increment only if

    backward compatible bug fix is introduced." “
  25. X . Y . Z Minor version Increment if new,

    backwards compatible functionality is introduced to the public API OR if any public API functionality is marked deprecated." “
  26. X . Y . Z Major version Increment if any

    backwards INCOMPATIBLE changes are introduced to the public API." “
  27. None
  28. Dependencies can be updated without worry of BC break.

  29. Thank You Take a look at all the great Octocats

    by Github at http://octodex.github.com/ @_mauris sam@heartcode.sg
  30. None
  31. Photo Sources • http://octodex.github.com/socialite/ - Used as described on http://octodex.github.com/faq.html

    • http://pixabay.com/en/puzzle-unfinished-mess-unresolved-55886/ - Public Domain • http://www.flickr.com/photos/23945877@N05/2623633694/ - Creative Commons Attribution-NonCommercial-NoDerivs 2.0 Generic • http://www.sxc.hu/photo/828750 - Standard SXC.hu License • http://octodex.github.com/codercat/ - Used as described on http://octodex.github.com/faq.html