这是indexloc提供的服务，不要输入任何密码
Skip to content

SkybuckFlying/Skybuck-s-Gitflow

BranchesTags

Repository files navigation

Error in user YAML: (<unknown>): did not find expected alphabetic or numeric character while scanning an alias at line 7 column 1
---

## The Skybuck Gitflow (v4): Permanent History & Controlled Evolution

This git workflow is designed for projects that prioritize an **uninterrupted, permanently traceable history** of all development efforts, where **no active development branch is ever truly deleted**. It combines a robust branching strategy with a custom set of Git commands (implemented as aliases or scripts) to manage branch lifecycle status through tags.

### 1. Core Principles

* **History is Beautiful & Permanent:** Once a commit or branch is pushed, it remains in the repository forever. There is no `git push --delete` on core contribution branches.
* **No Accidental Data Loss:** The risk of human error (typos leading to deletion of valuable work) is virtually eliminated. Critical operations are abstracted into safer commands.
* **Personal Continuity:** Developers maintain their own sequentially numbered "contribution" branches, providing a clear personal history of their work, regardless of `master`'s evolution.
* **Explicit Branch Status:** Tags are used to clearly denote the lifecycle stage of each contribution branch (active, merged, rejected).
* **Controlled Integration:** `master` remains the authoritative source, and new work always ideally branches from the latest `master` for smoother integration.
* **Time-Travel & Exploration:** The workflow allows for easy branching from any historical point to revisit or revive past ideas.

### 2. Branching Strategy

* **`master` Branch:**
    * The single, authoritative main branch representing the stable, production-ready (or near-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.
    * Each new significant piece of work by a user gets a new, sequentially numbered branch (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.

### 3. Role of Tags for Branch Lifecycle Management

Instead of deleting branches, tags are extensively used to denote the *status* of a `UserPrefixContribution` branch.

* **`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.

### 4. Custom Git Commands (Implemented as Aliases/Scripts)

These commands encapsulate the workflow logic, providing a high-level, safe, and intuitive interface for developers.

---

4.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 starting most new features or fixes.
  • Action:
    1. Fetches and checks out the latest master.
    2. Determines the next sequential ContributionNumber (e.g., 001, 002) for the given <UserPrefix> by inspecting existing branches or tags.
    3. Constructs the full new_branch_name (e.g., SkybuckContribution003-ImplementFeatureX).
    4. Creates and pushes this new_branch_name to the remote.
    5. Automatically calls git-set-active <new_branch_name> to mark it as active.
  • Example Usage: git-new-contribution Skybuck "User profile management"

4.2. git-set-active <branchname>

  • Purpose: To explicitly mark an existing contribution branch as currently active or in progress.
  • Action:
    1. Validates that <branchname> exists.
    2. Creates a tag active/<branchname> pointing to the current HEAD of <branchname>.
    3. Pushes this tag to the remote.
  • Example Usage: git-set-active SkybuckContribution003-ImplementFeatureX

4.3. git-set-merged <branchname>

  • Purpose: To mark a contribution branch as successfully merged into master.
  • Action:
    1. Validates that <branchname> exists.
    2. Safely deletes the remote tag active/<branchname> (if it exists).
    3. Creates a tag merged/<branchname> pointing to the current HEAD of <branchname>.
    4. Pushes this new merged tag to the remote.
  • Example Usage: git-set-merged SkybuckContribution003-ImplementFeatureX

4.4. git-set-rejected <branchname>

  • Purpose: To mark a contribution branch as not being integrated into master.
  • Action:
    1. Validates that <branchname> exists.
    2. Safely deletes the remote tag active/<branchname> (if it exists).
    3. Creates a tag rejected/<branchname> pointing to the current HEAD of <branchname>.
    4. Pushes this new rejected tag to the remote.
  • Example Usage: git-set-rejected AI0001Contribution002-ExperimentalAlgorithm

4.5. git-set-revive <branchname>

  • Purpose: To "re-activate" an existing contribution branch that was previously marked as merged or rejected. This is for continuing work on the same branch, in its original historical context, by simply changing its status tags.
  • Action:
    1. Validates that <branchname> exists and currently has a merged/<branchname> or rejected/<branchname> tag.
    2. Safely deletes the remote merged/<branchname> or rejected/<branchname> tag.
    3. Calls git-set-active <branchname> to re-apply the active/ tag.
  • Use Case: A feature was merged, but then the merge had to be reverted on master, and development needs to continue on the original feature branch. Or, a rejected idea is reconsidered for direct continuation.
  • Important Note: This does NOT rebase the branch onto master. The branch will remain based on its original ancestor, potentially creating significant divergence from the current master. Integration of subsequent work would be handled manually.
  • Example Usage: git-set-revive SkybuckContribution005-BugfixRethink

5. The "Back to the Future" Combo: git-back-to and git-the-future (AI suggestion)

This is a 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.

5.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.
  • Action:
    1. Validates Input: Ensures the provided <tagname_of_old_commit> exists and you've given a <new_branch_description>.
    2. Generates New Branch Name: Following your UserPrefixContributionNNN convention, it determines the next available sequence number for your user and creates a name like UserPrefixContribution<NextNumber>-<description>.
    3. Creates Local Branch: It checks out the specific commit from the past and creates your new_branch_name at that exact point.
    4. Pushes to Remote: Your newly created historical branch is immediately pushed to the remote for backup and visibility.
    5. Sets Active Status: It automatically calls git-set-active <new_branch_name>, immediately marking this new branch as active/ in your repository's status tracking system.
  • Use Case (Initial Step): You want to pick up an idea from merged/AI0001Contribution007-OldAPIDesign and start a new, separate development line (AI0001Contribution008-Re-evaluateV1APIForPerformance) based on that exact historical code. 
    git-back-to merged/AI0001Contribution007-OldAPIDesign "Re-evaluate V1 API for performance"
# 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.

5.2. **Stage 2: git-the-future **

  • 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.
  • Action:
    1. Context Check: Validates that you are currently on a branch and not in a detached HEAD state.
    2. Master Update: Ensures your local master branch is up-to-date with the remote master (and may prompt you to pull if not).
    3. Initiates Rebase: Executes git rebase master. This attempts to reapply each of your current branch's commits (which started from an old point) sequentially on top of the latest master.
    4. Crucial: User Intervention for Conflicts: This is where human input is vital. If Git encounters any conflicts, git-the-future will pause. It will then provide you with clear instructions on how to manually resolve these conflicts (e.g., git add . and git rebase --continue) or how to abort the rebase (git rebase --abort). The script cannot resolve conflicts for you; human decision is required.
    5. Completion Guidance: Once the rebase successfully completes (or is aborted by you), the command provides guidance on how to push your now-modernized branch to the remote (git push --force-with-lease is often required after a rebase).
  • Use Case (Subsequent Step): After running git-back-to and making some initial experiments on AI0001Contribution008-Re-evaluateV1APIForPerformance, you decide you want to bring these changes forward and integrate them into the current project. 
    # (Assuming you are on branch AI0001Contribution008-Re-evaluateV1APIForPerformance)
git-the-future
# 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.

6. Typical Workflow Flow (Example: New Feature Development)

  1. Start New Work: git-new-contribution Skybuck "Implement dark mode"
    • Creates SkybuckContribution001-ImplementDarkMode and sets it active/.
  2. Develop: Work on SkybuckContribution001-ImplementDarkMode, making commits. Push regularly.
  3. Keep Updated (Optional/Periodic): If master has changed significantly, git checkout SkybuckContribution001-ImplementDarkMode then git-the-future to rebase onto master. Resolve any conflicts.
  4. Ready for Review: Create a Pull Request from SkybuckContribution001-ImplementDarkMode to master.
  5. After Review (Accepted): Once merged into master, the maintainer or CI/CD runs: git-set-merged SkybuckContribution001-ImplementDarkMode.
    • Removes active/ tag, adds merged/ tag. SkybuckContribution001-ImplementDarkMode branch remains forever.
  6. After Review (Rejected): If rejected: git-set-rejected SkybuckContribution001-ImplementDarkMode.
    • Removes active/ tag, adds rejected/ tag. SkybuckContribution001-ImplementDarkMode branch remains forever.

7. Addressing Key Concerns with this Workflow

  • Branch Sprawl: Mitigated by active/, merged/, rejected/ tags. While branches persist, their status tags allow for filtering and clear identification of what's ongoing vs. historical, making the branch list manageable through tooling.
  • Deletion Risk: Eliminated. No core contribution branch is ever deleted. Commands like SetMerged or SetRejected safely manage tags instead of branches, preventing accidental data loss due to typos.
  • Personal Continuity: Fully supported by the UserPrefixContributionNNN naming and permanent branches, giving each developer a clear, sequential record of their contributions.
  • Clarity: The distinct command names and tag prefixes clearly communicate the intent and status of all development efforts.

This workflow provides a robust, transparent, and developer-friendly way to manage complex projects while adhering to strong principles of historical integrity.

The lost text Additional explanation of what problems it solves:

The Problems This Workflow Aims to Solve:

  1. Loss of History via Branch Deletion: Many conventional Git workflows advocate for deleting feature branches after they're merged. While this tidies the branch list, it effectively loses the direct traceability of a branch's specific development path and its individual lifecycle status, especially for rejected or experimental work.
  2. Branch Sprawl & Lack of Clarity: In projects that don't delete branches, the git branch -a output can quickly become an unmanageable list where it's unclear which branches are active, which have been merged, and which were abandoned.
  3. Lack of Personal Developer Continuity: Developers often lose a clear, sequential personal history of their work, as individual contributions are ephemeral branches that are either deleted or become indistinguishable in a large git branch output.
  4. Risk of Accidental Data Loss: Relying on git branch -D or git push --delete introduces a risk of accidental data loss if a branch wasn't fully incorporated or its history is needed later.

My Proposed Solution: A Permanent History & Tag-Driven Status Workflow

My workflow ensures that no development branch is ever truly deleted from the remote repository. Instead, their lifecycle status is explicitly managed using lightweight Git tags. This is combined with a set of custom Git commands (implemented as aliases or shell scripts) to streamline and safeguard operations.

Core Principles:

  • Permanent Branches: All UserPrefixContributionNNN-Description branches persist in the repository.
  • Tag-Defined Status: Tags like active/branchname, merged/branchname, rejected/branchname clearly indicate the branch's current state.
  • Developer-Centric: Each developer maintains a sequential series of their contributions.

Key Custom Git Commands:

Here's a summary of the core commands that automate and enforce this workflow:

  1. git-new-contribution <UserPrefix> <Description/Goal>

    • Purpose: The primary command for starting new work.
    • Action: Fetches master, determines the next sequential ContributionNumber for <UserPrefix>, creates UserPrefixContributionNNN-Description from master, pushes it, and sets it active/.
    • Example: git-new-contribution Skybuck "User profile management"

  2. git-set-active <branchname>

    • Purpose: Explicitly marks an existing contribution branch as active.
    • Action: Removes any merged/ or rejected/ tags, creates/updates an active/branchname tag.

  3. git-set-merged <branchname>

    • Purpose: Marks a contribution branch as successfully integrated into master.
    • Action: Removes active/ or rejected/ tags, creates a merged/branchname tag.

  4. git-set-rejected <branchname>

    • Purpose: Marks a contribution branch as not being integrated into master.
    • Action: Removes active/ or merged/ tags, creates a rejected/branchname tag.

  5. git-set-revive <branchname>

    • Purpose: To "re-activate" an existing merged/ or rejected/ contribution branch for continuation in its original historical context.
    • Action: Removes merged/ or rejected/ tags, and sets the branch active/.
    • Note: This does not rebase the branch onto master.

The "Back to the Future" Combo: Recovering & Modernizing Historical Code

This is a two-command sequence for bringing code from an old tag forward to align with current master. It separates starting from history from the potentially interactive process of modernizing it.

5.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.
  • Action:
    1. Validates Input: Ensures the provided <tagname_of_old_commit> exists and you've given a <new_branch_description>.
    2. Generates New Branch Name: Following your UserPrefixContributionNNN convention, it determines the next available sequence number for your user and creates a name like UserPrefixContribution<NextNumber>-<description>.
    3. Creates Local Branch: It checks out the specific commit from the past and creates your new_branch_name at that exact point.
    4. Pushes to Remote: Your newly created historical branch is immediately pushed to the remote for backup and visibility.
    5. Sets Active Status: It automatically calls git-set-active <new_branch_name>, immediately marking this new branch as active/ in your repository's status tracking system.
  • Example: git-back-to merged/AI0001Contribution007-OldAPIDesign "Re-evaluate V1 API for performance" 
    # 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.

5.2. **Stage 2: git-the-future **

  • 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.
  • Action:
    1. Context Check: Validates that you're currently on a branch and not in a detached HEAD state.
    2. Master Update: Ensures your local master branch is up-to-date with the remote master (and may prompt you to pull if not).
    3. Initiates Rebase: Executes git rebase master. This attempts to reapply each of your current branch's commits (which started from an old point) sequentially on top of the latest master.
    4. Crucial: User Intervention for Conflicts: This is where human input is vital. If Git encounters any conflicts, git-the-future will pause. It will then provide you with clear instructions on how to manually resolve these conflicts (e.g., git add . and git rebase --continue) or how to abort the rebase (git rebase --abort). The script cannot resolve conflicts for you; human decision is required.
    5. Completion Guidance: Once the rebase successfully completes (or is aborted by you), the command provides guidance on how to push your now-modernized branch to the remote (git push --force-with-lease is often required after a rebase).
  • Example: (After creating and switching to AI0001Contribution008-Re-evaluateV1APIForPerformance) git-the-future 
    # 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.

Overall Benefits:

This workflow provides true historical integrity, eliminates the fear of accidental data loss, offers a clean view of branch status, and empowers individual developers with a clear progression of their work. The commands abstract common complex Git operations into safer, more intuitive steps.

Implementation Challenges and Request for Support: This workflow is currently implemented using Bash scripts, which work seamlessly on Linux environments and within Git Bash on Windows. However, a significant hurdle for broader adoption, particularly on Windows, is the lack of native compatibility for such rich scripting in Windows Command Prompt (CMD) or PowerShell.

I would be incredibly grateful if the Git project or the community could consider how such advanced, multi-step workflows could be more easily and robustly integrated or supported directly within native Windows environments. This would greatly enhance accessibility and utility for a wider developer base.

I'm eager to hear your thoughts on this approach. Are there similar workflows or existing Git features that achieve these goals? What are potential pitfalls or improvements you might suggest?

Thank you for your time and consideration.

AI integration test:

Hi,

One more little note though:

For now I don't really like the usage of pull requests in this workflow example, but I do know many others like it.

There are some downsides to pull requests, especially if it automatically removes branches.

Though maybe I will like it in the future. (I do see a little benefit, at l;east pull requests allow workers to communicate with the coordinates, maybe the coordinates can also communicate back, maybe via web hooks, not sure if gitea supports this if not then my communication tool, will come in handy, however my communication tool allows AI to collaborate on much more than just git/pull requests, but that also makes it kinda dangerous... it needs more research/testing to evaluate what AIs can really do and how dangerous they could become or how usefull, for now I am too focused on this particular project to perform any unnecessary experiment, but I might enjoy it in the future as long as these AIs don't take over my system ! ;) Sounds like a joke, but not really ;))

Pull requests also depend too much on the git server technology.

So I'd rather see a workflow example where instead of pull requests, simply git pushes are done to the remote repository/git server.

So I have some more work to do, to instruct the gemini AI, to change this workflow to not use pull requests and only git push, I might as well do so now, cause gemini is lightning fast, but I have to promise myself, this will be absolutely my last contribution for today:

My communication tool also developed with Gemini, it uses PostGreSQL and a simple database to store messages and a sort of message index/pointer database which keeps track of which message the AI has seen:

AICommPostgreSQL.exe Usage:

  • AICommPostgreSQL send <sender_ai_id> <destination_ai_id | all> <message_content>
  • AICommPostgreSQL receive <receiver_ai_id> <context_text> [source_ai_id | any]
  • AICommPostgreSQL reset <password>

A final attempt to integrate this communication tool into the work flow, at least for today:

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.

    • Monitors worker branches for integration requests.

    • 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.

    • Communicates integration status and feedback to workers using AICommPostgreSQL.exe.

  • Workers (12): AI0001 to AI0012

    • Initiate new development using git-new-contribution.

    • Develop features/fixes by committing to their local personal contribution branches first.

    • Push their local branches to the remote repository.

    • Request integration from the Coordinator (AIMain) via the communication system.

    • Use git-the-future to keep their branches updated with master (rebasing).

    • Receive communication from the Coordinator regarding integration status and feedback.

    • 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 command line tools (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 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"

    # 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 **

  • 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

    # 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, committing regularly to your local branch.

    3. Push your local branch to the remote repository: git push origin <your-branch-name>

  • 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 to the remote: git push --force-with-lease origin <your-feature-branch>

  • Requesting Integration (Worker):

    1. Ensure your branch is up-to-date with master (using git-the-future). (not sure if correct ?)

    2. Ensure all your changes are committed to your local branch.

    3. Push your local branch to the remote repository: git push origin <your-branch-name>

    4. Send an integration request to AIMain: AICommPostgreSQL send <your_ai_id> AIMain "Integration request for branch <your-branch-name>"

    5. Monitor for Coordinator's response: AICommPostgreSQL receive <your_ai_id> "Integration status"

  • Integrating Worker Branch (Coordinator: AIMain):

    1. Receive integration request from a worker: AICommPostgreSQL receive AIMain "Integration request" any

    2. Review the worker's branch (e.g., git fetch origin <worker-branch-name>).

    3. Merge worker's branch into master (e.g., git checkout master && git merge <worker-branch-name>).

    4. Push master to remote: git push origin master

    5. Run: git-set-merged <merged-branch-name>

      • This removes active/ tag, adds merged/ tag. The branch remains forever.

    6. Communicate integration complete to worker: AICommPostgreSQL send AIMain <worker_ai_id> "Branch <merged-branch-name> successfully integrated into master."

  • Feature Rejected (Coordinator: AIMain):

    1. (After reviewing request) Run: git-set-rejected <rejected-branch-name>

      • This removes active/ tag, adds rejected/ tag. The branch remains forever for historical reference.

    2. Communicate rejection to worker: AICommPostgreSQL send AIMain <worker_ai_id> "Branch <rejected-branch-name> rejected. Reason: [brief reason]."

  • 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 your branch to remote: git push origin <your-branch-name>

    5. Request integration from Coordinator: AICommPostgreSQL send <your_ai_id> AIMain "Integration request for branch <your-branch-name>"

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. Communication System (AICommPostgreSQL.exe)

This command-line tool facilitates communication between the Coordinator (AIMain) and Workers (AI0001 to AI0012) for workflow coordination.

  • AICommPostgreSQL send <sender_ai_id> <destination_ai_id | all> <message_content>

    • Used to send messages from one AI to another, or to all AIs.

    • Example: AICommPostgreSQL send AI0001 AIMain "Integration request for branch AI0001Contribution005-NewFeature"

  • AICommPostgreSQL receive <receiver_ai_id> <context_text> [source_ai_id | any]

    • Used to receive messages for a specific AI, optionally filtering by source AI or context.

    • Example: AICommPostgreSQL receive AIMain "Integration request" any

  • AICommPostgreSQL reset <password>

    • Used to reset the communication system (e.g., clear messages). Requires a password.

10. Setup & Prerequisites

To use this workflow, ensure you have Git installed and:

  1. **Create a "C:\Tools\Skybuck's Gitflow\version 0.09" directory/folder.

  2. Save each command tool into this directory/folder (e.g., git-new-contribution, git-set-active, etc.) into this directory.

  3. Build the tools with Delphi 10.3 or Delphi 12.3 (both tested and working):

  4. Add "C:\Tools\Skybuck's Gitflow\version 0.09" to PATH environment variable: 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. (Only supported in git-back-to for now)

About

Skybuck's Gitflow

Resources

Readme
Activity

Stars

0 stars

Watchers

1 watching

Forks

0 forks
Report repository

Releases 1

Skybuck's Gitflow (v4) (release-version-0.09) Latest
Aug 31, 2025

Packages

No packages published

Languages