goals do
goal "Create a local git repository"
goal "Add all our files to the git repository"
message "In order to publish our application, we need to add our application and any changes we make over time to a \"revision control system\". In our case we're going to use *git* because it is (relatively) easy and it is what our app server, *Heroku*, uses."
end
steps do
step do
message <<-MARKDOWN
Let's set up Git, a way to track the code that you write tomorrow.
MARKDOWN
console_with_message "Type this, but with your full name in the quotes:",
'git config --global user.name "First Name Last Name"'
message <<-MARKDOWN
The `--global` option tells Git to set your name system-wide, instead of in only
one place.
Now let's tell Git what your email is.
MARKDOWN
console_with_message(
"Type the following, replacing the email with your email in the quotes:",
'git config --global user.email "your_name@your_email.com"'
)
end
step do
console "git init"
message "You'll get a message like this:"
message "> Initialized empty Git repository in /vagrant/railsbridge/suggestotron/.git/"
message "It doesn't look like anything really happened, but `git init` created (or initialized) a Git repository in a hidden directory called `.git`. You can see the `.git` directory by typing `ls -a` to list all files."
end
step do
console "git status"
message "`git status` tells you everything git sees as modified, new, or missing."
message "The first time you run this, you should see a ton of stuff."
message "The second time you run this, you shouldn't see much of anything."
end
step do
console "git add ."
message "`git add .` tells git that you want to add the current directory (referred to as `.`) and everything under it to the repo."
tip "git add" do
message <<-MARKDOWN
With Git, there are usually many ways to do very similar things.
* `git add foo.txt` adds a file named `foo.txt`
* `git add .` adds all new files and changed files, but *doesn't touch* files that you've deleted
* `git add -A` adds everything, including deletions
"Adding deletions" may sound weird, but if you think of a version control system as keeping
track of *changes*, it might make more sense. Most people use `git add .` but `git add -A`
can be safer. No matter what, `git status` is your friend.
MARKDOWN
end
end
step do
console "git commit -m \"Added a brand-new Rails app\""
message "`git commit` tells git to actually _do_ all things you've said you wanted to do."
message "This is done in two steps so you can group multiple changes together."
message "`-m \"Added a brand-new Rails app\"` is just a shortcut to say what your commit message is. If you skip that part git will bring up an editor to fill out a more detailed message."
end
end
explanation do
message <<-MARKDOWN
By checking your application into git now, you're creating a record of this as your starting point. Whenever you make a change after today's workshop, add it to git. This way, if anything ever breaks, or you make a change you don't like, you can use git as an all-powerful "undo" technique. But that only works when you remember to commit early and often!
MARKDOWN
end
next_step "deploying_to_heroku"