I’ve attempted to try git a couple times before. Looking into it again I’m on the fence, tentative but tempted.
cons:
- I don’t like to install things. Should be like Xojo, put an app somewhere and launch it.
- It feels like there’s some tethered link/reference/path that needs to be maintained. I move things around and have been bitten by external references breaking, like a quicktime movie that can’t find it’s external resources and I can’t locate them either or put them in the right place. When possible I work with self contained things (to know where and account for all the necessary data) and I’m not quite clear yet how to do that with git.
- There’s some other cons that fall into the above category, things I want to do, probably can, it’s just a problem of learning.
pros:
- Built in diff.
- Makes branching easier. With sequence versioning tags this gets clumsy.
- Publishing to github might increase feedback and development of my open source code.
To figure out my uncertainties I’ve mapped out a usage scenerio…
Create asteriods project.
Develop it a bit and approach a first stable something that I want to store and begin on a second stage.
Using binary project sequences here I’d Save-As a new project file with an incremented version number, yielding 2 projects and I always work on the latest.
With git I think I’d create a new repository and checkin or commit or otherwise store an initial project.
Then I’d continue working in the single, original VCP project and when it nears completion of the second stage I’d commit/store that to the git repository and again return to working on my single VCP project.
After several of these stores and having a complex project I might want to make a copy to mess around with and experiment. I’m guessing with git I point to one of those previous stores and tell it to export that as a different branch, then I’ll have 2 VCP projects.
I’m not clear how VCP projects are tied into the repository/branch. Is it by name? How do I not accidentally commit a VCP project to the wrong branch?
After a few iterations experimenting in the branch a polished class and other tid-bits are ready to be incorporated back into the master project.
Using binary project sequences I’d save a new master version and manually copy in just those completed items.
With git there’s a merge operation but I’m not sure that’s right. I only want to merge back select parts to select places. I could always manually copy into the master then commit that, but then I lose the branch tracking abilities of the network graph
https://github.com/macoslib/macoslib/network
They’re all doing it though so I guess I just need to understand merging better.
Once a branch is done I don’t really need it anymore. With binary projects I’d zip up that sequence (or not). With git I could delete that branch’s VCP project and rely on the repository to store it, exporting back out a VCP project if ever needed again. Relying is the key word, I don’t like data being held only in some mystery place. Well, I could always keep a copy outside.
The only other common usage scenerio is starting a new project just to develop a component for the main app. Technically it’s not part of the main app but I’ll save it’s binary project sequence in the same folder because they’re related. It’d be nice to do similar in git, a single repository but with seperate starting tracks. Probably doable.
Mapping this out I think I’m beginning to get it. Like when I was learning about interfaces and suddenly OOP clicked in clear and concrete. Plus that network graph view is something I’d really like to have.
