ande3577 / git-subtree-workflow-proposal Goto Github PK

Since it can be either feature or issue, hence topic.

*Branch with parallel feature branches
*Create a version with and without squash to show the difference

Create separate branch with shared code
Rebase on latest shared library
Push changes to a specific branch in your shared repo.
Send email (our use issue tracker) to maintainer of shared library
include repo location, branch name, and target branch name

git merge -s subtree appears to have issues overwriting conflicts. It is possible that using the recursive branch strategy with a subtree argument would fix this.

Ideally, this would eliminate the step in the workflow of checking out out the local branch and allow for merging directly from the remote branch. This would also allow for eliminating the need for the library editing clones altogether and greatly streamline the process.

The downside is this would require the developer to specify the location of the module each time a merge is done, rather than only when read-dir is called.

would be a little cleaner and more organized

Pull from individual project repo
rebase on target branch
If get conflicts, reject pull request
Merge

How to handle if both library and project remote branches are changed? Can I rebase then push a shared branch?

see https://github.com/apenwarr/git-subtree/blob/master/git-subtree.txt

Especially problematic in subtree merges. Lose history.

Not sure if this is possible with built-in git capabilities, may need to use deprecated git-subtree split.

i.e. is there a Push with subtree strategy?

Feature branch -> long term branch: merge
Long term -> feature: rebase

Splitting a subpath out into a new repo

For each project that uses a subtree:

1. Include the name of the subtree
2. Include that project path to the subtree contents
3. Include the remote repository address of the subtree

Including both -s subtree and -X subtree = forms

instead of creating multiple branches and switching back and forth. Clone the entire repository before creating the branch. This enables two branches to remain on disk at the same time, which eliminates the need to rebuild after branch switching.

Because should never rebase a publicly accessible branch. If someone else branches off of your branch, they'll wind up lost.