git学习笔记

0. 前言

1. Git常用命令总结(所有命令可以再后文中找到详细内容)

命令命令意义
git add 文件名–>git commit -m “注释内容”在git仓库中加入文件
git status查看仓库当前的状态
cat 文件名查看文件文本内容
git log显示对文件内容操作的历史记录
git reset –hard HEAD^回退到上一个版本
git reset –hard 4424ad1847b766d2d9回退相应的版本号
git reflog显示改变文件内容的文本标识
rm 文件名删除文件
git remote add origin git@服务器名:用户名/仓库名.git关联远程仓库
git push origin master推送本地master分支的最新修改
git remote -v
git clone git@服务器名:用户名/仓库名.git克隆一个本地库
git checkout -b dev★创建dev分支,然后切换到dev分支
git branch查看当前分支
git checkout master切换分支
git merge dev合并dev分支
git log –graph –pretty=oneline –abbrev-commit查看分支合并情况
git push origin dev推送本地dev分支到remote的origin
git tag v1.0打一个新标签
git tag查看所有标签
git config –global color.ui true让Git显示颜色
git config –global alias.sta status配置别名,配置status别名为

2. 概述

2.1 git版本控制软件

所有的版本控制系统,其实只能跟踪文本文件的改动,比如TXT文件,网页,所有的程序代码等等,Git也不例外。版本控制系统可以告诉你每次的改动,比如在第5行加了一个单词“Linux”,在第8行删了一个单词“Windows”。而图片、视频这些二进制文件,虽然也能由版本控制系统管理,但没法跟踪文件的变化,只能把二进制文件每次改动串起来,也就是只知道图片从100KB改成了120KB,但到底改了啥,版本控制系统不知道,也没法知道。Microsoft的Word格式是二进制格式,因此,版本控制系统是没法跟踪Word文件的改动的,前面我们举的例子只是为了演示,如果要真正使用版本控制系统,就要以纯文本方式编写文件。

2.2 常用版本控制软件

CVS作为最早的开源而且免费的集中式版本控制系统,直到现在还有不少人在用。由于CVS自身设计的问题,会造成提交文件不完整,版本库莫名其妙损坏的情况。同样是开源而且免费的SVN修正了CVS的一些稳定性问题,是目前用得最多的集中式版本库控制系统。

CVS及SVN都是集中式的版本控制系统,Git是分布式版本控制系统。和集中式版本控制系统相比,分布式版本控制系统的安全性要高很多,因为每个人电脑里都有完整的版本库,某一个人的电脑坏掉了不要紧,随便从其他人那里复制一个就可以了。而集中式版本控制系统的中央服务器要是出了问题,所有人都没法干活了。

###2.3 git注意 因为文本是有编码的,比如中文有常用的GBK编码,日文有Shift_JIS编码,如果没有历史遗留问题,强烈建议使用标准的UTF-8编码,所有语言使用同一种编码,既没有冲突,又被所有平台所支持。 ##3. 实践操作 ###3.1 基础操作 **3.1.1 安装git后的配置**
git config --global user.name "Your Name"
git config --global user.email "email@example.com"

3.1.2 创建git版本库
创建一个版本库非常简单,首先,选择一个合适的地方,创建一个空目录:

mkdir learngit  //创建仓库
cd learngit     //进入仓库
pwd         //pwd命令用于显示当前目录
git init    //★★命令把这个目录变成Git可以管理的仓库
//上个命令运行完后,当前目录下多了一个.git的目录,如果你没有看到.git目录,那是因为这个目录默认是隐藏的,用ls -ah命令就可以看见

3.1.3 版本库内容操作

在git仓库中加入文件readme.txt实际上就是把文件修改添加到暂存区(概念见后面)

git add readme.txt      //★第一步,用命令git add告诉Git,把文件添加到仓库。
git commit -m "wrote a readme file" //第二步,用命令git commit告诉Git,把文件提交到仓库。-m后面输入的是本次提交的

说明

Git和其他版本控制系统如SVN的一个不同之处就是有暂存区的概念。工作区(Working Directory)就是你在电脑里能看到的目录。但是.git不是工作区是git的版本库,里面存了很多东西,其中最重要的就是称为stage(或者叫index)的暂存区,还有Git为我们自动创建的第一个分支master,以及指向master的一个指针叫HEAD。实际上就是把暂存区的所有内容提交到当前分支
说明:因为commit可以一次提交很多文件,所以你可以多次add不同的文件。可以简单理解为,需要提交的文件修改通通放到暂存区,然后,一次性提交暂存区的所有修改

git add file1.txt   
git add file2.txt file3.txt
git commit -m "add 3 files."
git status://查看仓库当前的状态,上面的命令告诉我们,readme.txt被修改过了,但还没有准备提交的修改。
git diff         //查看difference
cat readme.txt  //读取readme.txt文档内容

每当你觉得文件修改到一定程度的时候,就可以“保存一个快照”,这个快照在Git中被称为commit。一旦你把文件改乱了,或者误删了文件,还可以从最近的一个commit恢复,然后继续工作,而不是把几个月的工作成果全部丢失。

git log     //显示对文件内容操作的历史记录:提交标识、作者、日期、保存时的注释
git log --pretty=oneline    //不显示作者日期,每次改动显示为一行,且只显示提交标识、保存时的注释

3.1.4 Git回退
在Git中,用HEAD表示当前版本,也就是最新的提交3628164…882e1e0,上一个版本就是HEAD^,上上一个版本就是HEAD^^,当然往上100个版本写100个^比较容易数不过来,所以写成HEAD~100

git reset --hard HEAD^      //★★回退到上一个版本
git log                                     //★★查看日志发现,最后一个版本标识已经没有了
///想要再回到回退前的版本
git reset --hard 4424ad1847b766d2d9  //★★只要找到相应的版本号,绘图相应版本即可。版本号没必要写全,前几位就可以了,Git会自动去找
git reflog      //显示改变文件内容的文本标识

第一次修改 -> git add -> 第二次修改 -> git commit:第二次的修改将没有被提交

Git管理的是修改
什么是修改?比如你新增了一行,这就是一个修改,删除了一行,也是一个修改,更改了某些字符,也是一个修改,删了一些又加了一些,也是一个修改,甚至创建一个新文件,也算一个修改。
你用git add命令后,在工作区的第一次修改被放入暂存区,准备提交,但是,在工作区的第二次修改并没有放入暂存区,所以,git commit只负责把暂存区的修改提交了,也就是第一次的修改被提交了,第二次的修改不会被提交。

3.1.5 撤销修改

git diff HEAD   -- readme.txt   //查看工作区和版本库里面最新版本的区别
git checkout -- file                    //可以丢弃工作区的修改,★--很重要,没有--,就变成了“创建一个新分支”的命令
git checkout -- readme.txt      //意思就是,把readme.txt文件在工作区的修改全部撤销
git reset HEAD file                 //可以把暂存区的修改撤销掉(unstage),重新放回工作区

3.1.6 删除文件

rm test.txt     //rm为删除一个文件,git status查询标记为红色的deleted
git commit --amend //修改最后一次提交,有时候我们提交完了才发现漏掉了几个文件没有加,或者提交信息写错了。想要撤消刚才的提交操作,可以使用 --amend 选项重新提交

3.2 远程仓库:参考地址

GitHub给出的地址不止一个,还可以用https://github.com/michaelliao/gitskills.git这样的地址。实际上,Git支持多种协议,默认的git://使用ssh,但也可以使用https等其他协议。使用https除了速度慢以外,还有个最大的麻烦是每次推送都必须输入口令,但是在某些只开放http端口的公司内部就无法使用ssh协议而只能用https。

git remote add origin*git@github.com:我的用户名/learngit.git //*关联远程库,如我的是
git remote add origin git@server-name:path/repo-name.git //远程仓库的默认名称是origin
git push origin master          //只要本地作了提交,就可以通过命令,把本地master分支的最新修改推送至GitHub
git push -u origin master       //关联后,使用该命令完成第一次推送master分支的所有内容

分布式版本系统的最大好处之一是在本地工作完全不需要考虑远程库的存在,也就是有没有联网都可以正常工作,当有网络的时候,再把本地提交推送一下就完成了同步

git remote  //查看远程库的信息
git remote -v       //★★查看远程库的信息显示更详细的信息:显示了可以抓取和推送的origin的地址

假设我们从零开发,那么最好的方式是先创建远程库,然后,从远程库克隆。首先,登陆GitHub,创建一个新的仓库,名字叫gitskills

//克隆一个本地库
$ git clone git@github.com:用户名/gitskills.git   //★
cd gitskills //进入相应的库
ls          //查看所有内容

3.3分支管理

3.3.1 概念

应用场景:分支在实际中有什么用呢?假设你准备开发一个新功能,但是需要两周才能完成,第一周你写了50%的代码,如果立刻提交,由于代码还没写完,不完整的代码库会导致别人不能干活了。如果等代码全部写完再一次提交,又存在丢失每天进度的巨大风险
现在有了分支,就不用怕了。你创建了一个属于你自己的分支,别人看不到,还继续在原来的分支上正常工作,而你在自己的分支上干活,想提交就提交,直到开发完毕后,再一次性合并到原来的分支上,这样,既安全,又不影响别人工作。下面用图示说明:

  • HEAD指向的就是当前分支,master才是指向提交的,每次提交,master分支都会向前移动一步,这样,随着你不断提交,master分支的线也越来越长:
    这里写图片描述
  • Git创建一个分支很快,因为除了增加一个dev指针,改改HEAD的指向,工作区的文件都没有任何变化
    这里写图片描述
  • 直接把master指向dev的当前提交,就完成了合并:
    这里写图片描述
git checkout -b dev //★创建dev分支,然后切换到dev分支,-b参数表示创建并切换
//上面一行相当于下面两行git branch dev 、git checkout dev
git branch  //★查看当前分支,会列出所有分支,当前分支前面会标一个*号
git checkout master //★★切换分支,这里是回到master分支
git merge dev//★把dev分支的工作成果合并到master分支上。Fast forward模式,这种模式下,删除分支后,会丢掉分支信息。
git merge --no-ff -m "merge with no-ff" dev //禁用Fast forward模式合并分支,这样git就会在merge时生成一个新的commit,所以要写注释信息
git branch -d dev   //合并完后可以删除分支,注意要先合并分支
git branch -D feature-vulcan    //用大写"D"表示在没有合并的情况下强行删除,如果使用普通删除将出现error

3.3.2 分支中的冲突

如果在各自的的分支上对同一个文件进行了提交,试图把各自的修改合并起来,就会出现冲突。用git status出现 both modified标记。里面会有用<<<<<<<,=======,>>>>>>>标记出不同分支的内容
这时必须修改后才能进行合并

git log --graph --pretty=oneline --abbrev-commit    ///查看分支合并情况

这里写图片描述

3.3.3 分支策略

在实际开发中,我们应该按照几个基本原则进行分支管理:首先,master分支应该是非常稳定的,也就是仅用来发布新版本,平时不能在上面干活;那在哪干活呢?干活都在dev分支上,也就是说,dev分支是不稳定的,到某个时候,比如1.0版本发布时,再把dev分支合并到master上,在master分支发布1.0版本;你和你的小伙伴们每个人都在dev分支上干活,每个人都有自己的分支,时不时地往dev分支上合并就可以了。所以,团队合作的分支看起来就像这样:
【图示:】
master分支是主分支[版本分支],因此要时刻与远程同步;
dev分支是[整体开发分支],团队所有成员都需要在上面工作,所以也需要与远程同步;
bug分支只用于在本地修复bug,就没必要推到远程了,除非老板要看看你每周到底修复了几个bug;
feature分支是[个体开发分支],决定是否推到远程取决于你是否和你的小伙伴合作在上面开发。

3.3.4 bug分支

  • 每个bug都可以通过一个新的临时分支来修复,修复后,合并分支,然后将临时分支删除。
  • 当你接到一个修复一个代号101的bug的任务时,很自然地,你想创建一个分支issue-101来修复它,但是,等等,当前正在dev上进行的工作还没有提交,该工作只进行到一半,还没法提交。这时必须用到git的stash功能,可以把当前工作现场“储藏”起来,等以后恢复现场后继续工作
git stash
git stash list  //查看刚才的工作现场
git stash apply//以不删除stash的模式恢复工作现场,需要用git stash drop删除
git stash pop  //★恢复的同时把stash内容也删了

3.3.5 feature分支

添加一个新功能时,你肯定不希望因为一些实验性质的代码,把主分支搞乱了,所以,每添加一个新功能,最好新建一个feature分支,在上面开发,完成后,合并,最后,删除该feature分支。
和bug分支类似

git checkout -b feature-feature_test //创建并且换到feature分支

3.3.6 推送分支

推送分支就是把该分支上的所有本地提交推送到远程库推送时,要指定本地分支,这样,Git就会把该分支推送到远程库对应的远程分支上

git push origin dev     //推送本地dev分支到remote的origin

3.3.7 抓取分支

一个项目中新加入一个开发人员,项目经理指定其开发某项任务,则它应该首先获取得到项目的部分源码,所以要抓取分支
第一步:把该开发人员自己的SSH Key 公钥交给git服务器

git clone git@github.com:张三/learngit.git //当他从远程库clone时,默认情况下,他只能看到本地的master分支
git checkout -b dev origin/dev //这样他就可以在dev上继续修改,时不时地把dev分支push到远程

如果他修改并提交了后,你也在修改,并开始提交,这是会提示错误。因为他的最新提交和你试图推送的提交有冲突,应该先用git pull把最新的提交从origin/dev抓下来,然后,在本地合并,解决冲突,再推送:
如果git pull也失败了,可能原因是没有指定本地dev分支与远程origin/dev分支的链接,根据提示,设置dev和origin/dev的链接

git branch --set-upstream dev origin/dev
git pull

多人写作模式
1. 首先,可以试图用git push origin branch-name推送自己的修改;
2. 如果推送失败,则因为远程分支比你的本地更新,需要先用git pull试图合并;
3. 如果合并有冲突,则解决冲突,并在本地提交;
4. 没有冲突或者解决掉冲突后,再用git push origin branch-name推送就能成功!
如果git pull提示“no tracking information”,则说明本地分支和远程分支的链接关系没有创建,用命令git branch –set-upstream branch-name origin/branch-name。

4. 其它

4.1标签管理

说明:下面的命令中v1.0是,创建标签的时候决定的

git tag v1.0        //打一个新标签
git tag             //查看所有标签

默认标签是打在最新提交的commit上的。有时候,如果忘了打标签,比如,现在已经是周五了,但应该在周一打的标签没有打,怎么办?方法是找到历史提交的commit id,然后打上就可以了

git tag v0.9 6224937        //对commit id是6224937的提交打标签
git show v0.1           //查看标签信息,标签不是按时间顺序列出,而是按字母排序的
git tag -a v0.1 -m "version 0.1 released" 3628164       //创建带有说明的标签,用-a指定标签名,-m指定说明文字
git tag -s v0.2 -m "signed version 0.2 released" fec145a        //通过-s用私钥签名一个标签
git tag -d v0.1 //因为创建的标签都只存储在本地,不会自动推送到远程。所以,打错的标签可以在本地安全删除
git push origin v0.1    //推送某个标签到远程
git push origin --tags  //一次性推送全部尚未推送到远程的本地标签
git tag -d v0.9 
git push origin :refs/tags/v0.9 //删除远程标签:先从本地删除-->从远程删除

4.2 自定义Git

git config --global color.ui true   //让Git显示颜色,会让命令输出看起来更醒目
git config --global alias.sta status        //配置status别名为st,以下是常用的配置别名,--global参数是全局参数,也就是这些命令在这台电脑的所有Git仓库下都有用
git config --global alias.che checkout
git config --global alias.com commit
git config --global alias.bra branch
git config --global alias.unstage 'reset HEAD'  //配置把暂存区的修改撤销掉(unstage)
git config --global alias.last 'log -1'//显示最后一次提交信息
git config --global alias.lg "log --color --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit"

说明:
配置Git的时候,加上--global是针对当前用户起作用的,如果不加,那只针对当前的仓库起作用
每个仓库的Git配置文件都放在.git/config文件中,别名就在[alias]后面,要删除别名,直接把对应的行删掉即可
当前用户的Git配置文件放在用户主目录下的一个隐藏文件.gitconfig中,配置别名也可以直接修改这个文件,如果改错了,可以删掉文件重新通过命令配置

4.3 搭建Git服务器详细内容

搭建Git服务器需要准备一台运行Linux的机器,强烈推荐用Ubuntu或Debian
第一步,安装gitsudo apt-get install git
第二步,创建一个git用户,用来运行git服务:sudo adduser git
第三步,创建证书登录:收集所有需要登录的用户的公钥,就是他们自己的id_rsa.pub文件,把所有公钥导入到/home/git/.ssh/authorized_keys文件里,一行一个
第四步,初始化Git仓库:选定一个目录作为Git仓库,假定是/srv/sample.git,在/srv目录下输入命令sudo git init --bare sample.git
第五步,禁用shell登录:出于安全考虑,第二步创建的git用户不允许登录shell,这可以通过编辑/etc/passwd文件完成
git:x:1001:1001:,,,:/home/git:/bin/bash –> git:x:1001:1001:,,,:/home/git:/usr/bin/git-shell
第六步,克隆远程仓库

it clone git@server:/srv/sample.git //通过git clone命令克隆远程仓库了,在各自的电脑上运行

5. 在Eclipse上使用git

1. 删除与github有联系的项目(本地eclipse中保留,github删除干净)

  • 步骤
    1. 点击进入相应的repository -> 右边settings -> 下边Danger Zone -> Delete this repository
    2. 删除github上面的项目以后,在本地删除与github上的联系:
      在eclipse中的Git Repositories上删除相关的仓库
      项目右键 > Team > Disconnect
  • 参考文档:如何删除github上的项目

2. 将一个项目提交到github上面,并建立本地与github上的联系

  • 步骤

    1. 在github上建立相关的以项目工程命名的仓库
    2. 右键工程 > Team > commit 将项目提交到本地工程(以workspace路径下的单个项目为仓库)
    3. 配置:Preferences > Team > Git > Configuration > Repository Settings(前提:本地和github的认证已经配置好)
    4. 推送
      Team > remote > pull
      Team > remote > push
  • 参考文档:Eclipse4.4安装egit插件提交本地项目代码到远程仓库

3. Java常用的忽略[ignore]机制

*.class
# Package Files #
*.war
*.ear
*.jar
#控制某个文件夹下面的所有文件不上传#
/classes
/.setting
/.git
/.ignore
/build

6 报错

报错1: src refspec master does not match any.

$ git push -u origin master
error: src refspec master does not match any.
error: failed to push some refs to ‘git@github.com:hewei2015/learngit.git’

没有保证当前库下有文件,并且已经在本地完成add和commit命令。如果没有看懂,请点参考文档

报错2: secret key not available

gpg: signing failed: secret key not available
error: gpg failed to sign the data
error: unable to sign the tag

用私钥签名一个标签时,签名采用PGP签名,因此,必须首先安装gpg(GnuPG),如果没有找到gpg,或者没有gpg密钥对

报错:Please make sure you have the correct access rights and the repository exists.

错误原因:我将最开始生成的公钥和私钥剪切到了另外的文件夹中

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值