21. Dezember 2013
[ English ]
Learning Ruby on Rails, Day 2 (Git Repository, GitHub)
I continued following my online course and set up a local code repository using Git. I studied some Git Basics before proceeding to set up an account on the public shared code repository GitHub. This was helpful, because I was familiar with CVS (Concurrent Versions System, a different version control system) and Git has quite a different model.
Every time you commit, or save the state of your project in Git, it basically takes a picture of what all your files look like at that moment and stores a reference to that snapshot.
Git appears very well thought-through and quite accessible to me. I was glad for the straightforward instructions and explanations.
I created an online repository on GitHub for the course's test project ("facebook on rails") and generated the test project locally (that's a one-liner command on the Terminal - you basically say "rails, make me a new project" and it generates the complete directory and file structure to get going). I connected the local project to the online-repository following simple steps.
I set up the connection between my local git repository and my GitHub account based on HTTPS as described here rather than using SSH as described in the course. I will see if this bites me in the ass later.
A controller ("pages") with an action ("home") is created via the command line. At this point I couldn't really figure out what that means, but the result is that the app, running on my local server, now has a homepage that I can edit. The source directory shows a section for the controller, and one for the view (_of_ the controller _with_ its action if I understand correctly). The view is HTML-code at the moment, in an .html.erb file.
My upcreeping anxiety was pacified by a brief review of Model View Controller basics. Maybe that time at university actually served for something.
The "controller" seems to be "what the thing actually does" (in this case: "make pages"), the "action" "one way of doing the thing" (in this case: "make a page of the type 'home'"), the "view" is "how the thing shows up" (in this case:
I proceeded to download Bootstrap, a framework for fast front-end development and set it up in my test project. (Very straightforward: you drop some .js and .css into two folders and connected them to the app with two lines in files in the "assets" directory. Simple.) Tested it on the local server: works. "Hello World" looks prettier now.
git status shows me what has changed in my local repository: There have been a number of new files added to the project (the new controller, view and assets) that are not yet tracked in git.
I would have missed this: New files dropped into the project directory need to be explicitly added to the repository for tracking. They don't get added/tracked automatically. Good to know.
There are also some modified files marked "not staged for commit": Local files need to be explicitly staged to then be committed to the repository in a next step. They don't move to the staging area or the repository automatically.
"Working directory, staging area, and git directory", from Git Basics
git commit -m "Added homepage, added bootstrap" stages the current snapshot to be committed.
git push -u origin master then pushes the content of the staging area into the repository.