Git基础笔记（初步整理）

一、Git 简介

1.1 安装

• 安装地址

  官网下载：Git官网下载

• 设置用户信息

  主要是设置 ： 名字 & Email 地址。

  $ git config --global user.name "hwh"
  $ git config --global user.email "380141202@qq.com"

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

1.2 创建版本库

• 创建仓库

  ​ windows可以直接在桌面创建一个名为："Git"文件夹，下有“test”子文件夹，子文件夹含有一个名为“readme.md”文件。

  ​ 然后切换到其目录下（这里切换的是"Git"文件夹，而非“test”子文件夹）

  $ cd Git/
  $ pwd
  /c/Users/86151/Desktop/Git

• 初步提交过程

  • 初始化仓库

    $ git init
    Initialized empty Git repository in /Users/michael/learngit/.git/

  • 修改仓库文件

    将“test”子文件夹，下readme.md文件，增加内容。

  • 添加文件到仓库

    注意：可以同时 一次添加多个文件到仓库！

    $ git add test/readme.md

  • 提交文件

    可以增加m参数：添加修改信息

    $ git commit -m '第一次文件改动'

二、时光机穿梭

2.0 更多控制修改提交

• 概览

  • 要随时掌握工作区的状态，使用git status命令。
  • 如果git status告诉你有文件被修改过，用git diff <filepath>可以查看修改内容。

• 实操

  • 再次修改文件

    可以先清除原文件，再增添readme.md文档内容 ：

    “i am  huitailang , here  is my first test word .“
    
     “这是我第二次修改这个文件”

    使用 git status，查看状态发现readme.md文件已被修改但未提交（no changes）

    $ git status

    

  • 查看具体修改了什么内容

    git diff <filepath>查看文件具体修改，

    $ git diff test/readme.md

    

  • 添加仓库

    $ git add test/readme.md

    同时可用 git status，查看此时状态会显示，readme.md将要被提交修改。

  • 提交仓库

    $ git commit -m "这是我第二次修改"

    ​ 再用 git status，查看仓库当前状态，显示没有需要提交的修改，而且工作目录是干净的（working tree clean）。

    

2.1 版本回退

• 概览

  • HEAD指向的版本就是当前版本，因此，Git允许我们在版本的历史之间穿梭，使用命令git reset --hard commit_id。
  • 穿梭前，用git log可以查看提交历史，以便确定要回退到哪个版本。
  • 要重返未来，用git reflog查看命令历史，以便确定要回到未来的哪个版本

• 实操

  • N次修改文件

    先多修改几次文件提交，得到多个版本。

  • 版本回退

    • 查看版本历史

      git log 查看当前版本和之前的历史，git relog 查看所有版本历史

      $ git log  # 可以加上 --pretty=oneline 参数使显示更简洁

      

  • 回退版本

    git reset --hard <指定版本>：可用于回到指定版本，<指定版本>方式：

    • HEAD ^

      HEAD ^ 回到上个版本；HEAD ^ ^ 回到上上 个版本，依此类推。

      $ git reset --hard HEAD^^  # 回到上上个版本

      

    • HEAD~<数字>

      回到前<数字>版本。如HEAD~100，回到前100个版本。

    • :

      commit ID 不用打全，一般打前面几个字符即可。如，如果回退第2版本，git log，只能看到第2版本及之前的版本信息。那么可用 git reflog查看所有版本ID，然后指定ID，回到第4版本。

      $ git reflog

      

      $ git reset --hard 3928d   # 再次回到第四次修改版本
      HEAD is now at 3928d9f 第四次修改

2.2 工作区和暂存区

• 概览

  • 理解工作区和暂存区的区别，暂存区是版本库的一个子集
  • 比较文件有三个不同命令
    • git diff
    • git diff --cached
    • git diff --HEAD

• 工作区

  工作区就是我们能看到的目录，如我前面创建的Git文件夹就是一个工作区

• 版本库 & 暂存区

  

  工作区有一个隐藏目录.git，不属于工作区而是Git版本库，版本库包含

  • Git自动创建的分支master&指向master的指针HEAD

  • stage（或叫index）暂存区

• 暂存区工作

  • git add

    这一步实际上就是把文件修改（已存在被修改 OR 新文件）添加到暂存区，可以add多个文件，一次被提交。

    

  • git commit

    把暂存区的所有内容提交到当前分支。

    但是注意，git commit 后暂存区文件不会消失，始终是上一次git add之后文件！

  • git diff &git diff --cached &git diff HEAD

    git diff 比较的是工作区文件和暂存区文件区别。

    git diff --cached 比较的是暂存区文件和仓库分支文件区别。

    git diff --HEAD 比较的是工作区文件和仓库分支最新版本区别。

    • 暂存区：就是 .git / index 这个文件，git add 会把工作区修改的文件添加到暂存区，即使 git commit 后也不会空，始终保存最近一次 git add后的内容。

    • 仓库分支：始终保存上次git commit 内容。

2.3 管理修改

• 概览

  • git管理的是修改，而非文件

• 实操

  新建一个文件 readme1.txt，然后依次：

  第一次修改 -> git add -> 第二次修改 -> git commit

  ​ 用git diff HEAD test/readme1.txt 比较工作区和版本分支，会发现第二次修改没有被提交，说明git只把git add后暂存区内容提交了，而不管理文件。

  如果要把第二次修改也提交了，需要进行以下操作：

  第一次修改 -> git add -> 第二次修改-> git add -> git commit

2.4 撤销修改

• 概览

  • 场景1：改乱了工作区某个文件的内容，想直接丢弃工作区的修改时

    用命令git checkout -- file。

  • 场景2：不但改乱了工作区某个文件的内容，还添加到了暂存区时，想丢弃修改

    • 第一步用命令git reset HEAD <file>，就回到了场景1
    • 第二步按场景1操作。

  • 场景3：已经提交了不合适的修改到版本库时，想要撤销本次提交

    参考版本回退一节，不过前提是没有推送到远程库。

• 实操

  • 场景1

    不小心在文件里增加了一句话：

    刘婷是傻子

    用 git checkout命令撤回工作区修改，有两种情况

    • readme.txt修改但未被放到暂存区，撤销修改就回到和版本库一样状态；
    • readme.txt修改且添加到暂存区后，撤销修改就回到添加到暂存区后的状态。

    ⚠️ 总之，就是让文件回到最近一次git commit或git add时的状态。

    🕵所以，也可用于恢复误删的文件（撤销工作区删除操作）

    git checkout -- test/readme.md

    

  • 场景2

    不小心在文件里增加了一句话，而且已经git add提交到暂存区

    刘婷是傻子哈哈哈

    命令git reset 不仅可以回退版本 而且可以把暂存区的修改撤销。

    ⚠️之所以不直接 git checkout 是因为此时会用暂存区内容覆盖工作区，显然不行。

    git reset HEAD test/readme.md # HEAD表示最新版本

    然后此时再用git checkout ，暂存区内容覆盖工作区

    git checkout -- test/readme.md

    再次查看文件发现，‘’刘婷是傻子哈哈哈‘’ 的胡话已经被没了，暂存区也没了。

  • 场景3

    又说胡话，不但 git add 且git commit（暂存区和版本库HEAD都是修改后版本）

    刘婷是傻子哈哈哈哈哈哈

    这个时候只有回退版本了

    $ git reflog  # 查看版本号

    $ git reset --hard  3928
    HEAD is now at 3928d9f 第四次修改

2.5 删除文件

• rm 删除

  • 原理

    rm 删除文件，只相当于删除了 工作区文件，如果要恢复文件撤销工作区修改即可。

    rm test/readme.md

  • 恢复

    用git checkout -- <file>，它会用最新版本库文件（如果已经git add 用最新暂存区内容，见前）覆盖工作区文件，则相当于撤销工作区修改

    git checkout -- test/readme.md

• git rm 删除

  • 原理

    git rm 删除文件，不但相当于删除工作区文件 & 而且git add添加到暂存区。

    所以此时直接git checkout 是用暂存区内容覆盖 工作区，显然是没用的。

  • 恢复

    • 先恢复暂存区

      git reset HEAD test/readme.md # HEAD表示最新版本

    • 再用暂存区覆盖工作区

      git checkout -- test/readme.md

  • 彻底删除

    如前所述，git rm 已经删除了 ①工作区文件 ② 添加到暂存区，那么此时只需要

    git commit --m '彻底删除'  # 将③版本库内容也修改

    那么文件就会从工作区、暂存区、版本库全部删除。

  • 彻底删除恢复

    如果已经commit，那么只能git reset回退版本

    $ git reset --hard  3928
    HEAD is now at 3928d9f 第四次修改

三、远程仓库

3.1 添加远程库上传本地文件

以下操作基于默认你

• 创建好 github 账号 & 创建好一个仓库
• 设置好本地ssh -key 而且已经同时在github网页服务端账号设置里添加 ssh -key

1. 添加用户信息

   $ git config --global user.name "hwh"
   $ git config --global user.email "380141202@qq.com"

2. 初始化本地仓库

   如果本地仓库从未被初始化才需要，初始化会创建一个隐藏的 .git 文件管理版本。

   • cd切换 + git init

     cd命令切换到后本地仓库；

     git init 初始化本地仓库，会为你创建一个 .git文件，已经初始化不用。

   • 手动 bash

     ⚠️ 很奇怪的是，这样 git add . --> git commit --> git push后，会把整个父文件夹推送上去。

     比如：地址 TEST 文件夹下有 README.md ，推送后github上显示的 TEST文件夹，而不是我想的README.md文件。

     右击本地仓库，选择Git Bash here

3. 把本地仓库添加到版本库

   $ git add .  # add . 提交所有新建、修改文件
   $ git commit -m '第一次添加本地仓库到版本库'

4. 本地仓库关联远程库

   git remote add <远程库名设置> <远程仓库地址>

   显然这里把远程仓库地址设置为 origin。

   $ git remote add origin git@github.com:huangwanghuiYY/gitTest.git

5. 推送到远程库

   下面代码表示：将本地master分支推送到远程仓库origin。

   $ git push -u origin master  # 第一次推送带 -u 参数

   -u选项指定一个默认主机，这样后面就可以不加任何参数使用git push。

   $ git push origin master

3.2 从远程库克隆

​ 当我们想多人协作时会用到克隆。比如有一个不错的开源项目，你可以克隆到本地仓库进行修改等。

1. 确定要克隆的仓库

   比如我的XSurvey项目。

2. git clone 进行克隆

   克隆会在当前文件夹创建克隆的仓库，克隆仓库以XSuery为名，下含项目文件。

   $ git clone git@github.com:huangwanghuiYY/XSurvey.git

   

四、分支管理

4.1 创建和合并分支

这一节，涉及大量图形，廖雪峰教程 讲的很好，这里尽量精简记录心得。

• 概述

  • 查看分支：git branch

  • 创建分支：git branch <name>

  • 切换分支：git checkout <name>

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

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

  • 删除分支：git branch -d <name>

• 实操记录

  • 主分支

    ​ master分支也是一条时间线，每次提交 master 分支都会向前移动一步，随着不断提交 master分支也就越长。

    ⚠️下图有两个指针：HEAD & master ，HEAD严格来说不是指向提交。HEAD指向master，master指向最新分支。

    

  • 新分支创建切换

    • 创建新分支

      $ git branch dev1   # 新建分支
      $ git branch        # 查看分支
        dev1
      * master           # * 表示当前所在的分支（master）

      ​ 当我们创建新的分支，例如dev时，Git新建了一个指针叫dev，指向master指向的提交。

      

    • 切换到当前分支

      $ git checkout -b dev1

      如果checkout 加上 -b参数，表示 创建 & 切换两个操作

      $ git checkout dev1

      切换到当前分支，其实把head指向master所指向的提交。

      ⚠️这张图，还表示dev分支还执行了一次提交。

      

  • 合并分支

    $ git checkout master  # 先切回master分支（即HEAD指向master）
    $ git merge dev1   # 表示当前分支（master）合并 dev1分支

    根据上图我们可以看到：

    ​ dev分支向前走了一步，dev指向了当前最新提交，而master指针依然指向上次提交。

    ​ 如果要合并，那么直接让master指向dev指向的当前提交 。相当于，master也提交过一次。

    

  • 删除分支

    $ git branch -d dev
    Deleted branch dev (was b17d20e).

    ​ 删除分支，等价于删除创建分支后的提交记录（上图红色线），但由于master指向了最新提交，等价复制dev1的提交记录（蓝色线）。

    

    ​

4.2 解决同时修改冲突

• 产生冲突原因

  

  • 在master分支上

    • 在当前master分支上，创建一个新分支 dev2

    • 同时master分支上，对README.md文件增加一句话

      i said master

    • ⚠️ 然后，git add --> git commit

  • 在dev2分支上

    • checkout切回master分支上，对README.md文件增加一句话

      i said dev2

    • ⚠️ 然后，git add --> git commit

  • 合并

    $ git checkout master
    $ git merge dev2

    显示，README.md文件同时被修改，发生冲突（也可用 git status 查看）

    

    vim 查看文件显示具体冲突：

    $ vim README.md #当前HEAD指向master，所以下图显示HEAD

    

• 解决冲突

  Ⓜ️此时两个README.md已经是一个文件了，文件内容就是上图vim查看的所有内容 。

  我们再命令行端口也可以看到，提示我们在 master|MERGING 合并中。

  

  ​ 我们打开文件，修改文件内容为：（第一句话有误，此时实在master分支上，不用在意）

  这是的dev分支，我增加了一句话

  修改冲突，这里变成这样。其实不修改直接提交也解决冲突，只是没解决同时修改。

  然后再提交，发现冲突已经解决：

  $ git add README.md 
  $ git commit -m '解决冲突'

  

4.3 分支管理策略 – 禁用Fast forward

• 概览

  通常，合并分支时，如果可能，Git会用Fast forward模式，则直接把 master 的指针直接指向了 dev 分支的最新提交，这样两个分支的最新提交的 commit id 就是一样的。但这种模式下，删除分支后，会丢掉分支信息。

  加上--no-ff参数，强制禁用Fast forward模式，使用普通模式。Git就会在merge时生成一个新的commit，这样，从分支历史上就可以看出分支信息。

• 实操

  默认已经创建好分支 dev3，且修该了文，进行了一次commit。

  然后下面都是在 master分支上尝试合并操作

  1. 切回master

     $ git checkout master

  2. 合并分支

     –no–ff ： 普通模式合并。

     -m ：由于本次合并dev要创建一个新的commit，所以加上-m参数，添加描述。

     $ git merge --no-ff -m "merge with no-ff" dev

  3. 查看历史

     $ git log --graph --pretty=oneline --abbrev-commit
     *   e1e9c68 (HEAD -> master) merge with no-ff
     |\  
     | * f52c633 (dev) add merge
     |/  
     *   cf810e4 conflict fixed

  4. Fast forward模式 & 普通模式 对比

     FF模式不用--no-ff，实际上只是将master的指针update成dev分支而已。用的还是dev的commit ID。

     普通模式用，则是重新commit一次，有了新的commit ID，保留了分支版本记录。

     • Fast forward模式

       

     • 普通模式

       

4.4 BUG分支—git stash

• 概览

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

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

• 实操（应用场景）

  1. master 上面发布的是A的1.0版本

  2. dev 上开发的是A的2.0版本 ，刚刚新建了test文件 &修改README.md：

     这里是dev分支。

     

  3. 这时，用户反映 1.0版本存在漏洞，有人利用这个漏洞开外挂

  4. 需要从dev切换到master去填这个漏洞，正常必须先提交dev目前的工作，才能切换。

     • 如果不commit切换分支：

       $ git checkout master 

       发现当前工作目录，是dev分支工作目录！

       

     • 解释1

       一个本地的git repo只有一个工作区和暂存区，但是有多个分支的提交区，而我们的checkout只是将HEAD指针从一个分支切换到另一个分支。

       所以：

       1. 切换后工作区内容是branch的工作内容

       2. 经过测试，如果切回dev分支，进行add --> commit 再切回master就回到 master工作区。

          

  5. 而dev的工作还未完成，不想提交，所以先把dev的工作stash一下，然后切换到master：

     1. 先git add test

        ⚠️ 为什么要先add test文件？

        test文件是新建，还未被git管理！让git add追踪test文件，否则即使 git stash ，test文件也依然会出现在master工作目录中！

        $ git add test

     2. git stash 然后切换

        $ git stash
        $ git checkout master

        

     3. 恢复dev工作目录

        简单恢复：

        $ git stash pop  # 恢复的同时把stash内容也删了

        有多个因此目录，可以配合下面目录恢复：

        $ git stash list  
        stash@{0}: WIP on dev: f52c633 add merge
        $ git stash apply stash@{0} # 恢复不会删除stash内容

  6. 在master建立分支issue101并切换。

  7. 在issue101上修复漏洞。

  8. 修复后，在master上合并issue101 。

  9. 切回dev，恢复原本工作，继续工作。

4.5 删除分支

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

4.6 多人协作

• 查看分支

  $ git remote -v  # 带-v参数查看更加详细

  

• push 推送分支

  git push <远程库名> <要推送分支名>

  ​ 推送本地主分支master到 origin master，相当用本地master版本覆盖远程origin master版本。

  ⚠️ git push 只能用户该项目属于自己的情况，因为要输入账号密码！参与他人开源：

  • 成为该开源项目贡献者（由项目作者设置）
  • fork 该项目 ----> clone到本地----> 修改 ----> 发起 pull requset —> 讨论 & 等待合并

  还有其他更多情况，如产生冲突等，查看：pro git 中文# 对项目做出贡献

  $ git push origin master

  

  推送其他分支到远程库 ，也可以查看。

  $ git push origin dev

  

• clone 克隆分支工作

  多人协作时，大家都会往远程库master和dev分支上推送各自的修改。

  1. 克隆主分支

     ⚠️ 克隆只能克隆master分支！！

     现在，模拟你的小伙伴，在另一台电脑（注意要把SSH Key添加到GitHub）克隆：

     $ git clone git@github.com:michaelliao/Python-100-Days

  2. 克隆远程dev分支开发

     由于只能克隆master分支，而又要在远程dev分支开发，那么：

     $ git checkout -b dev origin/dev

     之后就可进行修改 —> 提交 ：git push了

• git pull

  一种应用情况：A、B都克隆了项目，在远程分支dev上进行开发（分别在本地也克隆dev分支）

  1. A修改了文件 README，并进行了push提交 。

  2. 你也修改了README，进行提交修改，会出错，原因是

     ⚠️远程分支比你的本地更新！

  3. 只有先 pull 最新分支你的分支合并 —> 解决冲突—>提交

  git pull命令的作用是：取回远程主机某个分支的更新，再与本地的指定分支合并，它的完整格式稍稍有点复杂。

  在默认模式下，git pull是git fetch后跟git merge FETCH_HEAD的缩写。

  git pull == git fetch+ git merge （默认是检索头部合并到当前分支）

  ⚠️ 使用–rebase，它运行git rebase而不是git merge。

  $ git pull<可选参数> <远程主机名> <远程分支名>:<本地分支名>

  示例

  比如，要取回origin主机的next分支，与本地的master分支合并：

  $ git pull origin next:master

  • 省略当前分支名

    如果远程分支(next)要与当前分支合并，则冒号后面的部分可以省略。上面命令可以简写为：

    $ git pull origin next

    上面命令表示，取回origin/next分支，再与当前分支合并。实质上，这等同于先做git fetch，再执行git merge。

    $ git fetch origin
    $ git merge origin/next

  • 省略远程分支名

    某些场合，Git会自动在本地分支与远程分支之间，建立一种追踪关系(tracking)。比如，在git clone的时候，所有本地分支默认与远程主机的同名分支，建立追踪关系，也就是说，本地的master分支自动”追踪”origin/master分支。

    Git也允许手动建立追踪关系，指定master分支追踪origin/next分支：

    $ git branch --set-upstream master origin/next

    如果当前分支与远程分支存在追踪关系，git pull就可以省略远程分支名。

    $ git pull origin

    上面命令表示，本地的当前分支自动与对应的origin主机”追踪分支”(remote-tracking branch)进行合并。

  • 省略远程主机名

    如果当前分支只有一个追踪分支，连远程主机名都可以省略。

    $ git pull

  git fetch和git pull的区别

  1. git fetch：相当于是从远程获取最新版本到本地，不会自动合并。

  $ git fetch origin master
  $ git log -p master..origin/master
  $ git merge origin/master

  以上命令的含义：

  • 首先从远程的origin的master主分支下载最新的版本到origin/master分支上
  • 然后比较本地的master分支和origin/master分支的差别
  • 最后进行合并

  上述过程其实可以用以下更清晰的方式来进行：

  $ git fetch origin master:tmp
  $ git diff tmp 
  $ git merge tmp

  2. git pull：相当于是从远程获取最新版本并merge到本地

  git pull origin maste

五、标签管理

5.1 创建标签

5.2 操作标签

六、使用Github

6.1 简单上传

1. 设置用户信息

   $ git config --global user.name "hwh"
   $ git config --global user.email "380141202@qq.com"

2. git init 初始化仓库

   $ git init

3. 本地创建ssh key

   $ ssh-keygen -t rsa -C "380141202@qq.com" # 后面会要求设置密码可不设置

   然后会在：C:\Users\80651\.ssh 生成ssh key 文件，其下有一个公钥 id_rsa.pub，记事本打开复制。

4. 打开github设置

   打开github 在个人设置中添加**2.**中ssh key。

   可用 ssh -T查看是否成功

   $ ssh -T git@github.com

5. 对文件一些操作

   比如，这里以增加一个README文件，然后git commit 提交到版本库。

   $ git add README   # 也可add . 提交所有新建、修改文件
   $ git commit -m '增加readme'

6. push 上传到版本库

   $ git push origin master

   Q : git push 出现错误 ‘’ error: failed to push some refs to git‘’

   A : 一般是因为github中的README.md文件不在本地代码目录中

   • 添加 -f 参数强制覆盖

     git push -f origin master

   • 通过如下命令进行github与本地代码合并:

     $ git pull --rebase origin master   # 先和本地代码合并
     $ git push    # 然后再上传

6.2 参与开源项目

可参考：GitHub的Pull Request 是指什么意思

七、自定义Git

1. 服务器端安装Git

   $ yum install git

2. 创建用户 & 组 管理仓库目录

   $ groupadd git
   $ useradd git -g git  # -g 参数表示把用户gituser主组设置为 git

3. 创建目录

   我们先创建一个目录gitrepo用来管理其下仓库，一般习惯在 /var下创建。

   $ cd /var
   $ mkdir gitrepo

   给其设置好用户 & 组，便于管理

   $ chown -R gituser:git gitrepo # 把目录gitrepo 设置用户gituser & 组 git

   ls -l 查看是否设置成功：

   

4. 创建仓库

   创建hwhComputer2Backup.git仓库，并初始化用来上传电脑备份。

   $ cd gitrepo  # 注意先切换到git下
   $ git init --bare hwhComputer2Backup.git

5. 创建证书

   • 在本地电脑上

     执行以下命令创建ssh 公钥。会在：C:\Users\80651\\.ssh 生成ssh key 文件，其下有一个公钥 id_rsa.pub。

     $ ssh-keygen -t rsa -C "380141202@qq.com" # 后面会要求设置密码可不设置

   • 切回服务端

     裸机需创建/home/git/.ssh/authorized_keys文件。

     $ cd gitrepo/
     $ mkdir .ssh
     $ touch .ssh/authorized_keys

     然后把本地电脑上公钥复制导入，一行一个（？）

     $ vim .ssh/authorized_keys

     

6. 再次修改权限

   创建的子目录 用户 & 组 默认是 root root

   

   ⚠️由于.ssh & 仓库 hwhComputer2Backup.git 都不属于 gituser ，所有还需设置权限。否则进行 push pull 操作 没有足够权限。

   $ cd /var
   $ chown -R gituser:git gitrepo

7. 本地上传文件

   1. 添加用户信息

      $ git config --global user.name "hwh"
      $ git config --global user.email "380141202@qq.com"

   2. 初始化本地仓库

      $ cd D:/hwh/uploadToGit
      $ git init

   3. 把本地仓库添加到版本库

      错误：c#程序练习 does not have a commit checked out

      解决：是因为 c#程序练习 这个文件夹已经被初始化，查看隐藏文件可以发现 .git文件删除其即可。

      $ git add .  # add . 提交所有新建、修改文件
      $ git commit -m '第一次备份文件'

   4. 本地仓库关联远程库

      移除当前远程连接：

      git remote remove origin 

      git remote add origin <服务端用户名>@<远程库名地址>:<远程仓库地址>

      ⚠️<服务端用户名> : 是在服务端的用户！

      $ git remote add origin gituser@129.28.154.240:/var/gitrepo/hwhComputer2Backup.git

   5. 推送到远程库

      似乎由于 ssh key 设置不对，git push 要输入用户 gituser 的密码 123456？

      $ git push -u origin master  # 第一次推送带 -u 参数

      等待上传服务器(速度有点慢)：

      

八、debug 记录

ERROR：由于存在 >100M 文件，提交后报错，不允许提交超过100M 文件，进行如下操作：

• 压缩并删除>100M文件
• 将相应文件加入 .gitignore
• 再次commit --> push

依旧报相同错误。

解决办法如下，参考：Fixing the “GH001…

1. 删除文件

   建议可以先回退最近的commit 分支

   利用以下命令删除所有在仓库中 >100M 的文件：

   git filter-branch -f --index-filter 'git rm --cached --ignore-unmatch <大于100M文件URL>'

   例如，我的例子：

   git filter-branch -f --index-filter 'git rm --cached --ignore-unmatch  Experiment/Ex4_CustomerForecast/src/train.csv'

2. 再次提交

   为了保险，可以先：

   git rm -r --cached ./   # 本地代码不会被删除

   接下来正常：git add --> git commit --> git push 即可