encrypting script-only stacks

[Trevor DeVore]

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