This is based primarily on this guide.
The status of the file has been promoted from untracked to staged, which means the file is ready to be added to the repository. Untracked/unstaged and staged are two of the four states commonly used by Git. Technically, untracked and unstaged are different states, but the distinction is rarely important because git add tracks and stages files at the same time.
The main Git status sequence for a changing file.
One common issue when learning Git involves figuring out when to make a commit. Unfortunately, there’s no simple answer, and real-life usage varies considerably. My best advice is to make a commit whenever you’ve reached a natural stopping point, or when you’ve made enough changes that you’re starting to worry about losing them. In practice, this can lead to inconsistent results, and it’s common to work for a while and make a large commit and then make a minor unrelated change with a small commit. This mismatch between commit sizes can seem a little weird, but it’s a difficult situation to avoid.
Many teams (including most open-source projects) have their own conventions for commits, including the practice of squashing commits to combine them all into one commit for convenience.
Git lets us ignore files to be committed using a special hidden configuration file called .gitignore Example: content in the file .gitignore
.DS_Store
Wildcards can be used to ignore many files
*.tmp
Or a directory can be ignored also
tmp/
cached/*
Or all except a file
!/log/.keep
One of the most powerful features of Git is its ability to make branches, which are effectively complete self-contained copies of the project source, together with the ability to merge one branch into another, thereby incorporating the changes into the original branch. The best thing about a branch is that you can make your changes to the project in isolation from the master copy of the code, and then merge your changes in only when they’re done. This is especially helpful when collaborating with other users; having a separate branch lets you make changes independently from other developers, reducing the risk of accidental conflicts.
The main repository evolution is a series of commits, and the branch effectively represents a copy of the repo at the time the branch was made.
$ git help
Or for a specific command
$ git help <command>
Scrolling your mouse to see all command explanation on the command line
$ git config --global user.name "Your Name"
$ git config --global user.email your.email@example.com
Configuration information would be stored in ~/.gitconfig
$ git init
$ git status
$ git add -A
Or
$ git add .
Or add only a file
$ git add <filename>
$ git rm --cached <file>
$ git commit -m 'Message here'
Let write commit messages in the present tense using the imperative mood, as in “Initialize repository” rather than “Initializes repository” or “Initialized repository”.
And when to include changes to stage, add more parameter -a
$ git commit -a -m 'Message here'
or
$ git commit -am 'Message here'
Note that the -a option includes changes only to files already added to the repository, so when there are new files it’s important to run git add -A to make sure they’re added properly.
If you did some typo in commit message, change it by this
$ git commit --amend
$ git log
or use parameter -p to show the full diffs represented by each commit
$ git log -p
$ git remote add origin https://github.com/<name>/reponame.git
$ git push origin master
$ git push
or
$ git push origin master
master can be changed into another branch.
or
$ git push -u origin master
The -u option to git push sets GitHub as the upstream repository, which means we’ll be able to download any changes automatically when we run git pull.
$ git diff
or checking diff with other branch from current branch
$ git diff <branch>
$ git checkout -b <new branch>
-b option is to create new branch.
$ git checkout master
$ git branch -D test-branch
Note here that we need to use -D instead of -d to delete the branch because test-branch is unmerged.
$ git branch
- indicating the currently checked-out branch or
$ git branch -a
-a option means all.
$ git checkout master
$ git merge <branch>
$ git push
$ git checkout -f
-f option means 'force'
It’s worth noting that git checkout -f itself is potentially dangerous, as it wipes out all the changes you’ve made, so use this trick only when you’re 100% sure you want to revert to HEAD
We should run git log first to get SHA code of the commit identifier we want to recover
$ git log
Then run command with SHA code
$ git checkout <SHA code>
$ git pull
Because of the potential for conflict, it’s a good idea to do a git pull before making any changes on a project with multiple collaborators.
$ git config --global alias.co checkout
So new you can checkout by the command:
$ git co <branch>
- Pro Git by Scott Chacon and Ben Straub
- Git path at Code School
- Git tutorials by Atlassian (makers of Bitbucket)
- Tower Git tutorials