git入门及常用命令

前言

以前在写github的时候，自己用git单机来处理版本控制，在命令行把已经编辑好的代码上传到代码库，因为只有自己操作，在git上面用到的命令也很简单，主要是上传功能：

git add .

git commit -m "commits"

git push origin branch-name

git管理代码两个步骤

现在在公司用git的时候，因为是多人同时作业，所以就会有很多问题，经常提交代码的时候会出现冲突，尤其是多人同时对同一个文件进行修改的时候，这就需要在把自己的代码提交到代码库之前将代码库的最新内容拉取到本地。

1.把代码库的代码导入本地

git clone <repo>

git checkout branch-name

git pull origin branch-name

2.将修改过的代码提交到代码库

git commit -m "commits"

git branch //看一下自己的代码所在的分支

git pull origin branch-name//将最新的代码库拉取到本地，如果有冲突的话处理冲突再commit

git push origin branch-name//将自己的代码push到代码库

git常用命令一览

当然除了这些在工作中最最经常用到的命令之外，下面的表格中还列出了很多git的配置或者稍微高级点的命令，我感觉比较常用的都用颜色标注了。如果想更深入更系统的学习git，可以看参考文章2.

 

Git task	Notes	Git commands
Create a new local repository		git init
Check out a repository	Create a working copy of a local repository:	git clone /path/to/repository
For a remote server, use:	git clone username@host:/path/to/repository
Add files	Add one or more files to staging (index):	git add <filename> git add *
Commit	Commit changes to head (but not yet to the remote repository):	git commit -m "Commit message"
Commit any files you've added with  git add , and also commit any files you've changed since then:	git commit -a
Push	Send changes to the master branch of your remote repository:	git push origin master
Status	List the files you've changed and those you still need to add or commit:	git status
Connect to a remote repository	If you haven't connected your local repository to a remote server, add the server to be able to push to it:	git remote add origin <server>
List all currently configured remote repositories:	git remote -v
Branches	Create a new branch and switch to it:	git checkout -b <branchname>
Switch from one branch to another:	git checkout <branchname>
List all the branches in your repo, and also tell you what branch you're currently in:	git branch
Delete the feature branch:	git branch -d <branchname>
Push the branch to your remote repository, so others can use it:	git push origin <branchname>
Push all branches to your remote repository:	git push --all origin
Delete a branch on your remote repository:	git push origin :<branchname>
Update from the remote repository	Fetch and merge changes on the remote server to your working directory:	git pull
To merge a different branch into your active branch:	git merge <branchname>
View all the merge conflicts: View the conflicts against the base file: Preview changes, before merging:	git diff git diff --base <filename> git diff <sourcebranch> <targetbranch>
After you have manually resolved any conflicts, you mark the changed file:	git add <filename>
Tags	You can use tagging to mark a significant changeset, such as a release:	git tag 1.0.0 <commitID>
CommitId is the leading characters of the changeset ID, up to 10, but must be unique. Get the ID using:	git log
Push all tags to remote repository:	git push --tags origin
Undo local changes	If you mess up, you can replace the changes in your working tree with the last content in head: Changes already added to the index, as well as new files, will be kept.	git checkout -- <filename>
Instead, to drop all your local changes and commits, fetch the latest history from the server and point your local master branch at it, do this:	git fetch origin git reset --hard origin/master
Search	Search the working directory for  foo() :	git grep "foo()"

========下面是一些学习笔记，不完全版========= 

git init: administrator command
usage:
git initgit init <directory>
git init - -bare <directory>  e.g. git init  - - bare my-project.git

Initialize an empty Git repository, but omit the working directory. Shared repositories should always be created with the 

--bare

 flag
(see discussion below). Conventionally, repositories initialized with the 

--bare

 flag
end in 

.git

.
For example, the bare version of a repository called 

my-project

 should
be stored in a directory called 

my-project.git

.

for most projects, 

git
init

 only needs to be executed once to create a central repository—developers typically don‘t use git init to create their local repositories. Instead, they’ll usually use 

git
clone

 to copy an existing repository onto their local machine.

Bare Repositories

The 

--bare

 flag
creates a repository that doesn’t have a working directory, making it impossible to edit files and commit changes in that repository. Central repositories should always be created as bare repositories because pushing branches to a non-bare repository has the
potential to overwrite changes. Think of 

--bare

 as
a way to mark a repository as a storage facility, opposed to a development environment. This means that for virtually all Git workflows, the central repository is bare, and developers local repositories are non-bare.
图不见了

git clone: developer command, obtain a woking copy from central repo. local repo
usage:
git clone <repo>  
git clone <repo> <directory>
e.g.
git clone ssh://john@exmple.com/path/to/my-project.git
cd my-project
#start working on the project

git config
usage:
git config  - - global user.name <name>
git config  - - global user.email <email>
git config  - - global alias.<alias-name> <git-command>
git config  - - system core.editor <editor>
git config  - - global  - -edit

configuration files:
<repo>/.git/config  -repository-specific settings.
~/.gitconfig  -user-specific settings. change with —global flag
$(prefix)/etc/gitconfig -system-wide settings.
if configuration files conflict, local settings override user settings, which override system-wide.

e.g.
git config  - - global user.name “John Smith"
git config  - - global user.email john@example.com
git config  - - global core.editor vim
git config  - - global alias.st status
file contents:
[user]
name = John Smith

email =
john@example.com
[alias]

st = status

co = checkout

br = branch

up = rebase

ci = commit

[core]

editor = vim

working directory <===staging area as a buffer===> the project history
developer’s contributions <===local repository as a buffer===> the central repository

git add: Working Directory => Staging Area
usage:
git add <directory>/<file>/-p

git commit: Staging Area => Local Repository
usage:
git commit -m “commit”/-a

git status: list which files are staged, unstaged, and  untracked.show status of working directory and staging area. you can ignore some kind of files by modify .gitignore file.
usage:
git status
git log: list commit history
usage:
git log -n <limit> //git log -n 3. only display 3 commits.
git log  - -oneline//condense each commit to a single line.
git log  - -stat//more detail, including file changing.
git log -p//show full diff of each commit. most detailed view of project history.
git log  - - author=“name”//name can be a plain string or a regular expression
git log  - -grep=“<pattern>”//
git log <since>..<util>//since and util can be commit ID, branch name, HEAD and so on.
git log  - - graph  - decorate  - -oneline
HEAD refers to the current commit. it be a branch or a specific commit.
~ is useful for making relative references to the parent of a commit. HEAD~3, 3157e~e
.. is useful tool for comparing branches. e.g. git log - - online master..some-feature

git checkout://check out files, check out commits, check out branches.
usage:
git checkout commitID filename
git checkout HEAD filename
git checkout commitID
git checkout branchname

git revert:
usage:
git revert <commit>

git reset:
usage:
git reset
git reset <file>
git reset  - -hard
git reset <commit>
git reset  - -hard <commit>
git reset  - -hard~2

git clean: remove untracked files from working directory. often executed in conjunction with git reset  - -hard. reset only affects tracked files, so git clean to clean up untracked files.
usage:
git clean -n
git clean -f//force. remove untracked files only, not folders.
git clean -f <path>//remove untracked files, and specified path
git clean -df//remove untracked files and untracked directories.
git clean -xf//remoce untracked files from current directory,and ignored files.

The difference between SVN and Git
0.Repo-To-Repo Collaboration

It’s important to understand that Git’s idea of a “working copy” is very different from the working copy you get by checking out code from an SVN repository. Unlike SVN, Git makes
no distinction between the working copy and the central repository—they are all full-fledged Git repositories.

This makes collaborating with Git fundamentally different than with SVN. Whereas SVN depends on the relationship between the central repository and the working copy, Git’s collaboration model is based on repository-to-repository interaction.
Instead of checking a working copy into SVN’s central repository, you push or pull commits
from one repository to another.

Of course, there’s nothing stopping you from giving certain Git repos special meaning. For example, by simply designating one Git repo as the “central” repository, it’s possible to replicate a Centralized
workflow using Git. The point is, this is accomplished through conventions rather than being hardwired into the VCS itself.

图不见了
1.add
svn add a file, means that every file need to add once in SVN
git add a change to be committed, means that every change will be commit should be add.
2.
Whereas SVN tracks differences of
a file, Git’s version control model is based on snapshots.
For example, an SVN commit consists of a diff compared to the original file added to the repository. Git, on the other hand, records the entire
contents of each file in every commit.

参考文章：

1.table of basic git commands. https://confluence.atlassian.com/display/STASH0212/Basic+Git+commands

2. introduction to Git commands and workflows, including examples. https://www.atlassian.com/git/tutorials/setting-up-a-repository