encrypting script-only stacks

[Richard Gaskin]

Thanks, Trevor.  That's a helpful outline.

I haven't had a business case to support so many branches, but I can see 
where it might be useful down the road.

Any opinions on Github vs Gitlab?

-- 
  Richard Gaskin
  Fourth World Systems


Trevor DeVore wrote:
> On Tue, Jan 14, 2020 at 11:47 AM Richard Gaskin via use-livecode <
> use-livecode at lists.runrev.com> wrote:
> 
>> ...
>>
>> Help me motivate to move my Git transition forward sooner:
>>
>> Beyond backup across versions (since that's widely available in most
>> cloud storage for even binary files), that Git features do you find most
>> valuable?
>>
> 
> Hi Richard -
> 
> One way I use Git is to develop multiple features in tandem without
> affecting the version I distribute of my app that I distribute to
> customers. I love how I can silo my own work on features as well as the
> flexibility to see detailed history of changes throughout the life of my
> application. I use the Git commit notes and the ease with which you can
> review changes in those commits a number of times when trying to track down
> at what point a bug was introduced.
> 
> Here is an example of how I silo work I'm doing right now. If you looked at
> my Git repo earlier today you would see the following branches:
> 
> - master
> - develop
> - tkd-htmltidy
> - tkd-remove-answer-types
> - tkd-mammoth
> - tkd-hires-annotations
> 
> `master` always has the release version of the code.
> 
> `develop` is code that has been developed, tested, and is ready to go into
> the next release. I will create builds from this branch to send to
> customers who want early access to a feature or bug fix.
> 
> All other branches are features that are being worked on but which are not
> finished and require more testing. Some of those branches exist for an
> afternoon. Some last for a month or more.
> 
> Today I merged in `tkd-htmltidy` and tkd-remove-answer-types` into
> `develop` as they were finished and are ready to send to customers who need
> early access. When I squashed and merged those branches in there were a
> number of changes which had been made in the develop branch since I had
> started `tkd-htmltidy`. Those changes were seamless blended together
> without any problem, even though there were changes changes made in some of
> the same files. In addition, because I squashed the merge, all of the
> changes that went into the addition of HTML Tidy are seen as one commit in
> my `develop` branch. I made dozens of commits during development but was
> able to make one clean commit when I was all done and ready to merge the
> changes with the main code branch. This makes for a clean history that is
> easier to review later on.
> 
> I will continue to work on the tkd-hires-annotations and tkd-mammoth
> branches as they aren't done yet and require more revisions. But once they
> are ready I perform the same squash and merge. If I want an internal tester
> or a customer to test those features out before they are ready I can do
> that too. I can use the Git rebase feature to bring in all changes to
> `develop` that have been made since I created a particular branch. That
> means the tester is using the latest version of the app along with the new
> feature I'm working on.
> 
> One last example. Let's say that a nasty bug turns up while I'm working on
> `develop` and need to get a release out to customers right away. I can go
> to master, create a new branch from that code, make the fix, and package up
> a new installer. I can merge that fix into `develop` as well so that it
> will be included in a future update.
> 
> I think the scenarios I describe above are my favorite reasons for using
> Git as they make my daily development and management of the code easier.
> 
> -- 
> Trevor DeVore
> ScreenSteps
> www.screensteps.com