OT: You can check out the following for some standard git workflows.
http://nvie.com/posts/a-successful-git-branching-model/
https://www.atlassian.com/git/workflows
My teams uses a combination of gitflow and pull requests. We maintain a
central repo with gitflow standards with one modification. W
Nov 21, 2013 at 11:38 AM, Darrel O'Pry wrote:
>
>>
>> vagrant up dev
>> vagrant up ubuntu12.10-admin
>> vagrant up bare-node1
>> vagrant up bare-node2
>> vagrant up bare-node3
>> vagrant up bare-node4
>>
>> Which could all be wrapped up
On Thu, Nov 21, 2013 at 6:45 AM, Adam Spiers wrote:
> Darrel O'Pry (darrel.o...@gmail.com) wrote:
>
> > I hear a lot of knee jerk throw everything out and start over
> undertones. I
> > don't that that is a wise idea as it loses history. One of the things I
>
Move docs into the repo and version with the code.
On Wed, Nov 20, 2013 at 7:24 PM, wrote:
> How do we address that CB1 and 2 are so different that the docs can't
> cover both? This seems very confusing to me.
>
> If cleanup was simple, why don't we do it?
>
> FWIW, I'm adding BDD tests that c
>From the peanut gallery...
The project has come along way since I first started following it a few
years ago. What is there now is a vast improvement over what I first found
which were the links to Rob's blog. It has been steady forward progress. I
hear a lot of knee jerk throw everything out and
I have to second James here. I just came off a project where they insisted
on keeping historic stuff in the repo. It only served to confuse people
coming onboard who weren't already familiar with the project. Its really
easy to make a branch in you own repository and switch back to it or view
it o
