git的个人学习总结(1)

来源:互联网 发布:网络直播市场分析 编辑:程序博客网 时间:2024/05/16 01:15

Git的和svn比较的优点:
1、适合分布式开发,强调个体
2、公共服务器压力和数据量都不会太大
3、速度快、灵活
4、任意两个开发者之间可以很容易的解决冲突
5、离线工作


Git的常用命令:
1.git status命令可以让我们时刻掌握仓库当前的状态,上面的命令告诉我们,readme.txt被修改过了,但还没有准备提交的修改。
2.git diff readme.txt 可以查看到修改了什么内容。
3.git log命令显示从最近到最远的提交日志,我们可以看到3次提交。如果嫌输出信息太多,看得眼花缭乱的,可以试试加上--pretty=oneline参数。
4.git reset --hard HEAD^回到上一个版本。如果需要回到未来的某个版本的话,那么就要执行如下命令git reset --hard +commit id。
5.git reflog用来记录你的每一次命令。
6.git reset命令既可以回退版本,也可以把暂存区的修改回退到工作区。
7.用git log --graph命令可以看到分支合并图
8.feature-vulcan分支还没有被合并,如果删除,将丢失掉修改,如果要强行删除,需要使用命令git branch -D feature-vulcan。
9. Git fetch  从服务器的仓库中下载代码。(与服务器交互,从服务器上下载最新代码
现在我们强行删除:
从远程仓库克隆:
1.登陆GitHub,创建一个新的仓库,名字叫gitskills:
2.勾选Initialize this repository with a README
3.git clone //+地址  如git@github.com:michaelliao/gitskills.git


分支命令
查看分支:git branch
创建分支:git branch <name>
切换分支:git checkout <name>
创建+切换分支:git checkout -b <name>
合并某分支到当前分支:git merge <name>
删除分支:git branch -d <name>
git常见的冲突及解决方案
1.树冲突
文件名修改造成的冲突,称为树冲突。
比如,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提交即可。


2.出现冲突
一般来讲,出现冲突时都会有“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
3.rebase的冲突解决
rebase的冲突解决过程,就是解决每个应用补丁冲突的过程。
解决完一个补丁应用的冲突后,执行下面命令标记冲突已解决(也就是把修改内容加入缓存):
git add -u
注:-u 表示把所有已track的文件的新的修改加入缓存,但不加入新的文件。
然后执行下面命令继续rebase:
git rebase --continue
有冲突继续解决,重复这这些步骤,直到rebase完成。
 
如果中间遇到某个补丁不需要应用,可以用下面命令忽略:
git rebase --skip
 
如果想回到rebase执行之前的状态,可以执行:
git rebase --abort
 
注:rebase之后,不需要执行commit,也不存在新的修改需要提交,都是git自动完成
4.编辑冲突的方法
直接编辑冲突文件
冲突产生后,文件系统中冲突了的文件(这里是test.txt)里面的内容会显示为类似下面这样:
a123
<<<<<<< HEAD
b789
=======
b45678910
>>>>>>> 6853e5ff961e684d3a6c02d4d06183b5ff330dcc
c
其中:冲突标记<<<<<<< (7个<)与=======之间的内容是我的修改,=======与>>>>>>>之间的内容是别人的修改。
此时,还没有任何其它垃圾文件产生。
 
最简单的编辑冲突的办法,就是直接编辑冲突了的文件(test.txt),把冲突标记删掉,把冲突解决正确。
利用图形界面工具解决冲突
如果要解决的冲突很多,且比较复杂,图形界面的冲突解决工具就显得很重要了。
 
执行git mergetool用预先配置的Beyond Compare解决冲突:
$ git mergetool
Merging:
test.txt
Normal merge conflict for 'test.txt':
  {local}: modified
  {remote}: modified
 
上面三个窗口依次是“LOCAL”、“BASE”、“REMOTE”,它们只是提供解决冲突需要的信息,是无法编辑的。
下面一个窗口是合并后的结果,可以手动修改,也可以点击相应颜色的箭头选择“LOCAL”或者“REMOTE”。
 
在Beyond Compare中修改冲突保存后,冲突文件(test.txt)中的冲突标记就没有了,成了修改后的内容,一个文件的冲突编辑就完成了。


多人协作模式
人协作的工作模式通常是这样:
首先,可以试图用git push origin branch-name推送自己的修改;
如果推送失败,则因为远程分支比你的本地更新,需要先用git pull试图合并;
如果合并有冲突,则解决冲突,并在本地提交;
没有冲突或者解决掉冲突后,再用git push origin branch-name推送就能成功!
如果git pull提示“no tracking information”,则说明本地分支和远程分支的链接关系没有创建,用命令git branch --set-upstream branch-name origin/branch-name。
这就是多人协作的工作模式,一旦熟悉了,就非常简单。
 


css样式:http://www.css88.com/book/css/properties/flex/flex-direction.htm