If readers are anything like myself they may have tried out git from the command line and decided it was way too ridiculous to be worth the time. A quick google search for git tutorials yields very passionate authors with all too much information that a lot of people just do not care about.
Recently I have found git can be OK. I mostly just want to add files, commit changes, and push those changes to the server. This process is similar for mercurial and perforce, and I just cannot be bothered with more complicated things.
Here is what it looks like to add files to source control, make some commits, and then push all commits at once:
git add "filename" git commit -m "my commit message" git push
It is actually really easy. One gotcha is that -m option, it stands for message (sort of obviously). If you forget this the command seems to thrust you into a vi instance to create a message file. In my case I’ve never used vi, and like most things, I just can not be bothered to learn random crap I don’t care about. -m lets you avoid the vi thing and just type out a message right there.
Seriously, what the heck is this? I’m not some Linux hipster or programmer from 1998, I don’t write code or edit text in strange command prompt consoles. This text editor is context sensitive, so good luck exiting from it without googling for the vi shortcuts and wasting yet more of your life.
Creating a new repo is also easy: git init. Then go create a new repo via browser on your git account and it will prompt you with a nice message, saying to do:
git remote add origin https://github.com/YOURNAME/YOURREPO.git git push -u origin master
Out of all these commands the only annoying piece was that -u command. What is it? I can not be bothered to google random things! I just do not care, and want to put some of my code on github. I ignored the -u flag and just used the command without knowing what it does. In short, these two commands do not need to be memorized and appear on your fresh github repo in your browser when first creating a new repo :)
Merge conflicts were also a breeze. I’ve dealt with merge conflicts in perforce a lot and I can say, doing it in git makes a lot more sense. In the past I’ve had to use complicted GUI merge tools with way too many buttons (like Araxis merge) to get anything done. What a pain. When hitting a merge conflict your source code will have some markup placed inside of it that looks sort of like this:
code higher in file <<<<<<< HEAD your code ======= other code >>>>>>> branch-name rest of code in file
All that needs to be done is to edit the text file and pick which side of each conflict to keep. Dead simple. Delete the markups once done, and add/commit the file like normal. Couldn’t be much simpler!
All in all, as long as we avoid very passionate tutorials, bloggers, and stack overflow answers, git isn’t so bad!
