1

Here's our problem - we have several solutions with multiple projects using our own nuget packages. We're following GitFlow, but not SemVer. Every time we're developing bigger feature or epic we want to keep it's code up to date with our development branch (which can have some other features or bugfixes done in time of developing aforementioned epic), so we want to merge it regularly. The problem is that in every merge, if there were any changes with our nuget packages, we have dozens of merge conflicts in all packages.config files in our projects. Doing it that way, merge takes too much time, especially since after merging we have to manually update nuget versions and install them in our projects. So every time we want to merge something we have to reproduce this steps:

  1. Merge branch
  2. Resolve all version conflicts
  3. Push updated nuget packages
  4. Install updated nuget packages

I've done some research, but I'm still not sure what's the best solution to simplify this process. Ok, we can use PackageReference or Paket with floating versions combined with GitVersion, which would automize steps 3 and 4 for our development branch, but problem with merging and conflicts remains, as our development branch uses release versions (X.X.X) and other branches are using prerelease versions (with -branchName tag). So with every update there still will be conflicts.

So my question is, how to best deal with that situation? Is there any way to solve this using nugets or maybe we can share our code in some other way? Shared Projects won't solve our problems, as our libraries are quite big and we don't want to include them in our solutions.

  • I must be missing somethign, you are merging your master branch (with hotfixes) back into dev? and you get a conflict because a nuget package has changed version on both the dev and master branch? – Ewan Jun 26 '18 at 10:40
  • are you checking in the binaries? – Ewan Jun 26 '18 at 10:42
  • Yes, that's the case. For example I made epic branch when master had package in version 1.0.0, I've already made some changes to this package on epic (1.0.1-epic) and also on master (1.0.1). When I want to merge master to epic, I'm getting merge conflicts in packages.config in alll projects using this package. – JayL Jun 26 '18 at 10:47
  • It seems like that should be a rare occurrence, you have hotfixed the same functionality that your are working on in the branch – Ewan Jun 26 '18 at 10:51
  • are you referencing packages which are compiled from the same git repository? – Ewan Jun 26 '18 at 10:52
1

OK Here's my guess.

You have a shared lib distributed by nuget and consumed by you application.

When you get a feature request for the application you create a new feature branch on its repo, but find that it will require changes to the shared lib

You create a feature branch on the library repo and publish a pre-release nuget

You consume the prerelease nuget on you application feature branch and continue testing the feature.

In another Application feature branch you have the same thing happening, when you finish that OtherFeature, you update the library and dev branch, but your OrigionalFeature is still on its prerelease nuget and you get conflicts.

The solution is to add and test features to the library independently of the application. Don't publish unfinished library features, finish them off and merge them in to master before publishing.

Once the library is updated with its new functionality, Then you can update the application to use the latest version and proceed to make a feature branch.

Obviously this means you need to work out your specifications bit more rigorously.

Alternatively you might try packing the library locally as the same version and use a directory as a file source, while you test so you don't have to update the version on the app

  • First solution is I think what we'll be aiming for, but in the future - currently we're not able to fully test our libs independently of the application. There's a lot of legacy code not covered by any tests. That's why for now I'm leaning to second solution. We could separate development process from nuget and publish and install new packages only in build enviroment, which sounds like a good solution. Thank you, I think we'll give it a try. – JayL Jun 26 '18 at 13:25

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.