Setting up the workspace

Turns out that isn't as easy as I expected. At least not when git is involved.

Setting up the project was the easy part, obviously. After I upgraded to the most recent versions of Visual Studio and the MonoGame SDK, I created a project and cleaned up the mess created by the project templates, removing faux-documentation from my code and renaming class Game1 : Game to the equally non-descriptive and much prettier MainGame. You can't really blame MonoGame for it, Microsoft's templates for XNA were equally messy.

Before I so much as built the project, I decided that would do for the initial commit. So it was time to set up git. I don't plan to make this project open source for a while, and I don't really want to pay github for a private repo, so I looked into hosting the origin locally.
Someone suggested hosting it via Dropbox, which I'm already using. What a great idea! I get to push stuff even when I'm offline (which I am for multiple hours a day) while also having access to my code from essentially anywhere. It's simple to set up, too! And I'm not being sarcastic here, I genuinely think this is a great idea. But if you've worked with VS and version control before, you probably know what I'm getting at...

When I started coding for the first blog post and built the project, I realized that I didn't commit the build output in \bin and \debug, so I committed just those for my second commit. After changing the code some more and building again, I realized my stupidity: were I to commit my code changes, I'd to also commit the changed executable. And since I'm building the project a lot during testing, I'd do that with every commit to come.

I don't know about you, but I think that's stupid. Since it would be like 10 minutes of work to start over and do it right, I decided to tear down what I had by this point.
I knew VS has version control tools integrated, and I expected them to be aware of a problem like that, so I looked into that next. I found this MSDN page, but the talk about team projects and hosting on either visualstudio.com or a local Team Foundation Server made me worry this was an embraced and enhanced version of git that I couldn't simply host on Dropbox.
Toying with the tools under that assumption proved me (mostly) wrong, however. From what I saw, VS seems to be able to work with any git repo in what's called the Team Window, but can't create a remote, even if it's hosted locally. Therefore, I assume, repos created by MS tools just come with appropriate .gitignore files, like this one by github.

To recap, here are the steps to setting up the dev environment exactly like mine right now, both for you and future me:

1. Prepare for initial commit: set up the project, clean up template cruft, make sure it compiles
2. Paste the appropriate .gitignore file in the project directory
3. Open up the command line and navigate to the project
4. Initialize a repo and commit:

git init

git add .

git commit -m "initial commit"

5. Navigate to the desired origin directory. Make sure the directory name ends in .git
6. Initialize a bare repo:

git init --bare

7. Navigate back to the project directory
8. Set the origin and push your local changes:

git remote add origin E:\Dropbox\GitRepos\project.git

git push origin master

Obviously, you may need to adjust the path to your dropbox directory.

It's already been a learning experience for me, and I haven't even really programmed anything here. I guess this is what I get for never using version control in the five years I've been programming now.
Anyway, this post was probably pretty boring for the git gurus and all three git deniers out there. I'm afraid it'll stay this way for a little while, because I'll be a good citizen and spend my time integrating System.Diagnostics for Tracing and Profiling, so at least one two more posts of me summarizing MSDN and my own experiments...

Until then!