GIT solo flow-work & Xojo

Hi there Xojoers!

I read a message in Xojo forum about GIT clients and discovered Tower and found a nice collection of GIT video tutorials that emphasizes the convenience of using Branches for almost every commit you do.

I have stablished master as my production code, develop for my HEAD branch, and branching from here to features, bug fixes and experiments.

But these methodologies have been designed with a multiple-team factor in mind, and I wonder if some of you are following a different path for solo or 1-5 developers teams.

I will appreciate your suggestions!

Amando

It sounds like you’re using git-flow, and that’s how I do it for solo development too.

If you’re not using git-flow, look into it. It’s supported by Tower and automates a lot of steps for you.

Thanks Kem. Yeah, I am using git-flow approach.

In fact, thanks to Tower I learnt more about GIT than even before. My question now is about feature branches. Let’s say I have an XML feature I have in my 1.0 versin and would like to extend in versin 1.2 when I have more time to develop outputs. In this course I did not understood wether features should be deleted once merged or kept for the whole life of the project.

------> XML ----------------------------------------------> ( 1.1 )--------------------------->(1.2)–>
(develop) ------------------ > (1.0) -------------------------> (1.1) ------------> (1.2) -------- >
(master) ------------------- > (1.0 ) ------------------------------------>(1.1)---------------------->

I still don’t understand if this is correct and how to manage this.

I delete them. Remember, the history of a branch is merged into the trunk too and you can always return to a particular commit later. But if you keep that branch around long enough, you will either have to repeatedly update it with changes to develop or risk dealing with lots of merge conflicts later.

Be sure to take advantage of tags too to mark commits where a particular change happened or the last place a file existed.

Here’s a tip: You can create “folders” by prefixing a label, like that of tag, like this: name/subfolder1/subfolder2/…/label

git-flow is certainly the way to go for solo or team development. Say you are going to add a new feature. You branch from develop into your feature branch. The feature may take 1 hour or 2 weeks to complete. Let’s say it takes on the longer side, 1 week. You’ve been working on it for 3 days now, and that is 45 commits later when an important bug report comes in that needs fixed ASAP. You decide that you’ve already fixed 4 other bugs and added 2 other features, so you’ll do another release. So, you simply start a new feature to fix that bug. Fix the bug, complete the bug feature and do a new release.

Imagine if, on the other hand, you had 2 branches. Your feature is 45 commits into the develop branch, but you’re still 3 days away. Now what do you do? There are certainly ways of handling it, but nothing as clean as the git-flow methodology.

git-flow may seem like a bit more work to begin with, but I believe after a few features, hot fixes and releases you’ll appreciate it quite a bit. git-flow isn’t necessarily a work-flow to handle multiple developers, it’s a work-flow to handle features, bug fixes and releases… of which solo and multi teams have to deal with.

Thank you Kem and Jeremy for your advice. I see the great advantage of git-flow now!! :slight_smile: