• git常用知识整理


    分布式和集中版本控制的区别

    分布式版本控制系统与集中式版本控制系统有何不同呢?首先,分布式版本控制系统根本没有“中央服务器”,每个人的电脑上都是一个完整的版本库,这样,你工作的时候,就不需要联网了,因为版本库就在你自己的电脑上。既然每个人电脑上都有一个完整的版本库,那多个人如何协作呢?比方说你在自己电脑上改了文件A,你的同事也在他的电脑上改了文件A,这时,你们俩之间只需把各自的修改推送给对方,就可以互相看到对方的修改了。

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

    在实际使用分布式版本控制系统的时候,其实很少在两人之间的电脑上推送版本库的修改,因为可能你们俩不在一个局域网内,两台电脑互相访问不了,也可能今天你的同事病了,他的电脑压根没有开机。因此,分布式版本控制系统通常也有一台充当“中央服务器”的电脑,但这个服务器的作用仅仅是用来方便“交换”大家的修改,没有它大家也一样干活,只是交换修改不方便而已。

    安装git

    Windows下要使用很多Linux/Unix的工具时,需要Cygwin这样的模拟环境,Git也一样。Cygwin的安装和配置都比较复杂,就不建议你折腾了。不过,有高人已经把模拟环境和Git都打包好了,名叫msysgit,只需要下载一个单独的exe安装程序,其他什么也不用装,绝对好用。

    msysgit是Windows版的Git,从http://msysgit.github.io/下载,然后按默认选项安装即可。

    安装完成后,在开始菜单里找到“Git”->“Git Bash”,蹦出一个类似命令行窗口的东西,就说明Git安装成功!

    安装完成后,还需要最后一步设置,在命令行输入:

    $ git config --global user.name "Your Name"
    $ git config --global user.email "email@example.com"
    

    因为Git是分布式版本控制系统,所以,每个机器都必须自报家门:你的名字和Email地址。你也许会担心,如果有人故意冒充别人怎么办?这个不必担心,首先我们相信大家都是善良无知的群众,其次,真的有冒充的也是有办法可查的。

    注意git config命令的--global参数,用了这个参数,表示你这台机器上所有的Git仓库都会使用这个配置,当然也可以对某个仓库指定不同的用户名和Email地址

    创建版本库

    切换到相应的目录 然后执行 

    $ git init

    瞬间Git就把仓库建好了,而且告诉你是一个空的仓库(empty Git repository),细心的读者可以发现当前目录下多了一个.git的目录,这个目录是Git来跟踪管理版本库的,没事千万不要手动修改这个目录里面的文件,不然改乱了,就把Git仓库给破坏了。

    初始化一个Git仓库,使用git init命令。

    添加文件到Git仓库,分两步:

    第一步,使用命令git add <file>,注意,可反复多次使用,添加多个文件;

    第二步,使用命令git commit,完成。

    要随时掌握工作区的状态,使用git status命令。

    如果git status告诉你有文件被修改过,用git diff可以查看修改内容。

    版本回退

    HEAD指向的版本就是当前版本,因此,Git允许我们在版本的历史之间穿梭,使用命令git reset --hard commit_id

    穿梭前,用git log可以查看提交历史,以便确定要回退到哪个版本。

    要重返未来,用git reflog查看命令历史,以便确定要回到未来的哪个版本。

    工作区和暂存区

    Git和其他版本控制系统如SVN的一个不同之处就是有暂存区的概念。

    先来看名词解释。

    工作区(Working Directory):就是你在电脑里能看到的目录,比如我的learngit文件夹就是一个工作区:

    working-dir

    版本库(Repository):工作区有一个隐藏目录.git,这个不算工作区,而是Git的版本库。

    Git的版本库里存了很多东西,其中最重要的就是称为stage(或者叫index)的暂存区,还有Git为我们自动创建的第一个分支master,以及指向master的一个指针叫HEAD

    git-repo

    分支和HEAD的概念我们以后再讲。

    前面讲了我们把文件往Git版本库里添加的时候,是分两步执行的:

    第一步是用git add把文件添加进去,实际上就是把文件修改添加到暂存区;

    第二步是用git commit提交更改,实际上就是把暂存区的所有内容提交到当前分支。

    因为我们创建Git版本库时,Git自动为我们创建了唯一一个master分支,所以,现在,git commit就是往master分支上提交更改。

    你可以简单理解为,需要提交的文件修改通通放到暂存区,然后,一次性提交暂存区的所有修改。

    俗话说,实践出真知。现在,我们再练习一遍,先对readme.txt做个修改,比如加上一行内容:

    Git is a distributed version control system.
    Git is free software distributed under the GPL.
    Git has a mutable index called stage.
    

    然后,在工作区新增一个LICENSE文本文件(内容随便写)。

    先用git status查看一下状态:

    $ git status
    # On branch master
    # Changes not staged for commit:
    #   (use "git add <file>..." to update what will be committed)
    #   (use "git checkout -- <file>..." to discard changes in working directory)
    #
    #       modified:   readme.txt
    #
    # Untracked files:
    #   (use "git add <file>..." to include in what will be committed)
    #
    #       LICENSE
    no changes added to commit (use "git add" and/or "git commit -a")
    

    Git非常清楚地告诉我们,readme.txt被修改了,而LICENSE还从来没有被添加过,所以它的状态是Untracked

    现在,使用两次命令git add,把readme.txtLICENSE都添加后,用git status再查看一下:

    $ git status
    # On branch master
    # Changes to be committed:
    #   (use "git reset HEAD <file>..." to unstage)
    #
    #       new file:   LICENSE
    #       modified:   readme.txt
    #
    

    现在,暂存区的状态就变成这样了:

    git-stage

    所以,git add命令实际上就是把要提交的所有修改放到暂存区(Stage),然后,执行git commit就可以一次性把暂存区的所有修改提交到分支。

    $ git commit -m "understand how stage works"
    [master 27c9860] understand how stage works
     2 files changed, 675 insertions(+)
     create mode 100644 LICENSE
    

    一旦提交后,如果你又没有对工作区做任何修改,那么工作区就是“干净”的:

    $ git status
    # On branch master
    nothing to commit (working directory clean)
    

    现在版本库变成了这样,暂存区就没有任何内容了:

    git-stage-after-commit

    git add 是把工作区的改动推送到暂存区

    git commit 是把暂存区的内容提交到版本库

    撤销修改

    场景1:当你改乱了工作区某个文件的内容,想直接丢弃工作区的修改时,用命令git checkout -- file

    场景2:当你不但改乱了工作区某个文件的内容,还添加到了暂存区时,想丢弃修改,分两步,第一步用命令git reset HEAD file,就回到了场景1,第二步按场景1操作。

    场景3:已经提交了不合适的修改到版本库时,想要撤销本次提交,参考版本回退一节,不过前提是没有推送到远程库。

    撤销删除

    删错了,可以很轻松地把误删的文件恢复到最新版本,因为版本库里还有呢:

    $ git checkout -- test.txt
    

    git checkout其实是用版本库里的版本替换工作区的版本,无论工作区是修改还是删除,都可以“一键还原”。

    命令git rm用于删除一个文件。如果一个文件已经被提交到版本库,那么你永远不用担心误删,但是要小心,你只能恢复文件到最新版本,你会丢失最近一次提交后你修改的内容

    远程仓库

    注册github帐号,并创建仓库

    第1步:创建SSH Key。在用户主目录下,看看有没有.ssh目录,如果有,再看看这个目录下有没有id_rsaid_rsa.pub这两个文件,如果已经有了,可直接跳到下一步。如果没有,打开Shell(Windows下打开Git Bash),创建SSH Key:

    $ ssh-keygen -t rsa -C "youremail@example.com"

    你需要把邮件地址换成你自己的邮件地址,然后一路回车,使用默认值即可,由于这个Key也不是用于军事目的,所以也无需设置密码。

    如果一切顺利的话,可以在用户主目录里找到.ssh目录,里面有id_rsaid_rsa.pub两个文件,这两个就是SSH Key的秘钥对,id_rsa是私钥,不能泄露出去,id_rsa.pub是公钥,可以放心地告诉任何人。

    第2步:登陆GitHub,打开“Account settings”,“SSH Keys”页面:

    然后,点“Add SSH Key”,填上任意Title,在Key文本框里粘贴id_rsa.pub文件的内容

    有https协议和git也就是ssh协议,https协议在每次push时都需要数据帐号和密码,略麻烦,可以稍微控制push的次数。

    添加远程仓库

    本地的learngit仓库下运行命令:

    $ git remote add origin git@github.com:mh335776191/learngit.git
    添加后,远程库的名字就是origin,这是Git默认的叫法,也可以改成别的,但是origin这个名字一看就知道是远程库。

    把本地库的内容推送到远程,用git push命令,实际上是把当前分支master推送到远程。

    由于远程库是空的,我们第一次推送master分支时,加上了-u参数,Git不但会把本地的master分支内容推送的远程新的master分支,还会把本地的master分支和远程的master分支关联起来,在以后的推送或者拉取时就可以简化命令。

    从现在起,只要本地作了提交,就可以通过命令:

    $ git push origin master
    要克隆一个仓库,首先必须知道仓库的地址,然后使用git clone命令克隆。


    分支

    Git鼓励大量使用分支:

    查看分支:git branch

    创建分支:git branch <name>

    切换分支:git checkout <name>

    创建+切换分支:git checkout -b <name>

    合并某分支到当前分支:git merge <name>

    删除分支:git branch -d <name>

    解决冲突

    当Git无法自动合并分支时,就必须首先解决冲突。解决冲突后,再提交,合并完成。

    git log --graph命令可以看到分支合并图。

    分支策略

    在实际开发中,我们应该按照几个基本原则进行分支管理:

    首先,master分支应该是非常稳定的,也就是仅用来发布新版本,平时不能在上面干活;

    那在哪干活呢?干活都在dev分支上,也就是说,dev分支是不稳定的,到某个时候,比如1.0版本发布时,再把dev分支合并到master上,在master分支发布1.0版本;

    你和你的小伙伴们每个人都在dev分支上干活,每个人都有自己的分支,时不时地往dev分支上合并就可以了。

    所以,团队合作的分支看起来就像这样:

    git-br-policy

    Git分支十分强大,在团队开发中应该充分应用。

    合并分支时,加上--no-ff参数就可以用普通模式合并,合并后的历史有分支,能看出来曾经做过合并,而fast forward合并就看不出来曾经做过合并。

    隐藏/恢复现场

    修复bug时,我们会通过创建新的bug分支进行修复,然后合并,最后删除;

    当手头工作没有完成时,先把工作现场git stash一下,然后去修复bug,修复后,再git stash pop,回到工作现场

    删除分支

    如果要丢弃一个没有被合并过的分支,可以通过git branch -D <name>强行删除。

    多人协作

    多人协作的工作模式通常是这样:

    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

    这就是多人协作的工作模式,一旦熟悉了,就非常简单。

    • 查看远程库信息,使用git remote -v

    • 本地新建的分支如果不推送到远程,对其他人就是不可见的;

    • 从本地推送分支,使用git push origin branch-name,如果推送失败,先用git pull抓取远程的新提交;

    • 在本地创建和远程分支对应的分支,使用git checkout -b branch-name origin/branch-name,本地和远程分支的名称最好一致;

    • 建立本地分支和远程分支的关联,使用git branch --set-upstream branch-name origin/branch-name

    • 从远程抓取分支,使用git pull,如果有冲突,要先处理冲突。

    标签管理

    发布一个版本时,我们通常先在版本库中打一个标签,这样,就唯一确定了打标签时刻的版本。将来无论什么时候,取某个标签的版本,就是把那个打标签的时刻的历史版本取出来。所以,标签也是版本库的一个快照。

    Git的标签虽然是版本库的快照,但其实它就是指向某个commit的指针(跟分支很像对不对?但是分支可以移动,标签不能移动),所以,创建和删除标签都是瞬间完成的。

    • 命令git tag <name>用于新建一个标签,默认为HEAD,也可以指定一个commit id;

    • git tag -a <tagname> -m "blablabla..."可以指定标签信息;

    • git tag -s <tagname> -m "blablabla..."可以用PGP签名标签;

    • 命令git tag可以查看所有标签。

    删除标签

    • 命令git push origin <tagname>可以推送一个本地标签;

    • 命令git push origin --tags可以推送全部未推送过的本地标签;

    • 命令git tag -d <tagname>可以删除一个本地标签;

    • 命令git push origin :refs/tags/<tagname>可以删除一个远程标签。

    忽略指定文件

    有些时候,你必须把某些文件放到Git工作目录中,但又不能提交它们,比如保存了数据库密码的配置文件啦,等等,每次git status都会显示“Untracked files ...”,有强迫症的童鞋心里肯定不爽。

    好在Git考虑到了大家的感受,这个问题解决起来也很简单,在Git工作区的根目录下创建一个特殊的.gitignore文件,然后把要忽略的文件名填进去,Git就会自动忽略这些文件。

    不需要从头写.gitignore文件,GitHub已经为我们准备了各种配置文件,只需要组合一下就可以使用了。所有配置文件可以直接在线浏览:https://github.com/github/gitignore

    忽略文件的原则是:

    1. 忽略操作系统自动生成的文件,比如缩略图等;
    2. 忽略编译生成的中间文件、可执行文件等,也就是如果一个文件是通过另一个文件自动生成的,那自动生成的文件就没必要放进版本库,比如Java编译产生的.class文件;
    3. 忽略你自己的带有敏感信息的配置文件,比如存放口令的配置文件。

    使用Windows的童鞋注意了,如果你在资源管理器里新建一个.gitignore文件,它会非常弱智地提示你必须输入文件名,但是在文本编辑器里“保存”或者“另存为”就可以把文件保存为.gitignore了。

    • 忽略某些文件时,需要编写.gitignore

    • .gitignore文件本身要放到版本库里,并且可以对.gitignore做版本管理!

    配置别名

    有没有经常敲错命令?比如git statusstatus这个单词真心不好记。

    如果敲git st就表示git status那就简单多了,当然这种偷懒的办法我们是极力赞成的。

    我们只需要敲一行命令,告诉Git,以后st就表示status

    $ git config --global alias.st status
    

    好了,现在敲git st看看效果。

    当然还有别的命令可以简写,很多人都用co表示checkoutci表示commitbr表示branch

    $ git config --global alias.co checkout
    $ git config --global alias.ci commit
    $ git config --global alias.br branch
    

    以后提交就可以简写成:

    $ git ci -m "bala bala bala..."
    

    --global参数是全局参数,也就是这些命令在这台电脑的所有Git仓库下都有用。

    配置Git的时候,加上--global是针对当前用户起作用的,如果不加,那只针对当前的仓库起作用。

    配置文件放哪了?每个仓库的Git配置文件都放在.git/config文件中:

    $ cat .git/config 
    [core]
        repositoryformatversion = 0
        filemode = true
        bare = false
        logallrefupdates = true
        ignorecase = true
        precomposeunicode = true
    [remote "origin"]
        url = git@github.com:michaelliao/learngit.git
        fetch = +refs/heads/*:refs/remotes/origin/*
    [branch "master"]
        remote = origin
        merge = refs/heads/master
    [alias]
        last = log -1
    

    别名就在[alias]后面,要删除别名,直接把对应的行删掉即可。

    而当前用户的Git配置文件放在用户主目录下的一个隐藏文件.gitconfig

    配置别名也可以直接修改这个文件,如果改错了,可以删掉文件重新通过命令配置。

     

  • 相关阅读:
    BZOJ 1500 维修数列
    BZOJ 1501 智慧珠游戏
    BZOJ 1507 Editor
    BZOJ 3223 文艺平衡树
    BZOJ 3224 普通平衡树
    BZOJ 3196 二逼平衡树
    BZOJ 1048 分割矩阵
    BZOJ 1047 理想的正方形
    BZOJ 1046 上升序列
    BZOJ 1045 糖果传递
  • 原文地址:https://www.cnblogs.com/smailxiaobai/p/4303613.html
Copyright © 2020-2023  润新知