The author of a work and the copyright holder of the work don't need to be the same entity.
An example of this is music - a song is written by an artist, but the copyright on it may be held by a distributor. We still credit the artist with creating the song.
When an employee writes code as work for hire, the employee is still frequently recognized as the author of the work, although according to law the employer may claim authorship (as well as copyright and other rights). It is up to the employer to decide whether, and how, the employee is acknowledged as the author.
In any event, the employer generally holds the legal rights to the work, for example copyright. When projects ask for copyright assignment (i.e. signing a CLA), they generally use language which makes the contributor either state that they own copyright (i.e. the work is not a work for hire), or get the employer to sign off on the copyright assignment. For example, the Facebook CLA says:
"You" (or "Your") shall mean the copyright owner or legal entity authorized by the copyright owner that is making this Agreement with Facebook.
The ASF CLA goes into more detail on what is expected from both individuals and corporations.
Depending on what the requesting project requires, names of developers who produced the code may not need to be published:
- The employer (in the US, other jurisdictions may vary) owns all interest in the work.
- The employer designates a person who is legally allowed to sign copyright assignment on behalf of the employer.
- Subsequently, this person can submit the code as "being produced by FooWidgets Inc."
In practical terms the code submitted by an employer still needs to be associated with a person (either the one who signed the copyright assignment, or someone who the employer designated as being allowed to submit code). But this person can, in principle, be someone from legal team and not a developer.
If now the employee personally signs a contribution agreement or contributes under her or his own name, she or he would give away rights on something which are owned by someone else.
The employee can legally sign the copyright assignment agreement extending to whatever code they own copyright to (such as work done on their own time). The employee would not be legally allowed to contribute code that they don't own copyright to (such as work done for hire) even if they signed such an agreement, because they don't own the rights.
when browsing through some repos on Github I only see real names at commits.
Most tech companies allow their employees to retain authorship/credit of the work they have done, even when the company owns all rights to the work. This serves to motivate the employees, and doesn't usually cost the company anything.
That said, I worked for a company that allowed open source contributions as long as they did not have any association with the company. (The thinking as I understood it was the company did not want to provide the impression of "giving away" their IP.) I was allowed to contribute if I did so under a fake name and the company's name was not mentioned anywhere. A project that does not require copyright assignment typically won't bother checking whether the name that someone gives is real - there is no way to do that, really, short of asking for government-issued ID which I think many people would balk at.
This isn't a 100% legally sound way of running a software project (which is why copyright assignments are required by large companies) but the majority of free software/open source projects operate in this way. Also, the Github terms of service state that a contribution to a repository is made under the repository's license, which is satisfactory for most projects.
Or do other companies use some kind of "proxy persons" hiding the internal structures?
Given that many people post their company & position at LinkedIn, hiding corporate structure by preventing developers from putting their name on their contributed code probably doesn't accomplish much. The managers who are, one might argue, the actual hierarchy often don't write code and are even less likely to submit it to a project outside of the company.