Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Discussion: Branching Strategy for Function Refactoring #9

Open
jibarozzo opened this issue Feb 26, 2025 · 3 comments
Open

Discussion: Branching Strategy for Function Refactoring #9

jibarozzo opened this issue Feb 26, 2025 · 3 comments
Assignees
Labels
discussion Ideas or SOPs to guide development

Comments

@jibarozzo
Copy link
Collaborator

jibarozzo commented Feb 26, 2025

Posting as an issue, but it's more of a discussion of strategy.

I thought this a little more about how to best incorporate improvements on functions and make sure all is working before merging into main. I suggest the following branching strategy for refactoring functions (thanks to AI for organizing my early morning thoughts):

  1. Main Refactor Branch (function_refactor):

    • All refactoring work will be done in the function_refactor branch.
    • This branch will act as the main branch for function refactoring tasks.
    • When creating a new branch for refactoring a specific function, always branch from function_refactor.
  2. Specific Function Refactor Branches:

    • Each function refactor should have its own branch, which will stem from function_refactor.
    • The naming convention for these branches will be functionname_refactor. For example, if refactoring a function called sncm.LL, the branch should be called sncm.LL_refactor.

    Example:

    • function_refactor → base branch for refactoring.
    • sncm.LL_refactor → branch specifically for refactoring the sncm.LL function.
    • bino.LL_refactor → branch for refactoring the bino.LL function.
  3. Workflow:

    • Step 1: Create the base branch function_refactor (already created).
    • Step 2: For each function that needs refactoring, create a new branch named functionname_refactor.
    • Step 3: After completing the refactor for a specific function, open a pull request from the specific *_refactor branch to function_refactor.
    • Step 4: Once all refactoring work for individual functions is merged into function_refactor, it can be merged into the main branch by "Squash" method.

See A successful Git branching model for more details on this model.

This method helps keep each function's refactoring isolated, making it easier to review, test, and merge individual changes.

Related to #7 and #4

@jibarozzo jibarozzo added the discussion Ideas or SOPs to guide development label Feb 26, 2025
@jibarozzo jibarozzo added this to the All-BRC-Analysis milestone Feb 26, 2025
@jibarozzo jibarozzo linked a pull request Feb 26, 2025 that will close this issue
3 tasks
@jibarozzo
Copy link
Collaborator Author

@B-Kristy

@B-Kristy
Copy link
Collaborator

B-Kristy commented Mar 6, 2025

Ok thanks for this -- it's an intuitive workflow and it makes sense to me. I probably should have been more specific when naming my function refactor branch as 'myfeature_function_refactor'.

@jibarozzo
Copy link
Collaborator Author

jibarozzo commented Mar 6, 2025

No problem. I'm also learning a lot about branch management. Trying to minimize convolution for me and all.

I just pushed new changes to function_refactor trying out git merge --no-ff . No PR for those changes, so seeing what works best. I like PRs better to make everyone aware of what happened.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion Ideas or SOPs to guide development
Projects
None yet
Development

No branches or pull requests

2 participants