How do thousands of programmers edit the same code without chaos?

Programmers avoid chaos by never editing one shared copy. Each person works on their own copy of the code, and a tool called version control records every change as a version, stamped with the date and the person who made it. When two people are done, the tool combines their changes. This combining step is called a merge, and the shared history it protects is what lets a team stay in step.

The oldest way to keep versions is to copy your files into a new folder with a date on it. It is simple, but it is very error prone: it is easy to forget which folder you are in and overwrite the wrong file. Version control replaces the pile of folders with one history. You can go back to any earlier state of a single file or of the entire project, compare two moments, and see who last touched a line that is now causing trouble.

The same tool lets people work side by side. A team can keep one line of work for bug fixes only while another line, often called the trunk, carries new features. Each line is a branch of the history. Sooner or later the lines meet again, and merging is one of the hardest parts of the whole business. If two people changed the same lines, the tool may not be able to decide, and a person has to choose.

You have probably used the idea already. A word processor's undo history, a collaborative web document and the page history of Wikipedia all keep earlier versions you can look at. Lawyers did it long before computers, with contract redlines that show what changed between drafts. Programmers just needed it at a much bigger scale, with many people changing the same files at once.