Git for dummies by a (relative) dummy

[Neurotoxin]

Git for dummies by a (realtive) dummy

Prerequisites:
A desire to learn and to contribute to open source projects
Windows(Specifically for this guide though you can probably follow along on other OS's too)
A Github account
Git Extensions (I'm using this because I'm familiar with it, you can use a different Git interface but setting it up is on you Or you can use the command-line but knowing commands is also on you and if you already know them, you probably don't need this guide)
Git Ex install guide
or, and I suggest using this guide:
[Setting up Git, Git Extensions and GitHub account

I'd like to note, GitEx may or may not actually include some of the options you see in the screenshots during install. I already had a Git program installed and wasn't asked about MsysGit or KDiff and had to install them manually (They are easy, google and setup with default settings). On to the guide:



Do you already know Git? Go Away! Just kidding, feel free to stick around and drop some pointers. This article is aimed at people completely new to Git. For our purposes I'm assuming you meet the prerequisites and have setup GitExtensions with your Github account (see: Setting up Git, Git Extensions and GitHub account).

So, how do I use this exactly? Well, let's say you have your own project. You are the sole maintainer and want to make changes (substantial or not so substantial) without breaking your already working code. You've already pushed your repo to git... oh, you haven't yet because the guide didn't tell you how to make your Project folder a repo? Alright, so open up GitExtensions, if it's open already, close and reopen so we're all on the same page and at the start screen. You'll see this (please excuse my jittery circling job):


Before we clone the Github Repo, we need to have one. So head over to Github and Create a Repository with the same name as your project. When you're done with that, come back to GitEx and click Clone Github Repository. If you have everything setup right, you should see something like this:


Ok, before continuing, go back up your project. Then set the destination directory to your Projects directory (aka if you have Visual Studio/Project/MyProject point it at Visual Studio/Projects) Basically you want the parent directory of your project. Alright, now select the repo you made (with the same name as your Project's Folder), make sure the Create Directory is you project's directory and hit clone. Oh? You had an error, the directory exists and isn't empty? That's why we made a backup, Delete it, Clone it, then put your files back in.

After you put your files back in, you'll have to commit your changes so that Github has the right files, so click that orange Commit button up top.Before we commit our existing files, let's make sure we're only including the necessary ones. Click Edit .gitignore. on the right side you'll see Add default ignores, which is good enough for our purposes so click that and save. Now, go ahead and hit that orange commit button at the top.

On the left side is the staging area, files that have changed will be in the top, files you're commiting will be in the bottom. before we do anything here Click Working Dir Changes at the very top and select edit ignored files. If you were to commit now, all those excess files the IDE creates would be included and they're not needed. For our purposes the default ignores are good enough, almost too much but we'll just use those for now (or you can google .gitignore syntax and customize it here). So hit add default ignores (or customize the list) and save.

Ok, the double arrow button on the right side will stage all changed files to be committed and being this is the initial commit, click it. The text field on the bottom allows you to keep a changelog of sorts. It's usually good practice to commit a single change at a time, so if you mess up somewhere, you can easily roll back that single change. Be verbose with your changes so you know exactly what you did, when you did it and why. Since this is our first commit adding everything to the repo just put in Initial Commit or something of the sorts (Hello World, Hello Kitty, Bananarama FilppityShooBop - Just kidding, try to keep it professionalish - nobody is making you but it will be easier for yourself in the future unless they are code phrases you have mapped out to something somewhere *Suspicious look*).

The Commit button will store your changes as a checkpoint on your local machine only. Commit and push Will store changes and update your remote branch's (github) copy. Let's get that code into the clouds and hit Commit and push. If you added a password to your SSH key you may be asked for it. Viola, your code is now safe (or as safe as it can be) in the cloud.

But why did we go through that effort when I could have just stashed the code in my zip file?

Accessibility and control:
You can make branches from here for making changes, keeping your main code sterile and in a working state while you develop new features or add/remove things that may break everything. If you get everything in your new branch working right, it's a single press of a button to merge into the Master branch and make that the new base for your next Branch.

Extendability:
Anyone with a github account can make their own fork of your code, modify it and push it into their fork. Say Modder C#Master creates an awesome new feature. He can push a button to submit his code to you. If you like the feature you can press a single button and everything is up to date. Then you can pull the changes to your local machine, compile and release, just like that. Say Modder C#Noob has an awesome feature but it may be buggy, they can also submit a pull request which you can pull into your own sterile fork for testing. You don't have to accept pull requests, you can always close them as well.

A scenario:
You write a mod. ModderB makes a feature but it has a few bugs that he can't figure out. He submits a pull request anyway. You make a new fork of your master code and pull his changes into it. You can now modify what he's done, fix it up and push it back into your development branch. If all goes well, it's a single button press from there to update the Master branch with the new code.

Scenario 2:
You're sitting back, enjoying you first Coffee after a successful release of your mod. Here come the bug reports. "Well, I can fix that, just remove this line, change that line, ok everything should work. Build, quick test... seems fine, let's release the fix" More reports, now something that WAS working perfectly doesn't work at all. "Where did I go wrong, what line did I remove again?" Unless you keep local backups of your source at each revision and release, now you have to crawl through every single one of your classes or your miles of code to find that ONE line you changed. Git (paired with KDiff) shows you exactly what changed at each commit so you can easily find that thing you broke and fix it or, if it's completely unclear, roll back  to your last working state and go from there. Change example:


I hope this helps someone out there get into open source collaboration.

Post 2 to be reserved for "Forking like an Animal".

[Neurotoxin]

Reserved for Forking Like An Animal and IDE Integration.

[longbyte1]

Or just use GitHub for Windows, which is a lot simpler, right?

[Neurotoxin]

Or just use GitHub for Windows, which is a lot simpler, right?

Yeah it's easier, but in my opinion it's nearly worthless. The last time I used it, 3 out of 4 commits required me to use the commandline anyway because the application errored in submitting. If I wanted to use the commandline, I would've used that in the first place. Since switching I've had no problems and Github for windows doesn't really help you learn anything about Git except push a button and type some stuff.

[StorymasterQ]

Are you saying Git for Windows are for actual gits?

[Neurotoxin]

Are you saying Git for Windows are for actual gits?

Haha, I don't think dummies are, by definition, unpleasant. By proxy, in some cases, I suppose you are right but definitely not all.

I misinterpreted that, kinda. To me Github for windows is a git, not necessarily the people using it. If you or anyone else likes it, go ahead and use it, but for me it has been nothing but a problem.

I feel, even if it's not directly exposing you to commandline uses, a more full featured Git client gives FAR more potential for learning than the over-simplified Github for Windows software gives. It makes a good way to get comfortable with using it to start but beyond that there's nothing to learn from it (Besides when it inevitably errors and forces you to use the commandline to fix it).

One of the many issues I've had with it, I changed ONE character in my AssemblyInfo.cs, representing a new version, GfW decided I had completely deleted the file which I didn't notice before pushing. Then it decided I had completely remade it, well ok, I can come back from this, *hits commit* "Github for windows failed to commit". Repeat. Restart computer, try again, still fails. Ok, commandline.. 3 seconds later, commited and pushed.. WTH GfW?

[Bruvvy]

lol