I recently watched The Social Network, and this might be a stupid question, but how is it possible for multiple people to work on one website? I mean, if they're working on the same page, how is that possible? And also, is it possible to upload files to an online host without making them live?

  • 12
    Source control. Each developer works on the files locally, then has to check out the file which prohibits other developers from replacing content within the file until it is checked in. en.wikipedia.org/wiki/List_of_revision_control_software
    – mjw06d
    Jan 6, 2011 at 19:58
  • 3
    Never use version control's lock functionality on files unless they are binary though. Jan 6, 2011 at 21:03
  • @gommo: What do you mean by 'binary'? Can you expand on that?
    – Cam
    Jan 7, 2011 at 6:20
  • 1
    @Cam: in this context “binary” = “anything that is not a text file” Jan 7, 2011 at 10:57

12 Answers 12


Usually when multiple people need to make changes to the same file, they use some kind of version control system to keep track of who made what changes. It also lets them merge and synchronize the changes different people make.

  • 1
    Simple, yet elegant.
    – Ryan Hayes
    Jan 6, 2011 at 20:33

Very few websites consist of just one "page" and, for cases where multiple people would work on the same page, most revision control systems have mechanisms built in for merging the changes back together into a unified file.

  • Just to be picky :) unless it happens to be a CMS based system, where all pages are virtual and only exist in a database.
    – Darknight
    Jan 7, 2011 at 12:41

Multiple persons working in the same files: Source control

Without making them live: Development servers & databases, which are not the same branch as the real website.


They need some kind of manager.

Typically, teams are broken up into segments that should never interfere with each other (famous last words). For instance, if the foo API depends on helpers from the people who code in C, the breakage should (never happen), but if it does, it happens because the helper app doesn't understand what you are passing to it.

That is a classic case of the right hand not knowing what the left hand is doing, which clearly illustrates the fault, which is probably mine.

If you push code without first pulling and resolving merges (while breaking what the other dev did by just removing whatever you didn't write), prior to communicating with others who edit the same, I'm going to dose you with high voltage. After that, I'm going to take you out to dinner (to make ammends for the 1.21 gigawatts) and ensure that you ingest some kind of crazy, disgusting and quite exotic food. Think ... Klingon.

You'll then thank me for that, and never do it again.

Of course you could substitute some sort of normal 'talking to' here, but what fun is that?


You'll probably find that they have developers working on different pages. A template or site master is usually created so that each page has the same look and feel. For example, if the company is using Source Control such as Team Foundation Server, each developer would check in their source code and this will allow the other developers to get their latest changes.

  • 2
    TFS was the best you could come up with for an example of a Source Control Management system? Come on now. Jan 6, 2011 at 20:25

They could either:

  • Be programming in an editor via an SSH session (e.g. vi, vim, nano, emacs).
  • Be editing through FTP with their IDE (e.g. emacs, notedpad++).
  • Using a version control system.

For the last one, people now use distributed version control such as mercurial, git and bazar, instead of centralized version control such as CVS and subversion. For mercurial, check bitbucket.org and google code project hosting, for git, check github, which are sites that host the code for you to share collaboratively without you needing to set up a server.



Developing pages with components VS Pages as a Whole

I've worked on many large scale websites, and the way multiple people work on the same page is that most websites are portals. In general, many sites like facebook contain many controls, such as photos, ads, little blurb areas, etc, which multiple people will work on. Also, headers and footers are generally broken into their own reusable include file. This breaks the site up into components that can not only be worked on individually, but can also be re-used across multiple sites and areas.

  • do you know what a web portal is? (hint, it's not a mashup. think old times Yahoo)
    – Javier
    Jan 6, 2011 at 22:38
  • Yea, I was trying to use an example that shows that one technique is to break pages into components. A good example of that is a portal, except users can drop in/out portal widgets, while building pages using components can be only from the dev side. Portals is a good visual example.
    – Ryan Hayes
    Jan 6, 2011 at 22:51

You could use some sort of live syncing system like OneNote uses.... Furthermore, you could upload files to a host but not make your main domain link to them.


Don't forget that there can also be content management systems that some sites use to serve content so that while you may think something is a web page, it is really this mix of stuff.

Many content management systems will have a preview feature to allow authors to view content before making it publicly accessible.


All of these tools mentioned are helpful, but to me it sounds more like the OP is more asking how people keep from getting in the path of others.

In addition to using tools to solve those conflicts there is usually some division into stacks or tiers to help avoid the conflicts in the first place.

With the stack approach you have each person working on an unrelated feature (one person may be doing account sign-up and one may be doing content submission). There will be some conflict where the two may cross (user records in this example probably) and that gets handled as part of the merge to the next build.

With the tier approach someone is building all the innermost bits, when they get one portion finished another person writes the bits that sit atop those and so on. the conflicts generated here are usually when something has to be returned to on a lower tier for some later modification that could affect the next tier above and are handled in a similar manner before the next build.

The part about files promoted but not live has a wide variety of answers/implementations, but a separate server to preview on, a specific preview mode, or a user class or entitlement that pulls the bleeding edge version while regular users get the stable version are the ones I tend to see most often.


To answer the second part first, one way to upload files without making them live is to give them a name that won't be linked to. E.g. to make a new version of an index.html page, upload it with the name it index2.html, then visit http://yoursite.com/index2.html and check that it works OK. Once you are satisfied, rename it to index.html. This is really only for very small sites, and it gets a bit messy if you want to change something external to the page, like images, CSS or JavaScript files, because you have to have image2.png, then index2.html whose only difference is that it points to the new image.

A professional programmer would always have a test system to work on, then upload to their "online host" once they are happy with the changes. You can set up a web server on your computer that will only serve pages inside your local network. Of course you could also use a separate computer, or (as I do) a virtual machine running on your main computer.

When multiple developers work together, each would have their own test system to work on, then upload their changes to a version control system that keeps track of all the changes from all the different people. See the git parable for how this works.

The version control system makes it easy to see who changed what and why. This can be checked over by whoever is in charge and then merge it into the master, and hand it over to the testing / QA department. Once they have fully tested the new features, they will approve it for uploading to the live site.


First thing to establish is that many sites aren't a collection of static pages that are worked on by one or more people.

The pages that you see as a visitor don't exist on the website to make changes to as in such sites they are automatically assembled on-the-fly by a content management system - software running on the hosting server, using content that the website owners have produced. The CMS assembles the page from the content laid out using template files (CSS and CMS's own config files) and the resultant page is served to your browser.

The site owners make changes to the content and the layout templates rather than static pages. Leading on from that your answer depends on the type of change and the role of the person doing it:

  1. a site public user, posting a blog or comment
  2. if you are changing the content on the site (content producer role, e.g. journalist working for the website owner) or
  3. adding and changing functionality of the site (site developer working for the site owner).

Drupal is a free and powerful content management system that provides multi-user management to handle content updates which in turn affects what is seen by visitors on pages. Drupal will also provide means to alter the behaviour of the pages, e.g. how they are laid out or if commments on an article can be posted, addressing the 1st and 2nd types of change. If doing the changes in Drupal these will be stored in a SQL database. Drupal provides some versioning/revision control of content.

A full version control system is needed for more involved site behaviour changes, the 3rd type of change e.g. introducing more features, receiving updates from Drupal, or fixing bugs on own added code, then this means changing the code and as others have posted here. Version control systems such as GIT, Subversion or Mercurial - all free - are used to manage the changes made by several developers of the site.

Not the answer you're looking for? Browse other questions tagged or ask your own question.