git常用命令是什么
1、在当前目录新建一个Git代码库，：$ git init
2、新建一个目录，将其初始化为Git代码库，：$ git init [project-name]
3、下载一个项目和它的整个代码历史，：$ git clone [url]
4、显示当前的Git配置，：$ git config--list
5、编辑Git配置文件，：$ git config-e [--global]
6、设置提交代码时的用户信息，：$ git config [--global] user.name"[name]"，：$ git config [--global] user.email"[email address]"
7、添加指定文件到暂存区，：$ git add [file1] [file2]...
8、添加指定目录到暂存区，包括子目录，：$ git add [dir]
9、添加当前目录的所有文件到暂存区，：$ git add.
10、对于同一个文件的多处变化，可以实现分次提交，：$ git add-p
11、删除工作区文件，并且将这次删除放入暂存区，：$ git rm [file1] [file2]...
12、停止追踪指定文件，但该文件会保留在工作区，：$ git rm--cached [file]
13、改名文件，并且将这个改名放入暂存区，：$ git mv [file-original] [file-renamed]
14、提交暂存区到仓库区，：$ git commit-m [message]
15、提交暂存区的指定文件到仓库区，：$ git commit [file1] [file2]...-m [message]
16、提交工作区自上次commit之后的变化，直接到仓库区，：$ git commit-a
17、提交时显示所有diff信息，：$ git commit-v
18、使用一次新的commit，替代上一次提交
19、如果代码没有任何新变化，则用来改写上一次commit的提交信息，：$ git commit--amend-m [message]
20、重做上一次commit，并包括指定文件的新变化，：$ git commit--amend [file1] [file2]
扩展资料：
git有以下功能：
1、从服务器上克隆完整的Git仓库（包括代码和版本信息）到单机上。
2、在自己的机器上根据不同的开发目的，创建分支，修改代码。
3、在单机上自己创建的分支上提交代码。
4、在单机上合并分支。
5、把服务器上最新版的代码fetch下来，然后跟自己的主分支合并。
6、生成补丁（patch），把补丁发送给主开发者。
7、看主开发者的反馈，如果主开发者发现两个一般开发者之间有冲突（他们之间可以合作解决的冲突），就会要求他们先解决冲突，然后再由其中一个人提交。如果主开发者可以自己解决，或者没有冲突，就通过。
8、一般开发者之间解决冲突的方法，开发者之间可以使用pull命令解决冲突，解决完冲突之后再向主开发者提交补丁。
Git之远程分支改名
一般情况下是用不到远程分支改名的，只是最近项目中想把某个已是既成事实的开发分支改名成对应的dev分支，所以有了这个需求。
其实改名是一个偷懒的做法，本来应该是把这个待改名的分支merge到原dev分支上的，但是尝试了一下发现冲突太多了，有上百个，一下就泄气了，干脆改名。（这次也给了自己个警告，特性分支应该尽早合并到dev上来，如果走的太远了，就容易出现这个情况）
远程分支改名，其实就是先把远程分支给删除了，然后本地分支改名之后push上去即可，下面列下操作：(假设当前在本地分支�old上，要把它正名为new）
git branch-avv看下，会发现new分支对应的上游分支仍然是origin/old，但是多了一个gone标识，所以接下来我们要把new分支设置上游分支同时push上去
现在就完成了改名的步骤，我们当前的new分支对应origin/new，只是名称上的改动，所有的提交历史还是和old一样。
git到底怎么合并,有冲突都要手动吗
冲突的产生
很多命令都可能出现冲突，但从根本上来讲，都是merge和 patch（应用补丁）时产生冲突。
而rebase就是重新设置基准，然后应用补丁的过程，所以也会冲突。
git pull会自动merge，repo sync会自动rebase，所以git pull和repo sync也会产生冲突。当然git rebase就更不用说了。
冲突的类型
逻辑冲突
git自动处理（合并/应用补丁）成功，但是逻辑上是有问题的。
比如另外一个人修改了文件名，但我还使用老的文件名，这种情况下自动处理是能成功的，但实际上是有问题的。
又函数返回值含义变化，但我还使用老的含义，这种情况自动处理成功，但可能隐藏着重大BUG。这种问题，主要通过自动化测试来保障。所以最好是能够写出比较完备的自动化测试用例。
这种冲突的解决，就是做一次BUG修正。不是真正解决git报告的冲突。
内容冲突
两个用户修改了同一个文件的同一块区域，git会报告内容冲突。我们常见的都是这种，后面的解决办法也主要针对这种冲突。
树冲突
文件名修改造成的冲突，称为树冲突。
a用户把文件改名为a.c，b用户把同一个文件改名为b.c，那么b将这两个commit合并时，会产生冲突。
$ git status
added by us: b.c
both deleted: origin-name.c
added by them: a.c
如果最终确定用b.c，那么解决办法如下：
git rm a.c
git rm origin-name.c
git add b.c
git commit
执行前面两个git rm时，会告警逗file-name: needs merge地，可以不必理会。
树冲突也可以用git mergetool来解决，但整个解决过程是在交互式问答中完成的，用d删除不要的文件，用c保留需要的文件。
最后执行git commit提交即可。
内容冲突的解决办法
发现冲突
一般来讲，出现冲突时都会有逗CONFLICT地字样：
$ git pull
Auto-merging test.txt
CONFLICT(content): Merge conflict in test.txt
Automatic merge failed; fix conflicts and then commit the result.
也有例外，repo sync的报错，可能并不是直接提示冲突，而是下面这样：
error: project mini/sample
注：无论是否存在冲突，只要本地修改不是基于服务器最新的，它都可能报告这个错误，解决方法都是一样。
这个时候，需要进入报错的项目（git库）目录，然后执行git rebase解决：
git rebase remote-branch-name
冲突解决的一般过程
merge/patch的冲突解决
先编辑冲突，然后git commit提交。
注：对于git来讲，编辑冲突跟平时的修改代码没什么差异。修改完成后，都是要把修改添加到缓存，然后commit。
rebase的冲突解决
rebase的冲突解决过程，就是解决每个应用补丁冲突的过程。
解决完一个补丁应用的冲突后，执行下面命令标记冲突已解决（也就是把修改内容加入缓存）：
git add-u
注：-u表示把所有已track的文件的新的修改加入缓存，但不加入新的文件。
然后执行下面命令继续rebase：
git rebase--continue
有冲突继续解决，重复这这些步骤，直到rebase完成。
如果中间遇到某个补丁不需要应用，可以用下面命令忽略：
git rebase--skip
如果想回到rebase执行之前的状态，可以执行：
git rebase--abort
注：rebase之后，不需要执行commit，也不存在新的修改需要提交，都是git自动完成。
编辑冲突的方法
直接编辑冲突文件
冲突产生后，文件系统中冲突了的文件（这里是test.txt）里面的内容会显示为类似下面这样：
a123
<<<<<<< HEAD
b789
=======
b45678910
>>>>>>> 6853e5ff961e684d3a6c02d4d06183b5ff330dcc
c
其中：冲突标记<<<<<<<（7个<）与=======之间的内容是我的修改，=======与>>>>>>>之间的内容是别人的修改。
此时，还没有任何其它垃圾文件产生。
最简单的编辑冲突的办法，就是直接编辑冲突了的文件（test.txt），把冲突标记删掉，把冲突解决正确。
