search

kippdata / silo

A silo is "a deep bin for storing material" as is KIPP Silo. KIPP Silo is the KIPP Network's Self-organized, Iterative, Late-binding (or Lightweight), and Open-source (for now) data warehouse solution.
GNU General Public License v3.0
4 stars 1 forks source link

Forking vs Branching #1

Open chrishaid opened 10 years ago

chrishaid commented 10 years ago

@almostsurely and @almartin82 Thoughts on: branching vs forking for Silo?

Ideally, I think forking is best, but, I worry that the couple extra steps of overhead (pull requests, git fetch upstream, git merge upstream/master) may be a bit confusing for less experienced folks.

thinkcodemake commented 10 years ago

After reading over the links you've posted, I feel that since we are heading towards a more centralized solution at the moment, we should stick with branching. If a region needs to do a major overhaul to the codebase for their specific needs, I definitely think a fork would be in order.

So I guess I would say go with a blend of the two. For projects and changes that would affect multiple users that should be integrated into the whole system, we branch. If a region is working on a region specific need that might not be beneficial overall for now, we fork.

chrishaid commented 10 years ago

I think that makes sense. Scott Chacun has a nice blog post on how github uses github. The tl;dr (with some translation) is:

  1. Anything in the master branch is deployable, i.e., don't break the master branch with your committed code as it could be deployed at a moments notice. This is a huge issue where deployment = push to production server, but should serve us well. Eventually our ideal state should be that any region at any time could pull our master branch, update their local configuration files, and deploy Silo.
  2. To work on something new, create a descriptively named branch off of master (ie: new-oauth2-scopes), i.e., all new development/coding/etc. needs to be done on a branch (git checkout -b new-oauth2-scopes).
  3. Commit to that branch locally and regularly push your work to the same named branch on the server.
  4. When you need feedback or help, or you think the branch is ready for merging, open a pull request, i.e., you must have someone else sign off on your code before it can be merged with the master branch.
  5. After someone else has reviewed and signed off on the feature, you can merge it into master, i.e., what I just said.

This all makes sense right? It should keep the overhead for newbies low and allow them to understand the basic concept of developing on branches. Plus this workflow works both form the command line and from the gui client apps github has developed.

thinkcodemake commented 10 years ago

It looks good to me.

chrishaid commented 10 years ago

If @almartin82 doesn't comment on this, I'm gonna close this issue and we'll go the rough Scott Chacun route.

c