The files on GitHub and your workstation should be pretty much the same. Like Trevor was saying, you would have a develop branch that contained your in progress code. The master branch would be the release. Every beta could be a commit in the dev branch. When ready for a final release, the code is merged up to master. On Thu, Jan 25, 2018 at 1:54 PM Geoff Canyon via use-livecode < use-livecode@lists.runrev.com> wrote:
> Any suggestions where to go to figure this out? At the most basic level, > all I need is: > > 1. A "current released version" of Navigator on GitHub. > 2. A work-in-progress version on my computer, in my LiveCode installation. > 3. The ability to merge my copy into the GitHub version. > > And obviously, have multiple dev versions, release versions, etc., but for > now I just need dev and release, and even that seems beyond the ability of > any web page to explain simply. Nothing I've read seems to even come close > to explaining how to do that. Or am I just completely misunderstanding how > git works? Even basic tutorials seem to start with literally no description > of what the actual workflow of git is, and simply dive into various git > commands using undefined terminology. <grrr> > > On Thu, Jan 25, 2018 at 5:40 AM, Trevor DeVore via use-livecode < > use-livecode@lists.runrev.com> wrote: > > > On Thu, Jan 25, 2018 at 3:36 AM Geoff Canyon via use-livecode < > > use-livecode@lists.runrev.com> wrote: > > > > > > > > I have a fix coded, but I'm in the middle of another update, so I will > > > update the whole thing tomorrow morning. (This is the sort of thing > > GitHub > > > is supposed to be good for, right? Heh -- need to figure that out...) > > > > > > A couple of quick tips. Some of the vocabulary may be new. Just google > each > > concept and you will find lots of info. Git is really confusing at first > > and then one day it isn’t and you wonder how you ever lived without it. > > > > Look into branching. A simple approach for an individual is that your > > master branch has the stable version of your app. You work on each > feature > > in a separate branch that you then merge into master when it is ready. > > > > Whenever you want to make a new public release of your app tag the commit > > in master that has the release version. This allows you to easily check > out > > a branch with that exact version of your app if you need to in the > future. > > > > If you want to keep your master branch clean when merging other branches > in > > (not too many commits) look into interactive rebasing. Interactive > rebasing > > can be used to squash a bunch of commits in a branch down to one (or > more). > > That way when you merge a feature branch into master it only appears as > one > > commit, even if you made 30 commits while working on the feature. > > > > Trevor DeVore > > ScreenSteps > > > > > > > _______________________________________________ > > 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 > > > _______________________________________________ > 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 _______________________________________________ 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
