CVS Is Dead

The CVS repository is no longer needed. To prevent developers who have not heard about the move from checking in new material, the admin should check in a highly visible file, such as MOVED_TO_GITHUB, to give the latecomers a wake-up call before their contributions end up in a dead repository.

Now it's high time to create the project on GitHub so that you can push it live. Once the developer has created a new account with a username (mschilli in this case), you can click Your Repositories (create a new one) and add the three lines of text shown in Figure 1. The next thing GitHub needs is the public keys of everybody who has write access for the project repository. Public keys with the Secure Shell are a great way to eliminate typing your password every time; on GitHub, they're mandatory to identify a developer (Figure 2). Write access to the repository is handled later by talking to git@github.com, without specifying a username. Password-based identification is thus impossible via SSH on GitHub.

Figure 1: Creating a new GitHub project is easy.

Figure 2: The developer's public key is used for identification purposes on GitHub.

The First Push

Once the public key has been deposited with github.com, git push origin master synchronizes the local Git repository that I migrated from CVS with what is currently an empty repository on GitHub. Following this, the web page at http://github.com/user/project will show the project, including its full history, and give other developers an opportunity to contribute (Figure 3).

Figure 3: The Git repository, migrated from CVS, has finally arrived at GitHub.

Fork as Fork Can

If another GitHub user, call him the open-source-dude, stumbles across the project and discovers a bug or would like to contribute an improvement, he can create a fork by pressing the project's Fork button (arrow in Figure 4). This creates a copy of the original repository and gives the user write access to the copy. Again, the Dude has to deposit his public key with GitHub because he'll have write access to the forked project. Figure 5 shows the project belonging to open-source-dude.

Figure 4: Fork isn't a bad word at GitHub.

Figure 5: Another project has been forked.

To introduce changes, open-source-dude runs the git clone command to create a local clone of the fork (Figure 6). In typical Git style, and this would be impossible in Subversion or CVS, the local copy not only includes the latest version of the project, but all previous versions, starting with the first check-in. The git log command, with the HEAD~3.. parameter, shows the messages for the last three check-ins.

Figure 6: Creating a local clone of the forked project.