Project Management - foxymoron/test GitHub Wiki

VCS

  • Git
    • Distributed VCS that lets you create, destroy and combine branches with minimal effort.
    • Love it.
  • SVN
    • Centralized VCS. It' too simple. Not flexible. It's outdated.
    • Don't like.
  • Perforce
    • It's too complex.
    • Hate it.

Git vendors

  1. Github
  • Solution: Cloud, On-Premise (Enterprise - paid)
  • Features: Issues, Labels, Milestones, Projects, PR, Wiki, Gists, Organizations
  • Love this. Must use Issues and Projects especially.
  • Excellent video => https://www.youtube.com/watch?v=ff5cBkPg-bQ
  • [] Need to check Organizations
  1. Zenhub
  • Solution: On-Premise (Enterprise - paid)
  • Integrates with Github (Enterprise)
  • Extends Github with better Agile Project Management features
  1. Gitlab
  • Solution: Cloud, On-Premise (Enterprise - paid), On-Premise (Community Edition - free)
  • Like subgrouping in this which is not in Github.
  • UI is different than Github. Not so intuitive like Github.
  • Considering CE it's free, its more than good enough.
  • Has Issues, Labels, PR, Wiki, Snippets
  • [] Need to check Milestones, Projects

Workflow Strategies

  1. Github Flow: (for simple workflow)
  • Relies on short-lived branches.
  • 1 master branch where all released work lives.
  • Create temporary feature branches where new development takes place.
  • When changes are ready for review, open a PR and discuss them.
  • When changes are approved, merge feature branch into master and delete feature branch.
  1. Git Flow: (for complex and robust workflow)
  • Relies on long-lived branches.
  • Simultaneously developing new features while supporting current releases.
  • 2 Primary branches: master and develop.
  • master branch always reflects production-ready state of the software.
  • develop branch reflects latest development for the next release.
  • Temporary Supporting branches for other purposes: feature, release, hotfix
  • feature branches work like in Github Flow.
  • release branches help you prepare the work on develop, that will be included in the next release version.
  • hotfix branches let you make critical changes to the master branch without impeding work on develop or the next release.
  • Process:
    • Developers create feature branches off of the develop branch and merge them back into develop when features are ready.
    • When it is time to make a new production release you'll make a decision about which new features will be included in it.
    • At that point in the develop branch, you start a release branch.
    • This allows work to continue on develop without disrupting the preparations for releasing the new features to production.
    • You may find that there are a few bugs to fix before releasing.
    • It's ok to add the work to the release branch. Avoid adding new big features to existing release branch.
    • When the release is ready, merge the release branch into master and tag it with a version number.
    • Github recognizes tags in your project and lets you easily create releases from them.
    • Now, all of the work that you merged into develop, prior to the release branch, is available in production as part of the newest release.
    • You can safely merge any bug fixes in the release branch back into develop and then delete the release branch.
    • Suppose a critical bug arises in production, you can create a hotfix branch off of master to address the bug immediately while planned work continues on develop.
    • When the bug is fixed you can merge the hotfix branch into master, tag the work and create a new release.
    • You'll also want to merge the hotfix branch back into develop or to the next release branch if one currently exists.