Hello, Git-Curious People 🙂 My final contribution to this topic, at least for today. I asked Google's Gemini Flash 2.5 how to utilize this workflow for 1 coordinator AI and 12 worker AI. (Currently I am experimenting with Google's powerfull Gemini API and Gemini CLI + Gitea + PostGreSQL + (optionally MailEnable) to run 1 coordinate AI and 12 worker AI in parallel to convert a GO (golang) project to Delphi (Delphi/pascal). The code is from ViteLabs vite blockchain. I would like to analyze/understand/evaluate both projects, the conversion attempt and the blockchain itself, for the blockchain for me it's easier to understand Delphi code, and it frees me from having to learn GO code and I don't quite like it's syntax and non-object orientation after doing at least 30 years of Object Pascal/Turbo Pascal/Delph, I hope you understand ;) I also dream of extending this project beyond it's current capabilities or a least bring back some wallet/gui functionality and especially a distributed exchange, which unfortunately went down, also to make my vite coins valuable again or start a derivate blockchain and start new.) Anyway this software setup allows git to run in parallel on a single Windows 11 machine. The full hardware specification for this system/machine is here in case interested: https://www.skybuck.org/Hardware/SuperPC2023/Skybuck's%20SuperPC%20for%202023%20design%20version%2011%20final.txt This is a very powerfull and high quality machine/PC. Unfortunately the Windows 11 GUI (Graphical User Interfaces) leaves much to be desired. The nice thing though is that Microsoft Windows 11 seems to almost run anything that I throw at it. Unfortunately Microsoft Visual Studio 2022 as usual is the exception LOL (though maybe just github specific project source code bugs when needing to build from source ? hmmm). Anyway Gemini is an incredibly powerfull Artificial Intelligence. Running 13 processes is barely scratching the capabilities of this local PC. Interestingly enough this combines it with the power of Google's Data Center and thus it conserves logic energy and dust accumilation and overheat risks. Best of all, Gemini API/Gemini CLI is completely free, and 12 Gemini API keys can be acquired for a single google account. As far as I know Google allows 2 accounts per telephone number or maybe just 1 ? In case you have not heard yet, or seen the capabilities of this Gemini AI, I can highly recommend it, it has a HUGE context window of 1 million tokens, which is very important for it's context/memory/brain/capabilities, I considered leading edge right now. It's also very fast, this nice big fast context window, plus it's speed makes it suited for large "system prompt". For example the "partial system prompt" below will be peanuts for Google Gemini AI: Fortunately and amazingly enough Gemini seems to understand this workflow and seems to know how to utilize it. I almost can't wait to try it out. However this will ofcourse require functioning scripts. Plus it needs a communication system. I do have one in place, but it's tailored for Windows 11, not Linux/Bash/MingW etc. But maybe I and the AI can pull out a miracle and somehow get it ported/working in linux/mingw/git bash as well, maybe through the help of free pascal or kylix, both for linux. I am not sure if git bash on windows can execute windows 11 executables, I think so, or maybe linux executables... I think it's windows based not sure... and my communication tool/exe would need to communicate with PostGreSQL database running locally as well, not sure if git bash can do this... Maybe "firewalled ?" probably not... So in case I have to use git bash the complexity rises further... Anyway for what it is worth I share the adoption of this workflow, suited for a GEMINI.md which is a system prompt. Please take note GEMINI.md can be split into multiple files, even folders, can be loaded with @file I believe, I will try this out tomorrow, so still lots of work to do, to make this a reality. Anyway it's interesting to see how the AI believes this workflow and these commands should be used together with existing GIT commands, I believe it will definetly help humans/users to understand/and/or formulate their own system prompts/adopted workflows if so desired. Consider this an example of how to use this new (?) work flow: Here is the content of the "Skybuck Git Workflow" document, presented in plain text Markdown for easy copy-pasting into your web browser, and then again as a Markdown immersive for your local `gemini.md` file. ````markdown # The Skybuck Git Workflow: Permanent History & Controlled Evolution This document outlines the "Skybuck Git Workflow," a robust version control strategy designed for our team to ensure complete historical traceability, clear project status, and efficient collaboration. It leverages Git's power while addressing common challenges like lost history and branch sprawl. ### 1. Core Principles This workflow is built on the following foundational ideas: * **History is Sacred & Permanent:** Once a commit or branch is pushed, it remains in the repository forever. We explicitly **never delete core contribution branches**, eliminating the risk of accidental data loss. * **Explicit Branch Status:** We use lightweight Git tags to clearly denote the lifecycle stage of each contribution branch (`active`, `merged`, `rejected`). No more guessing a branch's purpose! * **Personal Developer Continuity:** Each developer maintains their own sequentially numbered "contribution" branches (`UserPrefixContributionNNN-Description`), providing a clear, personal history of their work, regardless of `master`'s evolution. * **Intentional Development:** Every new coding session or task starts with a new, incremented version, clearly defining its objective. * **"Time-Travel" Capabilities:** The workflow allows us to easily revisit past code to fix/examine bugs, understand historical implementations, explore "what-if" scenarios, or even salvage previous work. * **Controlled Integration:** `master` remains the authoritative, stable branch. New work ideally branches from the latest `master` for smoother integration. --- ### 2. Team Roles & Responsibilities This workflow clearly defines responsibilities for the **Coordinator** and **Workers**: * **Coordinator (1): AIMain** * Manages the `master` branch. * Reviews Pull Requests (PRs). * Uses `git set-merged` after a successful merge to `master`. * Uses `git set-rejected` for work that will not be integrated. * Ensures overall workflow adherence and repository health. * **Workers (12): AI0001 to AI0012** * Initiate new development using `git new-contribution`. * Develop features/fixes on their personal contribution branches. * Use `git the-future` to keep their branches updated with `master` (rebasing). * Submit Pull Requests for review. * May use `git set-revive` or `git back-to` for specific historical work. --- ### 3. Branching Strategy * **`master` Branch:** * The single, authoritative main branch representing the stable, production-ready state of the project. * All new development branches should ideally originate from the latest `master`. * Only `merged` contribution branches are integrated into `master`. * **`UserPrefixContributionNNN-Description` Branches:** * These are the primary development branches for individual contributors (e.g., `SkybuckContribution001-ImplementLogin`, `AI0001Contribution002-RefactorDatabase`). * The `NNN` (e.g., `001`, `002`) provides a clear personal sequence of contributions for the developer. * **These branches are never deleted from the remote.** --- ### 4. Branch Lifecycle & Status Tags Instead of deleting branches, we use tags to denote their status. These tags are pushed to the remote for global visibility. * **`active/<branchname>`:** Indicates a branch is currently under development, active review, or active re-evaluation. * **`merged/<branchname>`:** Indicates a branch has been successfully integrated (merged) into the `master` branch. The branch itself persists, but this tag marks its completion and successful integration. * **`rejected/<branchname>`:** Indicates a branch was reviewed but will not be merged into `master` (e.g., due to design decision, incompleteness, or being superseded). The branch itself persists, but this tag marks its final non-integrated status. --- ### 5. Custom Git Commands (Implemented as Bash Scripts) These commands encapsulate the workflow logic, providing a high-level, safe, and intuitive interface. They are implemented as Bash scripts (e.g., `git-new-contribution`) and are accessible via `git <command-name>` (e.g., `git new-contribution`). #### 5.1. `git new-contribution <UserPrefix> <Description/Goal>` * **Purpose:** To initiate a brand new development effort from the latest `master`. This is the **primary command for workers to start most new features or fixes.** * **Role in Workflow:** Worker initiates new work. * **Action (Brief):** Fetches `master`, determines next sequential number for `<UserPrefix>`, creates `UserPrefixContributionNNN-Description` from `master`, pushes it, and automatically sets it `active/`. * **Example Usage:** `git new-contribution Skybuck "User profile management"` #### 5.2. `git set-active <branchname>` * **Purpose:** To explicitly mark an existing contribution branch as currently active or in progress. Primarily used by the scripts themselves, but can be manually invoked. * **Role in Workflow:** Status management. * **Action (Brief):** Removes any `merged/` or `rejected/` tags, creates/updates an `active/branchname` tag. * **Example Usage:** `git set-active SkybuckContribution003-ImplementFeatureX` #### 5.3. `git set-merged <branchname>` * **Purpose:** To mark a contribution branch as successfully merged into `master`. * **Role in Workflow:** **Coordinator's action** after a successful Pull Request merge. * **Action (Brief):** Removes `active/` or `rejected/` tags, creates a `merged/branchname` tag. * **Example Usage:** `git set-merged SkybuckContribution003-FeatureX` #### 5.4. `git set-rejected <branchname>` * **Purpose:** To mark a contribution branch as not being integrated into `master`. * **Role in Workflow:** **Coordinator's action** for rejected work. * **Action (Brief):** Removes `active/` or `merged/` tags, creates a `rejected/branchname` tag. * **Example Usage:** `git set-rejected AI0001Contribution002-ExperimentalAlgorithm` #### 5.5. `git set-revive <branchname>` * **Purpose:** To "re-activate" an *existing* `merged/` or `rejected/` contribution branch for continuation *in its original historical context*. * **Role in Workflow:** Worker's tool for resuming work on an old, specific branch version. * **Action (Brief):** Removes `merged/` or `rejected/` tags, and sets the branch `active/`. * **Important Note:** This does **NOT** rebase the branch onto `master`. The branch will remain based on its original ancestor, potentially diverging from the current `master`. Integration of subsequent work would be handled manually. * **Example Usage:** `git set-revive SkybuckContribution005-BugfixRethink` ### 6. The "Back to the Future" Combo: `git back-to` and `git the-future` This is a powerful two-command sequence designed for bringing historical code (from an old tag) forward to align with, or be evaluated against, the current state of the `master` branch. It separates the act of creating a branch from old code, from the potentially interactive process of modernizing it. Think of it as your personal DeLorean for code! #### 6.1. **Stage 1: `git back-to <tagname_of_old_commit> <new_branch_description>`** * **Purpose:** This is your initial "time-travel" command. Its job is to create a **brand new, clean development branch** that starts *exactly* at the historical commit pointed to by your chosen tag. It isolates this old code, giving you a fresh workspace. * **Role in Workflow:** Worker's tool for starting new work from a specific historical snapshot. * **Action (Brief):** Generates a new `UserPrefixContributionNNN-Description` name, creates the new branch at `<tagname>`, pushes it, and sets it `active/`. * **Example Usage:** `git back-to merged/AI0001Contribution007-OldAPIDesign "Re-evaluate V1 API for performance"` ```bash # This creates branch AI0001Contribution008-Re-evaluateV1APIForPerformance, # and sets it active. You are now working on code from that old point in time. ``` * **Important Note (Initial State):** The new branch created by `git back-to` is *not* automatically updated with the current `master` branch's changes. It's truly a snapshot of the past. #### 6.2. **Stage 2: `git the-future` (or `git the-future-rebase`)** * **Purpose:** This command is the "modernization" step. Once you're on a branch (often one created by `git back-to`) that you want to bring up to date with the latest `master`, `git the-future` initiates the rebase process. * **Role in Workflow:** Worker's tool for updating a branch's base to the latest `master`. * **Action (Brief):** Ensures `master` is up-to-date, executes `git rebase master`, and **crucially guides the user through conflict resolution** (prompting for `git add .` and `git rebase --continue`). * **Example Usage:** (After creating and switching to `AI0001Contribution008-Re-evaluateV1APIForPerformance`) `git the-future` ```bash # Git will now walk you through any conflicts as it replays your commits on top of master. # Once done, you'd push your changes and propose a merge request to master. ``` ### 7. Typical Workflow Scenarios Here's how common development tasks fit into the Skybuck Git Workflow: * **Starting a New Feature (Worker):** 1. `git new-contribution <YourPrefix> "Brief description of feature"` 2. Develop code, commit regularly. 3. Push your branch regularly: `git push` * **Keeping Your Feature Branch Updated (Worker - Optional/Periodic)::** 1. `git checkout <your-feature-branch>` 2. `git the-future` (Resolve any conflicts as prompted) 3. Push your rebased branch: `git push --force-with-lease` * **Submitting for Review (Worker):** 1. Ensure your branch is up-to-date with `master` (using `git the-future`). 2. Create a Pull Request from your `UserPrefixContributionNNN-Description` branch to `master`. * **Feature Accepted & Merged (Coordinator):** 1. Merge the Pull Request into `master` (via Git hosting platform or `git merge`). 2. Run: `git set-merged <merged-branch-name>` * This removes `active/` tag, adds `merged/` tag. The branch remains forever. * **Feature Rejected (Coordinator):** 1. Run: `git set-rejected <rejected-branch-name>` * This removes `active/` tag, adds `rejected/` tag. The branch remains forever for historical reference. * **Revisiting Old Work (Isolated Exploration - Worker):** 1. `git back-to <tagname_of_old_commit> "New description for this exploration"` 2. Develop and experiment on the new branch. This branch is isolated from current `master`. * **Revisiting Old Work (for Potential Integration - Worker):** 1. `git back-to <tagname_of_old_commit> "New description for integration attempt"` 2. Make necessary changes/fixes on the new branch. 3. `git the-future` (to rebase onto current `master` and resolve conflicts). 4. Push and submit a new Pull Request. ### 8. Benefits of this Workflow * **True Historical Integrity:** Every development path is preserved, providing a complete audit trail. * **Eliminates Data Loss Fear:** No more accidental deletions of valuable work. * **Clear Repository State:** Tags provide an at-a-glance understanding of each branch's status. * **Empowered Developers:** Each worker has a clear, sequential record of their contributions, fostering ownership and traceability. * **Streamlined Operations:** Custom commands abstract complex Git operations into safer, more intuitive steps. * **Improved Debugging:** Easily jump back to any tagged state to debug issues in their original context. ### 9. Setup & Prerequisites To use this workflow, ensure you have Git installed and: 1. **Create a scripts directory:** `mkdir -p ~/git-commands` 2. **Save each custom command script** (e.g., `git-new-contribution`, `git-set-active`, etc.) into this directory, ensuring they are named without `.sh` extensions. 3. **Make scripts executable:** `chmod +x ~/git-commands/git-*` 4. **Add to PATH:** Add `export PATH="$PATH:$HOME/git-commands"` to your shell's configuration file (`~/.bashrc` or `~/.profile` for Git Bash on Windows) and restart your terminal. 5. **Configure Git User Prefix:** `git config --global user.contributionPrefix "YourPrefix"` (e.g., "Skybuck", "AI0001", "JohnDoe"). This is used for your personal branch naming. ```` Bye for now, Skybuck Flying skybuck2000@xxxxxxxxxxx
