This file contains all of my reflections while working through Udacity’s Git & GitHub intro course (Lesson 1)
1: How does the diff command help in version control?
Compared to just trying to scan each individual file looking for changes with the text, using the diff command helped narrow down the exact lines which have been modified in each file.
This was extremely helpful because it drastically cut down the time that would have otherwise been spent scanning each line of each individual document.
I hope this reflection was descriptive enough and …
I hope I am not regurgitating the same ideas over and over again.
Shalom!
2: How could having easy access to the entire history of a file make you a more efficient programmer in the long term?
This one’s pretty straight-forward.
Say you’ve been working on a particular program for the last 60 days and everything worked out just fine until day 62 when you added a new “feature”, the availability of over 2 weeks worth of a working program can enable you to easily “roll back” to a previous working version while you work out a new way to add the new “feature” without breaking the other existing ones.
Shit, that line was waaaay to long. But there, my reflection for this question.
3: What do you think are the pros and cons of manually choosing when to create a commit, like you do in Git, vs having versions automatically saved, like Google Docs does?
One big “pro” is the fact that manually commiting enables one to commit at logical points during the course of the development whereas if commits were automatically made, like say every one hour, and you worked on the project for approximately 250 hours, your commit history could be a mess.
4: Why do you think some version control systems, like Git, allow saving multiple files in one commit, while others, like Google Docs, treat each file separately?
I honestly, at this point, have no reasonable answer to that question but hey, there’s no harm in providing a wrong anwser, right?
Well, I think Git, as a VCS, allows saving multiple files in a single commit due to the fact that when writing code, most files in a repository (I hope I used that term correctly) are often dependent on the others – they’re all interconnected – hence a change in one particular file in the repo (again, I hope this was used correctly) would cause/require a change in another file abeit minimal.
5: How can you use the commands git log and git diff to view the history of files?
Pretty straightforword:
First the ‘git log’ command is employed to view the commit ‘history’ of the repo, then the ‘git diff’ command is used to check for differences between two files at any point(?) with the log.
6: How might using version control make you more confident to make changes that could break something?
With the knowledge that even if something breaks, there’s still a handy backup to rollback to? Come on, break on! Never stop making!
7: Now that you have your workspace set up, what do you want to try using Git for?
Well, as it stands, I’m gonna be using Git to properly learn how to use git. Once that’s done, maybe I’ll start using git for version control?
And oh, Github, when are you going to start talking about Github?