如何在不同存储库中的多个解决方案之间共享源代码库? [英] How to share source code library between several solutions in different repositories?

问题描述

我有一个公共的库，我想在几个解决方案之间共享，这些解决方案存储在不同的github仓库中.我们将共享库放在单独的GitHub存储库中，并创建了nuget包，可以将其安装在每个所需的项目/解决方案中.缺点是，更改库中的代码涉及几个步骤(更改代码，推送到库存储库，创建nuget软件包，安装软件包)，这很烦人.

I have a common library that I want to share between a few solutions, that stored in different github repositories. We put the shared library in separate GitHub repository and created nuget package, that can be installed in each required projects/solution. The disadvantage is that changing code in a library involves a few steps ( change code, push to library repository, creating nuget package, installing package) which is annoying.

我想使用git subtree创建带有库项目的子目录，并在我的解决方案中将其用作本地项目，并轻松进行代码更改/测试/调试. 主要"解决方案的开发人员可以选择-包括库作为二进制nuget包或作为子目录中的源项目.

I wanted to use git subtree to create sub directory with library project and use it as local project in my solution with easy code changing/testing/debugging. Developers of "Main" solutions will have a choice- include library as a binary nuget package or as a source project in subdirectory.

问题::当我尝试git subtree时，发现了一个问题:csproj文件在独立库解决方案中以及在一个主要的解决方案. 在MyLib.sln中，路径为".. \ Packages"，但在Main.sln中，路径应为".. \ .. \ Packages".
主要GitHub信息库的结构(和OtherUserOfMyLib GitHub信息库(是)):

PROBLEM: When I tried git subtree, I found one issue: csproj files have relative references to packages folder, that are located on different levels, when included in standalone library solution and when included in a main solution. When in MyLib.sln the path is "..\Packages" , but in Main.sln the path should be "..\..\Packages" .
The structure of Main GitHub Repository ( and OtherUserOfMyLib GitHub Repository(is)) :

Main.sln
LibSubfolder
-----------------| MyLib.sln
-----------------| MyLibSource
--------------------------| myLib.csproj
--------------------------| myLib code
-----------------| (expected Packages from lib solution)
Packages.  (From main solution)

MyLib GitHub存储库的结构:

The structure of MyLib GitHub Repository:

MyLib.sln
MyLibSource
--------------| myLib.csproj
--------------| myLib code
Packages.  (From lib solution)

我尝试了git subtree从Lib存储库中仅复制MyLibSource子目录(这将使packages文件夹的相对位置相同).不幸的是，我没有找到从另一个存储库复制子目录的方法，该方法以后支持将更改推回原始存储库.答案 使用git-subtree添加远程仓库的子目录有一些选项，但所有这些似乎都只讨论了单向(同步)同步. 从我看来，git子模块和git subrepo不支持从源存储库复制子文件夹.

I tried git subtree to copy only MyLibSource subdirectory from Lib repository (That will allow to have relative position of packages folder the same). Unfortunately I didn't find a way to to copy subdirectory from another repo, that support later PUSH the changes back to original repo. The answer Add subdirectory of remote repo with git-subtree has a few options, but all of them seems only discussed one-way (pull) syncronization. From what I looked, git submodule and git subrepo do not support copying subfolder from source repository.

我错过了什么吗?谁能建议，如何从库存储库复制到我的存储库文件夹的子文件夹，这将允许以后进行双向(拉/推)同步?

Am I missing something? Can anyone suggest, how to copy to subfolder of my repository folder from library repository, that will allow later two-way (pull/push) syncronization?

我考虑的其他选项是更改packages文件夹的位置.但是我不确定，对于main.sln和MyLib.sln，应该选择哪种路径是一致的.

Other option I considered is to change the location of packages folder. But I am not sure, which path to choose to be consistent for both main.sln and MyLib.sln.

第三种方法是不使用MyLib存储库中的MyLib.sln；仅将存储库用作库源代码的主存储.而是在Main存储库中创建MyLib.sln并使用它来构建NuGet包.我将能够使用MyLibSource项目的git subtree pull/push内容. OtherUserOfMyLib存储库将仅引用子文件夹中的项目，并在需要时调用git子树拉/推

The third approach is do not use MyLib.sln in MyLib repository ; use the repository only as a master storage for library source code. Instead create MyLib.sln in the Main repository and use it to build NuGet package. I will be able to use git subtree pull/push content of MyLibSource project. OtherUserOfMyLib repositories will just refer to the project in subfolder and also call git subtree pull/push when required

Main.sln
MyLib.sln       ( locate in Main repository instead of MyLib repository)
LibSubfolder
-----------------| MyLibSource
--------------------------| myLib.csproj
--------------------------| myLib code
Packages

我的问题是尝试哪种方法:

My question is which approach to try:

• 花时间尝试找到一种方法来推迟创建的git子树 子文件夹?
• 尝试更改包文件夹的位置?
• 保留解决方案以在存储库外部构建nuget软件包 有包装(第三种方法)?
• 还有什么?

• spend time trying to find a way to push back git subtree created subfolder?
• try to change location of packages folder?
• Keep solution to build nuget package outside of repository having the package(3rd approach)?
• anything else?

我看过类似的问题，例如 在.NET中的解决方案之间共享通用库的最佳做法和

I've looked at similar questions like Best practice to share common libraries between solutions in .NET and How do you share code between projects/solutions in Visual Studio? but didn't find satisfactory solutions.

推荐答案

我能够使用git子树来共享公共存储库(例如，源代码库)作为不同客户端解决方案(存储库)的子文件夹，并允许推送更改回到共享存储库.

I was able to use git subtree to share the common repository (e.g. source code library) as subfolder of different client solutions(repositories) and allow to push the changes back to the shared repository.

我们对c#库(Powershell psm模块的文件夹)使用类似的方法，考虑将其用于React jsx组件的收集.对于c#库，客户端存储库之一将构建NuGet软件包，任何喜欢引用NuGet软件包而不是源代码的解决方案都可以使用它.

We are using similar approach for c# libraries, folder of Powershell psm modules, consider to use for collection of React jsx components. For c# library one of the client repositories builds NuGet package, that can be used by any solution which prefer to refer NuGet package instead of source code.

如果我们需要包含一些开源github库的源代码(例如，如果我们想在新版本发布之前进行更改)，则使用相同的方法.

The same approach we are using if we need to include source code of some open source github library ( e.g. if we want the changes before a new release is available).

在每个应用程序存储库中，我们需要自定义两个批处理文件(对于每个公共存储库):subtreePull和subtreePush.

In each application repository we need to customise two batch files (for each common repository): subtreePull and subtreePush.

批处理文件示例(基于使用git-subtree添加远程仓库的子目录答案):
MyCommonLib-SubtreePull.cmd

Examples of batch files (based on option 4 of Add subdirectory of remote repo with git-subtree answer) :
MyCommonLib-SubtreePull.cmd

@rem Template Pull and Push  are located in SubTreeCommands folder
@Rem from https://developer.atlassian.com/blog/2015/05/the-power-of-git-subtree
@set remoteBranch=master
@set RelativeTarget=src/MyApplicationProject/LibSource/MyCommonLib
@echo If you have errors "Working tree has modifications.  Cannot add." uncomment stash before command and stash apply after command
@REM git stash 
@rem run this command from the toplevel of the working tree 
@for /f %%i in ('git rev-parse --show-toplevel ') do set GitRoot=%%i
CD %GitRoot%
IF EXIST %RelativeTarget% (
set gitCmd=pull
) ELSE (
set gitCmd=add  
)
@rem if you want to have full history, do not include  --squash
git subtree %gitCmd%  --prefix %RelativeTarget% https://github.com/MyCompany/MyCommonLib.git %remoteBranch% --squash
@REM git stash apply
@pause

MyCommonLib-SubtreePush.cmd

@Rem from https://medium.com/@v/git-subtrees-a-tutorial-6ff568381844#.a2ne9vlve
set remoteBranch=master
@rem run this command from the toplevel of the working tree 
@for /f %%i in ('git rev-parse --show-toplevel ') do set GitRoot=%%i
CD %GitRoot%
git subtree push --prefix=src/MyApplicationProject/LibSource/MyCommonLib https://github.com/MyCompany/MyCommonLib.git  %remoteBranch%
@pause

在工作期间，您需要进行常规的git commit/git push来更改应用程序存储库中的更改，包括LibSource公共库子文件夹中的更改.

During the work you are doing normal git commit/git push for the changes in your Application repository, including changes within LibSource common library subfolder.

要同步公共库更改，请运行subtreePush/subtreePull命令.
请注意，建议subtreePush在库中进行重大更改后运行(例如在每个相关项目的末尾).
subtreePull可由不同存储库中的不同人员完成，建议在存储库的主要工作之前运行(例如在项目开始时).
子树的pull和push批处理都需要一些时间才能运行，但是您可以启动它们并执行其他任何操作.

To synchronise your common library changes run subtreePush/subtreePull commands.
Note that subtreePush is recommended to run after major change in the library (e.g. at the end of each relevant project).
subtreePull may be done by different persons in different repositories , it is recommended to run before major work with the repository(e.g. at the start of a project).
Both subtree pull and push batches take some time to run, but you can start them and do anything else.

这篇关于如何在不同存储库中的多个解决方案之间共享源代码库?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！