Learn how to support a multiple-developer version-control environment using source-code hosting for git repositories.

Has your shop begun using multiple programming languages? The implementation of new options may not be on the top of the priority list. Code can be developed, priorities could change, staff could change, and by the time you go back to complete something you initiated a few months ago or try to find the source code for something that is deployed, you may have difficulty determining where the source code is or what version was actually deployed. This is where git can help.

Perhaps you have several developers who are developing code on their machines and deploying production code with no organization of the source code. This isn't uncommon, especially when you're experimenting with new technologies and have more than one developer participating in the implementation of these new options.

In my previous article "Use Git to Document and Manage Any Source Code with Version Control," I talked about using git locally on your machine to provide commitment control for your code with change tracking and rollback capabilities, but the real beauty of git comes when you're in a multiple-developer environment because you can have one master copy that is the production version, and then you can create a copy for yourself to work on, which is called a "branch" in git lingo, and another developer can work on a separate branch.

When you commit your changes back to the production code, you merge in the changes that you've made with a complete audit trail. Then, when other developers merge their branches back into the master branch, the changes of the previous developer will not be overwritten.

Public and Private Remote Repositories

When you're looking for a remote repository, GitHub will most likely be the first one that comes to mind because it's very popular, but it's not the only repository available. When you're considering using a remote repository, you need to decide whether you want to share your source code with the world or keep it private so that only you and your team can access it.

A lot of remote repositories provide free access to public repositories, which are intended to be used for open-source code development. Public repositories let anyone download the code so that others can download and modify it. Private repositories require an authorized user name and password to access the code. An initial user will set up the repository and send out invitations for other members to join the team in order to provide access to the code.

Some remote repositories provide only public repositories, some provide only private repositories, and some provide a combination of both. For the purpose of this article, I will be focusing on private repositories. Of course, as with any project, you have to balance versus functionality. Public repositories are typically free, and private repositories usually come at a cost.

Comparing Private Remote Repository Options

For the scenario of this evaluation, suppose you have come up with a great application idea and you have joined a few of your geek friends to start up an independent development team to develop the hottest new application. In this scenario, you will want to share your code with your development team but keep it protected from the rest of the world, and of course, you'll want to keep your expenses at a minimum. With this objective in mind, I put together my "top five" list of options that meet these criteria.

 Figure 1: These are my five favorite remote repository options.

Note: There are smaller and larger options available for most of the sites listed above, but I wanted to list those that support at least five people at minimal cost. These were the top sites that I reviewed; please feel free to post your recommendations in the forums section accompanying this article.

I decided bitbucket.org was the best match because…

• It supports five people, which is the minimum requirement.
• It offers unlimited projects, repositories, and storage.
• And to top it all off, it's free!

Using BitBucket.org Remote Private Repository

To demonstrate the use of a remote repository, I'll assume that you've performed the steps in my previous article (which simply creates a directory off of the root of the hard drive), initialized a local repository within the new directory, created an HTML file, and changed it.

Next, you sign up for an account on bitbucket.org (or the remote repository of your choice) that can provide an online backup and also a place to share your code with other developers on your team.

After you create an account on your remote repository, create a repository and you will be provided with a repository URL that you can use to upload and download your repositories to.

Figure 2: Create a repository at bitbucket.

Now that we have a repository URL, we can upload the local repository that we've already created:

git remote add origin <YOUR_REPOSITORY_URL>

Replace <YOUR_REPOSITORY_URL> with the URL of the repository that you're working with.

git push origin master

Once you have pushed your repository to the remote URL, you will see your commitment history.

Figure 3: You've pushed your repository to the remote URL.

The commits are associated with my account, not because of the name but because of the email address associated with the repository. So it helps if you make your repositories user.email match the email of the repository account.

Changing Your User Name and Email

In my previous article, I set my user name and email in a way that doesn't link to my bitbucket account, so I wanted to change that to match the project I'm working on. If you specify a different user.name or user.email without the -–replace-all option, it will just add the new value. To replace all existing references you would use the -–replace-all option as follows:

git config -–global -–replace-all user.name "Tom Snyder"

git config -–global -–replace-all user.email "This email address is being protected from spambots. You need JavaScript enabled to view it."

To view all of the configuration values, use the list option:

git config -–list

Retrieving a Copy (Clone) of Your Code

Now that you've pushed your code up to the remote repository, you have an online backup that you can retrieve from anywhere. If your hard drive dies, no problem (code-wise anyway). You can fix up your computer and just download your repository and pick right up where you left off.

To download your repository, it's just a matter of using your repository URL with the clone option to download a clone of the master branch.

To emulate another computer, or another user on another computer, let's create a new directory off of the root of the hard drive and call it MCPressOnline2.

To download a copy of the online git repository, execute the following command:

git clone <YOUR_REPOSITORY_URL>

My example would look like this:

Figure 4: Download a copy of the online git repository.

After downloading your copy of the repository, you can see that the files and directory structure are an exact copy of the last time that the original upload was pushed up to the remote repository. Now you can continue using your repository locally, just as you've done before, and push your code up to your local repository as frequently as you'd like. When you start changing files locally on your computer, your local copy will become different from the copy that you have on your remote repository.

For our example, let's add a new text file to our local copy in the MCPressOnline2 folder called readme.txt, which will contain some text. We'll add and commit the file to our local repository as follows:

Figure 5: Commit a change to the repository.

When you commit a change to your repository, it doesn't automatically update your remote repository. You can see that our local branch is one commit ahead of the "origin/master," which is your remote repository. If you push your local repository after the commit, you will see that this message goes away, indicating that the local and remote branches are now the same.

git push origin master

After we perform the push, MCPressOnline2 is the same as the remote repository. But if we go back into the original MCPressOnline folder, which would emulate a different user, you can list the files in the directory to see that it does not contain the new readme.txt file. If you want to synchronize the MCPressOnline folder with the remote repository, you pull the latest master from the remote repository as follows:

git pull origin master

Figure 6: Pull the latest master from the remote repository.

At this point, the next logical step would be to examine what would happen if multiple programmers were working on the same file and attempted to push their changes to the remote repository. We'll save that for the next article, which will be the final article in the series of git articles.

Diversify Your Skills

You'll find that my article content will become more diverse in areas of content, exploring into open source technologies and criss-crossing between RPG articles. I've been asked more times than once, "How do I get started in different areas of software development to keep my skills up to date?" I'm hoping to provide that direction by pointing out some useful technologies that are definitely worth looking into. At the same time, I will be attempting to express the reasons why you would want to use them. I hope you find this new programming journey to be useful to you.

References

Git—Free and open source, distributed version control system

Bitbucket —Remote Git Repository

"Use Git to Document and Manage Any Source Code with Version Control" —Article on using local git repository.