Can Git handle these use cases?

Question

Now I am switching from SVN to Git. The code base is 10-15 modules of a large Maven project. We used repo for each module.

I wonder what architecture my Git repositories should contain in order to handle the following use cases:

• User can check 1..N module.
• John pushes and pushes module M. Emma pulls the changes from the super-folder.
• John commits and causes the module M to be modified from the super-folder. Emma pulls the changes from the module folder.
• John moves (with Git mv) file A from M1 to M2, commits and pushes. Emma edits file Update before commit. File moved with Emma changing.

I was thinking of a single-repository architecture, but UC # 1 is not being processed. "Submodule", " subtree ', and the former" one-module-one-repo "cannot handle UC # 4.

In addition, if most use cases are handled by the architecture of the “submodule”, I would like to introduce as little complexity as possible. A submodule introduces concepts such as a disconnected head, and can cause painful repairs after more frequent errors.

I did an extensive search, and I'm not sure if this is possible without introducing too many complexities, but I hope some of you must have found a workaround.

Note. Our current SVN architecture cannot handle these use cases.

Thanks a lot, Maxime.

Answer 1

Your analysis is correct; There is no obvious way to solve all of these use cases right away. I would suggest one of two approaches:

• The first requirement to test the modules individually may not actually be needed. With git, you pay for the statement only once when you execute the initial clone, but after that, incremental updates are very fast.
• If you are dealing with Maven modules, perhaps each with its own release cycle, does the module really need source-level communication? If not, then module dependencies can only be represented in Maven.

In fact, you should probably start with one repository and then split it later if you find it necessary. But you probably won't. :)

Answer 2

you cannot have all of this. not on GIT, not SVN.

You already realized that your requirements conflict with each other and even recognize that your current setup does not cover all situations, so you must change the way you approach this problem.

Instead of requiring specific capabilities from the tool, try to explain what the actual problems that need to be solved and allow people to suggest ways to solve them, most likely this will not be what you have already considered.

Now I will try to answer the problems that you indicated in the comments and completely ignore your initial request, I hope that it will help more with the real situation in which you are.

we cannot afford a timeline in which the commit messages of each (10-15) modules are displayed in the same place

unlike SVN, in GIT you have branches (real branches), and each branch will have its own history, as long as your developers use the branches, and you merge them instead of using rebase, you should be able to isolate each branch log with the corresponding by commands, see git log --graph to get this idea.

mergers are currently anxiogenic, and therefore developers are trying to avoid mergers as often as possible

There is no real solution to this, but there are ways to mitigate the problem.

one way is to have several repo clones along with the main copy, if your team is about 40 people and you have 10-15 modules, then I think you have small teams there that focus on specific areas / modules ; if in this case each subtopic should have its own repo clone and merge locally there before merging with the main copy.

this approach effectively breaks down the merging process (and responsibility) into two stages, one of which concerns changes within the subtopic, and the other for interaction with other modules.

But I have to keep the use case 4 (move and edit) to give GIT a clear advantage in the eyes of the developer and tame the fear of merging

I will be completely honest, US # 4 is not possible *. especially on GIT, where the mv operation is actually a composition of rm and add .

maybe if the addition happens before the move, some (d) VCSs can figure it out, but I don’t think the case is for GIT, even so I think you are wrong to “tame this fear of merging” let me explain.

* @sleske suggests checking this thread for a way to make UC # 4

the reason people fear merging is because they don’t understand it, and SVN forces you to unite upstream (i.e. on the server), which adds pressure, the problem with your approach is that trying to help them To avoid this, you reinforce the idea that mergers are something obscure and dangerous that should be avoided; do not do this.

if you want them to overcome the fear you need in order to educate them, that they have tools to deal with the situation, in other words, they do not help them avoid the problem, make them solve it, teach them about all mergers and conflicts, tell them about rerere , even teach them to merge an octopus that I never used, but what the hell is it to teach them too! and then DO their practice so that they become what they know and can handle.

merges into GIT, not as stressful as with SVN, because they are also local, so you can do them as many times as you like, without fear of screwing up another environment, you will only push them, absolutely sure that they are in order.

that at the moment, if you have additional problems, add a comment and I will see if I have an idea, good luck!