On Tue, Jan 14, 2020 at 11:47 AM Richard Gaskin via use-livecode < use-livecode@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 _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
