w5d2 - git

So, yes, we did cover the basic git intro today.  After several tutorials online and today's class, I feel I'm getting the hang of it.

Honestly, the concept is pretty simple.  I get the idea of version control.  I even get the idea of branching, pulling from a repository, pushing, etc.  I could, do local commits since the beginning of class, a month ago, thanks to code academy and others.

The information that was missing, and that I'm still not 100% sure on, is "git best practices".  It was never clear from the tutorials that renaming a file would screw up your git commit history.  Renaming files is standard practice in most of the world, as is moving a file while reorganizing content.  With git, though, those things are REALLY BIG DEALS.  Yes, there are work-arounds, but it's just another layer of complexity at this point.

Some day, when I really understand how things work, I'll come back to this idea and write my own tutorial just on 'best practices'.  As I understand them now:

1) One project per (hard drive) folder.  Each project may contain multiple files.
2) One folder to one github repository.
3) Pick descriptive files names at the start, and stick with them.
4) Use git version control rather than renaming files to roll back changes as needed.
5)  Commit only code that is functional, since each commit could potentially be a roll-back point.  Getting broken code from a rollback makes it harder to deal with bugs that arose subsequent to that commit.
6) There are plenty of instructions available for generating ssh keys, and for walking newbies through the establishment of a new repository.  There's not enough on the care of ssh keys and the consequences of screwing up your passphrase.

I think it's all working ok now, though.

One interesting thing I discovered:

In the process of playing with git, I was looking back over older projects.  Early in the first week, I wrote a module that would print out (to the terminal) the names of variables discovered via dir(), with the magic variables removed for clarity.  the script would also print out the type of each variable and its value (via eval(var) - unsafe in settings where strangers can access the code, but probably ok if you're using it for internal debugging).

The point of the table was to illustrate a point made in class about following the variables in your code.  I suppose it's not terribly useful at this point...

The reason I brought it up, though, is that I managed to refactor 4 functions into 4 lines of code with, probably, a gain in clarity.  The "variable_printer.py" script has both the old and new versions, along with instructions for use.

Hooray for refactoring!