具有开源和专有(私有)部分的项目的git工作流程 [英] git workflow for a project with open-source and proprietary (private) part

问题描述

Wordpress插件具有免费和PRO版本. PRO版本包含其他文件，这些文件分散在整个代码库中.

Wordpress plugin with free and PRO version. The PRO version contains additional files, scattered across the codebase.

在git中跟踪以下两个版本的最优策略是什么:

What is the optimal strategy to track both versions in git, satisfying the following constraints:

1. 免费版本在GitHub上是开源的，接受捐款；
2. PRO版本已与专用存储库同步；
3. 本地开发是在PRO版本上进行的(例如，为了使其能够正常工作)；
4. 两个历史都是相关的(PRO⊇free的历史)
5. 低维护:

1. free version is open-source on GitHub, accepting contributions;
2. PRO version synced with a private repository;
3. local development takes place on the PRO version (e.g. for refactoring to work);
4. both histories are related (history of PRO ⊇ free)
5. low-maintenance:

1. 我们是git noobs
2. 没有手动记录适合哪个文件的文件.

遵循免费与专业版二分法之后，有许多Wordpress插件.他们是如何版本的?

There are numerous Wordpress plugins following this exact free vs. PRO dichotomy. How are they versioned?

推荐答案

想到了一些简单的方法...

A few simple approaches come to mind ...

将所有分散的文件移动到单独的名称空间目录(例如./pro)中，在其中将单独的PRO存储库克隆到其中，仅包含PRO文件. 缺点:必须将两个存储库的签出保持同步(即，如果您在一个存储库中切换到旧提交，则还总是需要在另一个存储库中切换到兼容的提交)回购).

Move all scattered files into a separate namespace directory, such as ./pro, into which you clone the separate PRO repository, containing only the PRO files. Drawback: The checkouts of the two repositories would have to be kept in sync (i.e. if you switch to an old commit in one repo, you'd always also need to switch to a compatible commit in the other repo).

我想这是正常完成的方式.在两个不同的存储库中维护免费和PRO版本.让PRO repo定义要从中获取并合并更改的公共远程源.

This, I suppose, is how it's normally done. Maintain free and PRO versions in two distinct repositories. Let the PRO repo define the public remote source to fetch and merge the changes from.

cd ~/project-libre
git remote add origin GITHUB_PUBLIC_REPO

cd ~/project-pro
git remote add origin PRIVATE_REPO
git remote add libre GITHUB_PUBLIC_REPO  # to fetch and merge changes from

只要有更改提交到公共存储库，您就可以通过以下方式将其合并到您的PRO版本中:

Whenever there are changes submitted to the public repository, you can merge them into your PRO version with:

cd ~/project-pro
git checkout master
git pull libre master --allow-unrelated-histories
git push origin master

只要要同步到已发布的免费版本中的PRO版本中有更改，就可以使用

Whenever there are changes in the PRO version you want to sync into the published free version, you can use git-format-patch to export the changes as patch files, then on the other end import that patchset, excluding any files that are not to published in the free version. Like so:

cd ~/project-pro
git checkout master
git format-patch HEAD~3..HEAD  # Export e.g. last three commits as patches

现在切换到免费版本并应用补丁(使用 git-am ) ，从每次提交中排除免费版本忽略列表中的所有PRO文件(路径).我将它们放在免费项目根目录下的 .gitignore 文件中，并且命令行假定POSIX shell可用(对于.gitignore中的每个文件/路径，都重复--exclude参数).

Now switch to free version and apply the patches (with git-am), excluding from each commit all the PRO files (paths) that are on the ignore list for the free version. I put them in a .gitignore file here in the free project root, and the command line assumes POSIX shell is available (repeats --exclude parameter for every file/path in .gitignore).

cd ~/project-libre
git checkout master
git am $(printf -- '--exclude=%s ' $(cat .gitignore)) ~/project-pro/*.patch    

两个分支

有两个分支，每个分支与另一个遥控器同步.

Two Branches

Have two branches, each synced with a different remote.

git remote add origin  GITHUB_PUBLIC_REPO
git remote add private PRIVATE_REPO

创建两个文件，一个免费，一个PRO:

Create two files, one free and one PRO:

touch free1 pro1

在master分支上，创建一个包含所有PRO文件的.gitignore

On master branch, create a .gitignore containing all the PRO files

git checkout master
echo 'pro*' > .gitignore

git add .gitignore
git commit -m 'Add .gitignore ignoring PRO files'

将公共分支与公​​共存储库同步:

Sync the public branch with the public repository:

git push -u origin master

现在将分支主节点转移到私有PRO分支中，并清除.gitignore，因为在那里PRO文件不会被忽略.

Now branch master into a private PRO branch and clear the .gitignore as the PRO files are not ignored there.

git checkout --branch master-private
echo > .gitignore

git commit .gitignore -m 'Clear .gitignore -- track all files here'

将私有分支与私有存储库同步:

Sync the private branch with the private repository:

git push -u private master-private

现在将free1和pro1文件提交到各自的分支:

Now commit free1 and pro1 files to their respective branches:

git checkout master
git add free1
git commit -m 'Add free1'

git checkout master-private
git add pro1
git commit -m 'Add pro1'

然后将master合并为master-private，以便它包含完整的集合.

And merge master into master-private so that it contains the full set.

git checkout master-private
git merge master

您需要解决一个.gitignore冲突(或者您可以指定-X ours合并开关).

You need to resolve the one .gitignore conflict (or you can specify -X ours merge switch).

稍后，您将在master-private分支(第3节)上进行一些开发，以修饰并创建适合两个分支之一的各种文件:

Later, you do some development on master-private branch (§ 3) retouching and creating various files that would fit in either of two branches:

git checkout master-private
touch free2 pro2
echo xxx > free1
echo xxx > pro1

您不想枚举要提交的所有非PRO文件(第5.2节)；这就是您拥有.gitignore的目的.您可以通过切换到master并提交所有适合的东西来使用它，然后再切换回master-private，然后提交剩下的东西.您需要先存储更改，因为更改更改会被分支覆盖.

You don't want to enumerate all the non-PRO files to commit (§ 5.2); that's what you have the .gitignore for. You use it by switching to master and there committing everything that fits, then switching back to master-private, committing what remains. You need to stash the changes first as they would be overwritten by switching branches.

git stash
git checkout master
git stash apply

您在这里遇到冲突，因为pro1的存储已更改但在master上已删除.您可以通过告诉git通过取消暂存来继续忽略它来解决它.

You get a conflict here about pro1 changed in stash but deleted on master. You resolve it by telling git to just continue to ignore it by unstaging it.

git reset HEAD .

现在提交所有免费文件:

Now commit all the free files:

git add free2  # Manually add the new files (easy and not violating § 5.2)
git commit -a -m 'Update to free1 and free2'

切换回专用分支，合并到更新的master分支中，然后再次从存储中提交其余文件.

Switch back to the private branch, merge in the updated master branch, and commit the remaining files, again from stash.

git checkout master-private
git merge master
git stash pop  # The stash now applies cleanly and is removed
git add pro2  # Manual but necessary adding of new files (not violating § 5.2) 
git commit -a -m 'Update pro1 and pro2'

就是这样.

当您在GitHub上收到请求请求并合并它时.之后，只需将其与本地主机同步，然后将其合并到私有分支中即可:

When you get a pull request on GitHub and you merge it. Afterwards just sync your local master with it and then merge it into the private branch:

git checkout master
git pull
git checkout master-private
git merge master
git push

git很简单–容易.

git is easy–peasy.

这篇关于具有开源和专有(私有)部分的项目的git工作流程的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！