Before AirPair, understanding git, the language of Github, even on a simple awareness level was extremely foreign to me. I’ve read a book or so and browsed through countless blog tutorials about git and until a few days ago, felt intimidated about performing git actions successfully, beyond a google search and paste style, rooted in sort of a situational desperation.
Today, I’m going to share what I’ve been learning and practicing with git. And as everyone before me has said, it’s really not that hard once you understand a little background about version control systems. My goal hear is that some of you will feel the same way after the post. And as always, if you have something to add, feel free to leave a comment.
Lets start from scratch, doing so may provide a more robust illustration of the process, than jumping in at any other point of the development process.
Command-line steps for a new Rails App
We start things off by typing
rails new your_app_name or
rails new your_app_name --database=postgresql in your terminal. I’ve been taught to stick with postgresql so I can push to heroku easily and often. The next step is to add our dependencies to the project. We can do this by typing
bundle install or just
bundle which is one of the many aliased commands included in our environments shortcut command bank. Adding dependencies, at least in this instance, may be better understood by just saying adding/loading our gemfiles to the project.
This is what our terminal will resemble if all goes well:
Command setup for our remote repository push
Now that we have our gems bundled and ready to go, lets change into our new project_name’s directory and initiate git. Type
cd your_apps_name and then
git init. John Davison correctly pointed out to me yesterday that there is only a need to type that command once, after we’ve created our app for the first time, like for today’s post. In future changes of our project directory, we’ll skip straight to this next step.
git status to see the current state of our files. I learned that this command is used as liberally as breathing, read: apply liberally, because it gives us the status of our local workspace at any time and point of our choosing. Since this is a new application, there won’t be much going on until we actually create some files for our project.
So lets create a simple user resource to demonstrate how that will look when we check out the status of our local repository.
rails generate scaffold User or the aliased
rails g scaffold User
into the console. This just generates some test files, a User model, and an associated controller with views to match.
Now to receive another status update from git. Type in
git status again and notice the changes.
The statement on our terminal shares with us whats happening. The third line in the image lists the changes we’ve made to the files in our local repository, and reminds us that these changes have not yet been staged for commit.
git status report also includes a helpful reminder of what the next logical steps should be. If we look down at the part of the image starting with
modified: we can see the file(s) that were changed.
git status finishes its report to us by saying that we have yet to add the above
modified: changes to our staging area. We’ll use the command that they suggest to make the next move toward getting our new application pushed to github.
git add gemfile or
git add . if we want to add all the files that have been modified.
Commit and push to our remote repository
Lets start by receiving another status report, to confirm our last move went off without a hitch.
git status again, and you will see something in your terminal that resembles this:
So now our status report informs us that we are ready to commit our modified files. We can achieve this by typing
git commit -m "Change gemfile" in our terminal. The
-m "Change gemfile" is a message included in our commit, so that we, or anyone else looking at our snapshots can have some guidance as to whats going on at this particular point.
Heres what your terminal result will resemble:
[master 314e175] is the name of our snapshot, with the message we added acting as it’s alias for us to make quick sense of. Our commit changes can be seen underneath our snapshot name and alias.
Now to push our commit into github. Typing
git push origin master into our terminal, connects to our remote repository and makes the changes.
Success at last!
If you would like help setting up your git and repositories on a mac environment, leave a comment, and I’ll do my best to aid you.
Better yet you could schedule an hour with AirPair.Here’s what my session inspiring this post looked like: