Let me run a hypo. Three people. A, B, C.
Persons A, B, and C are all running 1.0 and all working from home. A is working on animation, B is working on sound, and C is working on engine/tech.
A alters 1.0 for his animation work. He saves/uploads that so that others can access it. Saves as 1.5.
B alters 1.0 for her sound work. She saves/uploads that so others can access.
C alters 1.5 to include her engine/tech patch and upgrades. She saves as 2.0.
Can you merge 2.0 and 1.0 into a 3.0? How easy is it?
Git works by recording changes as a way to reduce the size of updates. So these kinds of version control only work for text files, usually. However, you can freely push new files onto a repro. In your example, those would be components that don't rely on each other. Those would be externally loaded at runtime, not necessarily something compiled into the binary, so managing that sort of stuff is pretty easy. Usually, when you work on projects, you'll have dummy files in place as those parts are worked on. So as, say, animations or sounds are completed, they would get pushed to the repository to be loaded instead of the dummy files.
A more relevant scenario I think you're envisioning is when you're working on modular code. Say I'm working on io event handling while someone else is working on a physics system, those would likely be different source codes, handled by different classes that are compiled and linked into the binary when the project is built. In this case, coordinating the interaction between my io event handler and this physics system would have been hashed out through a common agreed upon interface early on in development, and each of us would fork the repro for our own components. Our agreed upon interface would have stubbed out sections that we could fill in with dummy code until our forks are complete. Like, say the physics system needs to tick some IO input on a frame, so it calls an agreed upon interface function like io.getInput() that resides in an interfacing class. Early in the project, calling that function might do nothing more than printf("Called io.getInput()\n"); until I finish my work. In critical components, black box cases can be made, i.e. the meat of the function isn't there yet, but it'll set values as though it were working correctly, to simulate the behavior so that other parts of the project can continue. The function still exists, the physics class can still call out to it, but the actual meat isn't there until my fork is merged back into the repro.
You use forks in this instance so that, while I'm working on my io event handler, I essentially have an entire version of the project to myself to mess with. If I break something in my module, it doesn't destroy someone else's code. The process or merging code back into a project is called integration and it requires lots of coordination to make the process easy and smooth.
the idea behind modular programming and forking is to make it so that parts of a program can be encapsulated, you only work on one component while it feels like everything else around that component remains static.