gitflow-如何合并以掌握和保持依赖关系正常工作？

Question

I have a project with 2 repositories. Repository 1 depends on repository 2 using git urls.

We are using gitflow, but we don't understand how to do a release that works.

Our dependency between repository1 and repository2 is pointing to develop branch, and once we release, all the code moves to master branch, but the dependency is still looking at develop branch!

On the other hand, we cannot have the dependency looking at master branch all the time too..

It seems as if we need to make a change in the code when releasing, one that will change the dependency url, but that is against git flow as master should not have commits that are not merges

What are we doing wrong and how can we achieve a proper release?

Example

2 teams working on different git repositories for nodejs projects.

One team is dependent on the other, so in order to get all their latest changes every day, they write the following npm dependency

"otherTeam": "git://github.com/sameProject/otherTeam.git#develop",

see the develop at the end of the dependency url?

at the end of development, this should be master - the a tag name.

How can I achieve that without making commits directly to master during the release time?

Different Release Cycle

Thank you @Graham for this comment.

If I understand correctly - you suggest to release component1, and then update dependency version continuously on component2 to point to the new realse for 1. Then component1 should stop development for current version at some point - which means component2 does not need to update dependency anymore, and then component2 will eventually reach end of version and then we can release the entire product.

correct me if I misunderstood you.

This solution was raised in the company, but concerns were raised about this procedure not being automatic enough. The company wants all the components to be built together, have the same version etc...

Answer 1

You'll have to forgive my Java background and relate certain points to the node.js ecosystem.

Given a dependency on a library, for example a template rendering library, I would treat it completely separately from the main web application.

To enable usage in the web app usually I would pull a version of the library down using a dependency manager, eg Ivy/Maven.

Generally I prefer explicit versions when eventually releasing. This enables you to know what is being used and helps narrow down issues related to a certain version of a dependency. The overhead of knowing what you have shipped to a customer, so you know what to fix greatly out ways an automatic process. As in an automatic process this information is lost.

Additionally the version for the template library would relate only for this library and would be different to the main web app. This allows you to reuse the library elsewhere.

To enable a more automatic process whilst developing a release of the main web app you could pull down the latest version until the release branch is ready. At this point making a release of the template library and making the web app use an explicit version.

You could always pull down the latest versions of the dependency if you wish, (at least I know how to do that with Ivy) but I would consider it slightly risky.