see the contents by cd'ing into the new folder called html5-boilerplate:
$ cd html5-boilerplate
in this new cloned repository, you can see the whole history of the project by looking at the git-log:
$ git log
if you want more details about what changed in a specific version, use git-diff and the hash id to compare it to previous changes:
$ git diff b59c1cc00e1f6a25a12a224080a70287fa33e4da
lines that have been added will begin with a + sign, those that have been removed will begin with a - sign
to find out which files where changed recently, type:
$ git status
this will show you files that are:
"Changes to be committed" that is, changed but not updated (staged)
"Changed but not updated" that is, staged but not committed
Adding and Committing Changes
changing and saving files isn't the same as committing them
before you can commit a change, you need to git-add the file to what is called the "staging area"
The Staging Area & Using Git Add
the staging area is also known as the index
what it's used for
the staging area is designed so that you can craft your commits regardless of when you edit the actual code
helps you break down your commits by features rather than by when you edited the text files containing them
considered a solution to the "tangled working copy problem"
a good practice is to submit logically or functionally independent files in separate commits
for example, you can break down your commits by features that are being changed or updated
why features?: this allows you to move those features around easily later on
if you want to bring a whole set of features from one branch to another, it's much easier to have them within their own commits.
to stage a change, type:
$ git add css/style.css
Adding a Brand New File with Two 'add's
you need to first 'add' it to the repo, and then 'add' it to staging
untracked files can be identified with 'git status'
to add every file in a directory to the staging area, type:
$ git add .
How Git Looks at Your Files & Using the Patch Option
git doesn't actually see your code as discrete files
it sees everything in your repository as one big hunk of text
this is how it can keep track of diffs and renames across files within a repository
this comes in handy when you're working on different features that may happen to be in the same file, and you want to break them into separate commits
there is a special option called 'git add --patch' which allows you to stage code by "hunk" rather than by a whole file
to commit a change, type:
$ git commit -m "killed the hot pink selector"
to confirm the commit (optional), type:
$ git log
Shortcut: Add and Commit a Change in A Single Command
type:
$ git commit -am "added some random text"
Branching
Why branch?
When you have an idea for a new feature that is too big for a single commit
What is a branch?
A copy of the state of a repository at any commit
The "master" branch
this is the default branch that every Git repository starts out with
there is nothing special about the master branch
but it is usually considered the "stable" branch alongside developmental or experimental branches for new features or bug fixes
to see all branches, type:
$ git branch
you will see something like: * master
the star marks the current branch
to create a new branch and move to it, type:
$ git checkout -b development
git will always keep track of which branch you're "sitting on"
and it will stay there unless you explicitly checkout another branch
this will be important when we decide to merge
checking out a branch Caution
when you checkout a branch, the files in your working directory will change in place to wherever the code happens to be in that branch
? "change in place" ?
this means git will actually "edit" your files to match the version in the branch you are checking out
you will see the changes "flip" in your text editor
nothing will be lost AS LONG AS IT IS COMMITTED in one branch or another
make sure you have saved files in your text editor BEFORE checking out another branch because your non-git-aware changes could be overwritten
? what is a non-git-aware change ?
Note: Git doesn't care about when you use an application's save function, only when you deliberately use the commit command.
another caution: If you make a change to newfile.txt, but do not stage it, and then run 'git checkout newfile.txt'. it will revert the file to its state in the last commit with no undo.
? author doesn't explain why you would point a checkout at a file ?
Merging
suppose we finished our new feature on the new development branch and we want to merge it with our master branch because it's ready to ship
to merge, we must checkout the branch we want to merge into and then merge the target branch into it
checkout the branch we want to merge into (the master branch):
$ git checkout master
merge the target branch (development) into it:
$ git merge development
now all of your changes in development will be merged with master
now, to clean up, delete the development branch:
$ git branch -d development
Moving a File from One Branch to Your Current Branch
use:
$ git checkout development myfile.txt
it will replace the file in the current branch (if it exists) with the development version of the file