Day 3

Today was thrown into the torrents of Git and all of its amazing snazzy fancyness. And! I did it all through the terminal too, no fancy GUI for this boy, just a nice easy simple terminal with absolutely all the functions I could ever want, need, think of or work with! I have had the course tell me about GUI's and how they can be real nice and help explain bits a little easier but none of them can ever intergrate all the functions of the terminal.

Today was my first introduction so I didn't do anything too crazy, I got to save some fun bits for later, today I made my first repository on Got Hub and cloned it to my local machine with the given SSH, thank you Got Hub for generating that for me, and then I was off to the races! I made the read me file and a test text file! Made edits in VS code, opened it through the terminal, and then saved them all locally.

I then took all my lovely and little changes and popped them over into the staging area, my gut status command showed me everything I had changed but not set to be staged in a beautiful bright red was very useful, and the while that chilled there waiting for it's snapshot bus over to the hub I read all about the useful yet potential pit falls of commited messages.

These beautiful notes can help you easily see the what and why of changes through the git log, or git shortlog for a more condenced version grouped with users and dates, if used well these can be a life saver when trying to quickly look back on versions and see what happened where and can be utilised for easy roll backs if and most likely enevitably needed. First lesson on these was to pick a convention and stick with it! But there is a good basic framework most follow and a good note was keep the subject/title to 50 characters and use the imperative mood, spoken or written as if giving a command or instruction, makes it sound rude at first but apparently you get used to it and helps alot. Then your body/further message is the what and why not the how the actual changes should show the how.

Also we should strive for atomic commits, these keep commits to be smaller ,usually, with each change or task being one commit. So that several changes are done separate not all in one. Then if a commited change needs a rollback you can roll back that one issue and merge the other branches to keep fixes easy, especially for any layouts along with any behind code and additional resources, then it shouldn't break anything if you need to roll back on a bad design change no one liked!

So yer that's all I did and got to enjoy! Wasn't much but I got my first public repository down so it's a step in the right direction! Next time should be more and bigger!