sudo apt-get install git
sudo apt-get insatll tig
brew install tig), gitk (If you install git by using .dmg file, if will be automatically installed)
git init: Transform the current directory into a Git repository, this operation will add a
.gitfolder to the current directory.
git init 'directory': Specify a directory you want to initialize into a repository, if the directory is not existed, Git will create it for you.
git init --bare 'directory': This the
--bareflas is a way to make a repository as a storage facility, opposed to a development environment which will omit the working directory. Shared repositories should always be created with the
--bareflas (ex. central repositories should always be created as bare repositories because pushing branches to a non-bare repository has the potential to overwrte changes), the central repository is bare, and developers local repositories are non-bare.
ssh @ xxx. 2.
cd path/repo, 3.
git init --bare my-project.git. First, SSH to your server. Then, navigate to wherever you's like to store the project. Finally, you use the
--bareflag to create a central storage repository. Developer would then
clonemy-project.git to create a local copy on their development machine.
What is git clone?:
git cloneis sort of like
svn checkoutwhich copies an existing Git repository but except the "working copy" is a full-fledged Git repository.
The different between SVN and Git: SVN is
Central-Repo-to-Working-Copy Collaboration, Git is Repo-to-Repo Collaboration`.
git clone 'repo': Clone the repository located at 'repo' onto the local machine, the original repo can be located on the local filesystem or on a remote machine accessible via HTTP or SSH.
git clone 'repo' 'directory': Clone the repository located at 'repo' into folder called 'directory' on the local machine.
git config user.name 'name': Define the author name to be used in the current repository.
git config --global user.name 'name': Define the author name to be used for all commits by the current user.
git config --global user.email 'email': Define the author email to be used for all commit by the current user.
git config --global alias.'alias-name' 'git-command': Create a shortcut for a Git command.
git config --system core.editor 'editor': 'editor' argument should be the command that launches the desired editor (e.g, vi).
git config --global --edit: Open the global configuration file in a text editor for manual editing.
git configuration files: Git stores configuration options in three separate files, which lets you scope options to individual repositories, users, or the entire system, when options in these files conflict, local settings override user settings, user settings override system settings.
'repo'/.git/config- Repository-specific settings.
~/.gitconfig- User-specific settings. This is where options set with the --global flag are stored.
$(prefix)/etc/gitconfig- System-wide settings.
Recommendation: I recommand you open configuration files and add below into it once and once for all. [user]
git add 'file': Stage all changes in 'file' for the next commit.
git add 'directory': Stage all changes in 'directory' for the next commit.
git add -p: Begin an interactive staging session that lets you choose portions of a file to add to the next commit. This will present you with a hunk of changes and prompt you for a command. Use y to stage the hunk, n to ignore the hunk, s to split it into smaller hunks, e to manually edit the hunk, and q to exit.
The Staging Area: The staging area s one of Git's more unique features, and it can take some time to wrap your head around it if you's coming from an
SVN(or even a
Mercurial) background, it healps to think of it as a buffer between the working directory and the project history.
git commit- Commit the staged snapshot. A text editor will be launched for you to write a commit message, entered a message -> save the file -> close the editor to create the actual commit.
git commit -m "message"- Commit the staged snapshot, use "Message" instead of launching a text editor.
git commit -a- Commit a snapshot of all changes in the working directory (Only includes modifications to tracked files which have been added with
git addat some point in their history).
Difference between Git and SVN- Snapshots are always committed to the local repository, this is fundamentally different than SVN, wherein te working copy is committed to the central repository. In contrast, Git doesn't force you to interact with the central repository until you're ready. You can commit to local repository after a function or module is done, and push them to remote at once, this is a ballance of controling the repository size and the commit review. Just as the staging area is a buffer between the working directory and the project history, each developer's local repository is a buffer between their contributions and the central repository.
Snapshots, Not Differences- Git's snapshot model has a far-reaching impact on virtually every aspect of its version control model. SVN recodig file diffs and Git record snapshots which makes many Git operations much faster than SVN (A particular version of a file doesn't have to be "assembled" from its diffs - the complete version of each file is immediately available from Git's internal database.
git commitcommand record is the time you commit, not the time you
git push, I actually got confused, haha.
git status- The
git statuscommand displays the state of the working directory and the staging area. It lets you see which changes have been
staged, which haven't, and which files aren't being
trackedby Git, and it also include relevant instructions for staging /unstaging files.
Ignoring Files- Untracked files typically fall into two categories: 1.They are files that have just added to the project and haven't been committed yet. 2.They're compiled binaries like
etc., the compiled binaries will make it hard to see what's actually going on in your repository, for this reason, a special file called
.gitignoreis for you to add the files you want to ignored, and these files will not appearing in
git status. (An example of
.gitignorefile content: ..swp)
git logcommand displays committed snapshots. It lets you
listthe project history,
searchfor specific changes. While
git statuslets you inspect the working directory and the staging area,
git logonly operates on the committed history.
Identification- the 40 character string is an SHA-1 checksum of cmomits contents. This serves two purposes, First, it ensures the integrity of the commit - if it was ever corrupted, the commit world generate a different checksum. Second, it serves as a unique ID for the commit. The idea behind all of these identification methods is to let you perform actions based on specific commits.
git log- Display the entire commit history using the default formatting. If the output takes up more than one screen, you can use Space to scroll and q to exit.
git log -n "limit"- Limit the number of commits by "limit" . For example, git log -n 3 will display only 3 commits.
git log --oneline- Condense each commit to a single line. This is useful for getting a high-level overview of the project history.
git log --stat- Along with the ordinary git log information, include which files were altered and the relative number of lines that were added or deleted from each of them.
git log -p- Display the patch representing each commit. This shows the full diff of each commit, which is the most detailed view you can have of your project histo ry.
git log --author="pattern"- Search for commits by a particular author. The argument can be a plain string or a regular expression.
git log --grep="pattern"- Search for commits with a commit message that matches "pattern" , which can be a plain string or a regular expression.
git log "since".."until"- Show only commits that occur between "since" and "until". Both arguments can be either a commit ID, a branch name, HEAD, or any other kin d of revision reference.
git log "file"- Only display commits that include the specified file. This is an easy way to see the history of a particular file.
git log --graph --decorate --oneline- A few useful options to consider. The --graph flag that will draw a text based graph of the commits on the left hand side of the commit messages. --decorate adds the names of branches or tags of the commits that are shown. --oneline shows the commit information on a single line making it easier to b rowse through commits at-a-glance.
Used to do- 1.checking out files, 2.checking out commits, 3.checking out branches.
checking out a file- Checking out a file lets you see an old version of that particular file, leaving the rest of your working directory untouched.
git revert "commit"- Generate a new commit that undoes all of the changes introduced in commit, then apply it to the current branch.
git branch "branch-name"-
what is git checkout command-
git checkout "new-branch"-
git checkout -b "new-branch"-
git checkout -b "new-branch" "existing-branch"-
what is git merge- Merging is Git's way of putting a forked history back together again.
git merge "branch"- Merge the specified branch into the current branch. Git will determine the merge algorithm automatically (discussed below).
git merge --no-ff "branch"-
git commit --amend
git rebase -i
git remote: List the remote connections you have to other repositories.
git remote -v: Same as above command, but include the URL of each connection.
git remote add 'lname' 'url': Create a new connection to a remote repository. After adding a remote, you'll be able to use 'name' as a convenient shortcut for 'url' in other Git commands. Note: lname is short for link-name.
git remote rm 'name': Remove the connection to the remote repository called.
git remote rename 'old-name' 'new-name': Rename a remote connection from 'old-name' to 'new-name'.
originRemote: When you clone a repository with
git clone, it automatically creates a remote connection called origin pointing back to the cloned repository, this behavior is also why most Git-based projects call their central repository origin. Note: I like
originis also mean TRUTH.
URL's: Git supports many ways to reference a remote repository. Access a remote repo via the HTTP and the SSH protocols is two easiest ways. HTTP allow anonymous, read-only access to a repository, but you can push commits to an HTTP address. If you want to push commits, you need a valid SSH account on the host machine, about SSH key, this will help: Generating SSH Keys.
git fetch 'remote': Fetch all of the branch from the repository, and download all of required commits and files from the repository.
git fetch 'remote' 'branch': Only fetch specified branch.
git pull 'remote':
Fetchthe specified remote's copy of current branch and imediately
mergeit into the local copy. Same as the command :
git fecth 'remote'+
git merge origin/'current-branch'.
git pull --rebase 'remote': Same as the command:
git fetch 'remote'+
git rebase 'remote',
--rebaseoption can be used to ensure a linear history by preventing unnecessary merge commits, many developers prefer rebasing over merging, this put your changes on top of what everybody else has done, examples:
git checkout master
git pull --rebase origin.
git push 'branch': Push the specified branch to 'remote', to prevent you from overwriting commits, Git won't let you push when it results in a non-fast-forward merge in the destination repository.
git push --force: Same as above, but force the push even if it results in a non-fast-forward merge, do not use the
--forceflag unless you're absolutely sure you knon what you are doing.
git push --tags: Sends all of your local tags to the remote repository which are not automatically pushed when you use