| DECLARE @SharedFieldId UniqueIdentifier = '{BE351A73-FCB0-4213-93FA-C302D8AB4F51}' /* Shared checkbox */ | |
| DECLARE @UnversionedFieldId UniqueIdentifier = '{39847666-389D-409B-95BD-F2016F11EED5}' /* unversioned checkbox */ | |
| DECLARE @TemplateFieldId UniqueIdentifier = '{455A3E98-A627-4B40-8035-E683A0331AC7}' /* Template field */ | |
| -- Find all templates WHERE both "Unversioned" AND "Shared" is selected: | |
| -- "Shared" will have precedense, so the "Unversioned" checkbox can be removed | |
| SELECT * FROM SharedFields | |
| WHERE FieldId=@UnversionedFieldId AND [Value] = '1' | |
| AND ItemId IN (SELECT ItemId FROM SharedFields WHERE FieldId=@SharedFieldId AND [Value]='1') |
I've been asked a few times over the last few months to put together a full write-up of the Git workflow we use at RichRelevance (and at Precog before), since I have referenced it in passing quite a few times in tweets and in person. The workflow is appreciably different from GitFlow and its derivatives, and thus it brings with it a different set of tradeoffs and optimizations. To that end, it would probably be helpful to go over exactly what workflow benefits I find to be beneficial or even necessary.
- Two developers working on independent features must never be blocked by each other
- No code freeze! Ever! For any reason!
- A developer must be able to base derivative work on another developer's work, without waiting for any third party
- Two developers working on inter-dependent features (or even the same feature) must be able to do so without interference from (or interfering with) any other parties
- Developers must be able to work on multiple features simultaneously, or at lea
Whether you're trying to give back to the open source community or collaborating on your own projects, knowing how to properly fork and generate pull requests is essential. Unfortunately, it's quite easy to make mistakes or not know what you should do when you're initially learning the process. I know that I certainly had considerable initial trouble with it, and I found a lot of the information on GitHub and around the internet to be rather piecemeal and incomplete - part of the process described here, another there, common hangups in a different place, and so on.
In an attempt to coallate this information for myself and others, this short tutorial is what I've found to be fairly standard procedure for creating a fork, doing your work, issuing a pull request, and merging that pull request back into the original project.
Just head over to the GitHub page and click the "Fork" button. It's just that simple. Once you've done that, you can use your favorite git client to clone your repo or j