With your local repository set up and connected to your remote repository at Github.com, you're ready to start tracking changes to your project.
Everything we have done to this point has been setup steps that you only do once when starting a new project. Everything that follows reflects the kind of Git work you'll do on a day-to-day basis.
hello-world directory, run
$ git status
At this point, there should not be any changes of note, as you haven't made any modifications to the
/Applications/MAMP/htdocs/hello-world $ git status On branch master Your branch is up-to-date with 'origin/master'. nothing to commit, working tree clean
Let's make a change to demonstrate how git works.
Make an edit to the
README.md file, amending the title to read:
# Practice repository for DWA
With that change saved, run
git status again, and it should pick up on the change:
/Applications/MAMP/htdocs/hello-world $ git status On branch master Your branch is up-to-date with 'origin/master'. Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: README.md no changes added to commit (use "git add" and/or "git commit -a")
Let's imagine this was some important change to the code base, and we'd like to check those changes into our version control history.
To do this, we'll stage (aka
add) this new file with the following command:
$ git add README.md
git status again, and you should see you have a file waiting to be committed:
$ git status
/Applications/MAMP/htdocs/hello-world $ git status On branch master Your branch is up-to-date with 'origin/master'. Changes to be committed: (use "git reset HEAD <file>..." to unstage) modified: README.md
Next, commit this change using the
commit command, plus the
-m flag which indicates we'll also be including a commit message:
$ git commit -m "Modified title in README file."
/Applications/MAMP/htdocs/hello-world $ git commit -m "Modified title in README file." [master 1cb73b6] Modified title in README file. 1 file changed, 1 insertion(+), 1 deletion(-)
Finally, push this commit to Github.com with the following command:
$ git push
/Applications/MAMP/htdocs/hello-world $ git push Counting objects: 3, done. Writing objects: 100% (3/3), 290 bytes | 0 bytes/s, done. Total 3 (delta 0), reused 0 (delta 0) To github.com:susanBuck/hello-world.git e646ab3..1cb73b6 master -> master
Double check this change made it to Github.com by refreshing your repository's page.
Let's run through that procedure again, but this time we'll make three changes:
First, edit your
README.md file again adding the URL for this course below your title:
# Practice repository for DWA <https://dwa15.com>
Second, find an image (any image will do) and save it in a new directory called
/hello-world/images/. You'll see with this example how git can track changes to files other than code/text, such as images.
Finally, create a new file called
index.php and include the following code, replacing the
alt attributes with your own image details:
<h1>Hello World!</h1> <img src='/images/kitten.jpeg' alt='Adorable kitten'>
(Don't worry about viewing this HTML code in the browser yet; we'll address that in the next note set).
After making these three changes, run
git status to see the results.
Now let's track these changes in Github.
You can stage the files one at a time:
$ git add README.md $ git add images/kitten.jpeg $ git add index.php
Or you can use this command to stage any changed or new files:
$ git add --all
Once your changes are staged, commit:
$ git commit -m "Update README file; added index file with an image."
And finally, push your commit:
$ git push
Check your repository in Github.com to make sure the commit is there.
“Git is all about composing and saving snapshots of your project and then working with and comparing those snapshots.
An important concept here is that Git has an index, which acts as sort of a staging area for your snapshot. This allows you to build up a series of well composed snapshots from changed files in your working directory, rather than having to commit all of the file changes at once.
In a nutshell, you will use
git addto start tracking new files and also to stage changes to already tracked files, then
git diffto see what has been modified and staged and finally
git committo record your snapshot into your history. This will be the basic workflow that you use most of the time.”
Git is an open source program for tracking changes in text files. It was written by the author of the Linux operating system, and is the core technology that GitHub.com [...] is built on top of.
Stage aka add
In Git, you have to add file contents to your staging area before you can commit them. If the file is new, you can run
git add to initially add the file to your staging area, but even if the file is already “tracked” - i.e., it was in a previous commit - you still need to invoke git add to add new modifications to your staging area.
A commit, or "revision", is an individual change to a file (or set of files). It's like when you save a file, except with Git, every time you save it creates a unique ID (a.k.a. the "SHA" or "hash") that allows you to keep record of what changes were made when and by who. Commits usually contain a commit message which is a brief description of what changes were made.
Pushing refers to sending your committed changes to a remote repository such as GitHub.com. For instance, if you change something locally, you'd want to then push those changes so that others may access them.
Pull refers to when you are fetching in changes and merging them. For instance, if someone has edited the remote file you're both working on, you'll want to pull in those changes to your local copy so that it's up to date.
If you get a message about
src refspec master does not match any.after trying to push— it means you have not yet created a commit.
git statusis a command you should take advantage of frequently; it will give you a sense of what's going on your repository: what has changed, if any files are untracked, etc.
git diffis another useful command to show what changes have been made. You can see all changes with just
git diffor see just the changes on a particular file with
git diff <file>.
If you want to undo changes made to a file that haven't yet been staged, you can use the command
git checkout <file>.
If you stage a file but decide you want to unstage it, run this command:
git reset HEAD <file>. This won't revert any changes to that file (that's what
checkoutdoes), it will just remove it from staging.
If you delete a file from a project, you'll use the
git rm <file>command instead of
git add <file>.