I Am That I Code.

Phill's Learning To Code Blog.

Not so long ago and in pretty close geographical posistion.

(Think - 8/11/14 - Petone)

Well what a week it's been! I probably need some sleep, but how is that possible with so many cool concepts running through my head? I really thought my brain would fall apart earlier in the week - but never fear - it turns out it was just doing a bit of a re-formatting exersize to get some room organised for all this amazingly neat and cool coding I'm being taught.

Ok, this second paragraph is going to be all about something called version control. Version control is a nessersary tool in developing code as it allows for some pretty neat things to occur and stops some pretty tedious things from also occuring. Version control keeps the code being worked on in a 'central' location, visable to all the developers working on it. It allows those developers to take a copy of the code, called a branch, work on it, modify it, even delete it, before uploading and joining it back to the source of that branch. Now here is where it gets tricky - the development team can see who modified what and have the ability to disregard those chages and revert to the previous version. It also allows for different developers to work on different sections of the code simultaneously in a 'many hands make light work' sense. Without being able to monitor modifications and revert changes, developers would have to find bugs by examining the code slowly line by line, searching for what maybe only one small dash in the wrong place. Also, without version control the code would have to be written one line after the other making the process both inefficient and under-productive.

So, now that we know what version control is, I can explain how git tracks changes, (as git is the version control we've been using to learn at Dev Academy). The tracking of changes begins as soon as a branch has been 'added' - that a definitive term in git, - 'added' - It means that a branch has already been taken from the master code, that modifications have been performed on it and now it's ready to begin it's journey to rejoin it's maker.

To add a file command:

So we have a branch, it gets "added". This moves it to a staging area, (and understand that git is now tracking any changes to it as an independant entity), and now it's ready to be 'committed'. The function called 'commit' gets the file ready to be sent. Then, when the file is uploaded, gitHub recognises that this is it's own branch/entity. gitHub then calls for it to have a 'pull request' performed on it, (a way others can check the work and approve of it), before it is authorised to be 'merged', which is a flash way of saying that it will be added back into the original file.

But wait - theres more!

What happens if there has been a change to the code by others, how do you keep a track of those changes? - By linking into the 'master' remote repository and, just as we have 'pushed' an amendment up into gitHub and into the 'master' in the pargraph above, we can fetch down the new modified master onto our computer with command such as:

- to plant the remote repositories location in your computer

- to grab down the latest master copy from gitHub

- to then merge the new master over the old one on your computer.

So, why would you want git to store your code anyway? Well there are many reason that this is a good idea, so I will only touch breify on a few of the ones that stand out most in my mind.

1. Your house burns down or someone knicks your computer.

-Yay if you have git the latest version of your project is sitting happliy on the internet just waiting for you to fetch it.

-Not on git? Oh-no, start your project again from scratch. The same goes for techological meltdowns, accidental coffee misplacement and other random acts of computer unkindness.

2. You want others to be able to analysis your code and help you help yourself.

-Yay if you have git, you can share the code with as many or as little as you like. You can have others with provable history of expertise work on the code, they can show you in the very code itself where something has an opportunity for improvement, collaborate and make life much eaiser.

-Not on git? Oh-no, well you can always go to the library and put your name down on the reservation list for one of those gigantic programming manuals, read and adsorb at least 500 pages of it before relising that you've got the wrong book out and after finally laying your hands on the correct one, you find that what you were trying to doesn't fit. Or you could copy your code to a usb drive, then your only 'breeding homming pigeons' or trusting the mail, away from sharing your code - but who with? Maybe some of those really friendly people on those hacking websites could help - who will no doubt suggest del*.* at some stage and your back at no.1

3. Octocats.

-Yay if you have git. They will dress up, change colours and always look toward you with a loving eye, full of cuteness and as an inspiration to create a better world!

-Not on git? - You're not going to know what you're missing, that's probably for the best. "You wouldn't like them anyway", you'll tell yourself, "no octocats = happy life", and you'll see your lips moving in your bathroom mirror but all you'll hear is:

"...meow-meow bubble bubble, bubble..."