git multiple project merging

Question

We will be forking a project into its own codebase, but it will closely follow the project it forked from.

I see it working like this:

Forked project will develop some initial changes to rebrand product. I wouldn't want to share these changes with the original project, but going forward I want to merge changes.

The way we have it setup is separate repos that have the same history now and just add remotes for Each other.

The workflow I was thinking of was this:

We should try to work on feature branches and only have 1 commit per feature so we can each to git cherry-pick . Whenever you work on a feature and make a commit, just do git commit --amend in the branch for the feature. When it is finalized I can cherry-pick the commit.

I don't like this because if the feature gets changed after cherry picking the developer needs to remember to NOT am end but create a new commit.

I would love a way to do this with a merge or rebase.

Answer 1

One possible way to structure this is with three repositories where one repository is the 'white label version' and the other two repositories are for the two front ends. The two front ends would reference the 'white label version' repository as a submodule.

With this structure you:

1. have clearly called out the white label version as a shared resource that is 'controlled' but others
2. yet, still allow for changes to the white label version by the two front ends
3. allow the two front ends to develop independently with their repository contents.

If your two front ends are going to be similar, then they can be branches of one repository (but both dependent on the submodule). In this case, if you are merging back and forth between the two front ends, a good approach is to create a branch for each and every feature. Having a branch per feature frees you from the restriction of 'one commit per branch'. [edit] Depending on the nature of the feature branch you could a) cherry-pick all the commits using <branch-base>..<branch-head>; or b) rebase everything on the branch into one commit and then cherry-pick that one commit or c) use merge/rebase to get the feature branch onto another branch (See the numerous examples from the git rebase documentation, particularly the --onto option.) [/edit]

Also here is a common, well-respected branching model with a discussion on feature branches.

[edit2] You can do this with one repository if you prefer. Keep three primary branches: white-label-dev, prod1-dev, prod2-dev and have the developers on each of the three teams operate only on their branches or their created branches off of their branches. When one team has something that should be shared, the 'corporate integration lead' will do the work of moving commits from that one team's work to the other team's branches. (Moving the commits as I described above.)

Your teams will need some discipline to avoid mucking with another team's branches. But, if you've got a shared repository you can assign hooks to prevent pushes from the wrong team onto another team's branches. [/edit2]

Answer 2

Suggested workflow:

• New branch for each feature
• Developer commits normally to the feature branch
• When merging to the master branch do:

git merge --squash -m 'new feature' branchname

Now, delete the branch!

git branch -D branchname

• If the developer needs to fix something or change the feature, he creates a new branch from the master. Everything else is the same.

The next merge will appear as a different commit on the master branch.

Answer 3

I think that you want to follow a similar procedure that Github uses for keeping forked projects updated.

To start off with would be the whitelabel repo. This is the one that the other projects would fork from. Then the other projects would be a clone of the whitelabel with the whitelabel being set as the upstream repo. Using this you would be able to do git merge upstream/master or git rebase upstream/master depending on the workflow.

The advantage is that you aren't dealing having to keep straight the status of the main project. The other projects become their own forks and can be updated easily. Trying to cherry-pick changes could get onerous easily especially with many commits. And doing this if one of the other projects wants to make changes to code that came from the original repo, you can manage that change much easier.

http://www.techblogistech.com/2012/07/setting-a-default-upstream-branch-in-git/

See the section about pulling in changes here: https://help.github.com/articles/fork-a-repo