Git for game server configuring?

Question

I was wondering if git is suitable for this. So here is the scenario:

We are thinking about hosting a game server. However it is not the case of just downloading files and running the server. It needs to be carefully configured and maintained. It also has scripting capabilities. Also, there will be quite a few "developers" who are going to contribute to this project and would like to have all server files synced on their local machine for testing. So I guess git would be a great tool here.

The problem is, none of us have used git before, and have little or no experience with other repositories. So I have quite a hard time figuring how should everything work.

So there must one one copy (or branch?) of files which are so called stable and these files are used by game server. Another branch would be for developing. I guess any feature a developer scripts or configures should go to this testing branch.

Now what seems to be a problem here is that these two branches should be available on hard disk drive both on the same time. And I get a bit confuse here. Should there be two separate repositories? One for stable server run and other for testing? And then whenever testing repository seems stable enough, I should push these changes to stable repo?

Any help or thought are appreciated.

Answer 1

I would suggest not using GIT. Git is a decentralised source control system which needs some experience.

Might I suggest a simpler solution, like using subversion instead. with subversion, you have 1 central repository, and all your developers will copy the code from there and merge back in when they are done editing files.

Dont bother with creating branches for specific builds just yet. Just use a centralized source repository until you and your team are comfortable with source control. Only then, review your development process and decide how to proceed.

Prematurely dividing your source repository into branches usually makes it difficult to reconcile later.

Answer 2

I agree that subversion is a lot easier to understand if this will be the first time you have worked with a source control system. There are lots of sites that will host your project for free, sourceforge and codeplex are examples, or if you want to host the server yourself I can recomend the VisualSVN server, we use it at work it is easy to setup and maintain and it is free as VisualSVN only charge for Visual Studio licences. I also agree about branching, try not to over complicate matters when you start, you will only need one repository to start with, inside that you should create your project with all the folders and files underneath it. You need to agree with all memebers of the team under what circumstances changes will be commited to the project. This will depend on what state you need to keep the project in. For example if you need to be able to go to the repository at any time to retrieve the files and setup the game server then the rules must reflect this. If you have not already you should get your hands on a good tool for diff/merge operations. We use Winmerge which is free and performs most basic tasks well there are commercial tools out there that support more advance functionality like Beyond Compare and Araxis merge, I have used both and they are good. I would also suggest you check out TortoiseSVN it is a client that helps you commit changes and retrieve updates from the SVN server.

With regards to Branching if at some point you decide to add a large set of changes over a long period of time then you should consider branching the project. Don't take this decision lightly as it can be a lot of work to merge the branch back into the trunk. Once you have got to grips with SVN and are comfortable with the conceptes it is easy to migrate to GIT if you feel the extra features it offers would benefit the team.

Answer 3

There's no reason why you couldn't use it for maintaining the config files etc.

However, watch out if you're also storing large binary files in the git repository as well. Git tracks the history of ALL files that have ever been in the repository (even if they have been deleted). So it's not particularly space efficient with binary data - text is better though (such as config files)