Separate branches or git projects?

非 Y 不嫁゛ 提交于 2019-12-06 16:21:29

Separate Git projects: branches are interesting if you intend to merge common code source.

But if your apps are independent (in development, even though they are somehow linked in runtime), a git repo per application will work better.
It will allow for each app to follow its own development lifecycle, with its own set of tags and branches.

If you want to keep track which versions of those three apps are, at a given time, working together, you can create a fourth repo, and register the first three as submodules.

Think of branches as temporary areas for developing "Work In Progress" code that will eventually get merged back into master.

If you have different applications, use different git projects. Git projects are cheap and everything stays a lot easier if you keep distinct degrees of separation in your workflow.

In my opinion if you don't have common code between the applications it has no sense to put them on separate branches. You will never need to merge them or cherry-pick from a branch to another. I would vote for separate repos.

I think that you have these options:

  1. put the code at different git repositories.
  2. put the code at the same git repositories, but at different directories.

I would take 1 if there are separated teams and the teams don't need/are allowed to access the others code, and the applications are independent (i personally prefer this approach, even if they are dependent). I would take the 2 if everybody make modifications at all application codes and they are supposed to be together ALWAYS (theres a large dependency between the applications).

The branching is not an option since branching is something that you do to a common code. You have a code that changed in some way (you make a branch), and then you want to merge that modifications to the main code (you merge the branch).

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!