Git 与 GitHub 入门实践

  数据结构23 分钟读完 (大约3486个字)

git配置

优先级：--local > --global > --system

用了--global这个参数，表示你这台机器上所有的Git仓库都会使用这个配置 ### 配置git用户名和邮箱

1
2
3
4
git config --global user.name        # 查看
git config --global user.name 用户名  # 修改
git config --global user.email       # 查看
git config --global user.email 邮箱   # 修改


仓库

创建git仓库

1
2
git init 仓库名  #创建一个git仓库
git init        #将一个项目转化为使用git管理（创建.git目录）

示例：

目录结构：

1
2
3
4
5
6
7
8
9
10
project
   |------.git
            |--------branches
            |--------config        #仓库的配置文件
            |--------description
            |--------HEAD
            |--------hooks
            |--------info
            |--------objects
            |--------refs

隐藏目录.git不算工作区，而是Git的版本库

查看仓库状态

1
git status

远程仓库

最早，肯定只有一台机器有一个原始版本库，此后，别的机器可以“克隆”这个原始版本库，而且每台机器的版本库其实都是一样的，并没有主次之分

实际情况往往是这样，找一台电脑充当服务器的角色，每天24小时开机，其他每个人都从这个“服务器”仓库克隆一份到自己的电脑上，并且各自把各自的提交推送到服务器仓库里，也从服务器仓库中拉取别人的提交

GitHub就是提供Git仓库托管服务的，所以，只要注册一个GitHub账号，就可以免费获得Git远程仓库，即Github为我们的git仓库提供了一个远程仓库，有了这个远程仓库，妈妈再也不用担心我的硬盘了

为本地与GitHub的通信配置ssh

本地git仓库和GitHub上的远程仓库之间的传输是通过SSH加密的，所以，需要一点设置：

  1. 创建ssh key： 
    1
    ssh-keygen -t rsa -C "youremail@example.com"
  2. 登录你的GitHub帐号，Settings -> SSH and GPG keys -> new SSH key ，将id_rsa.pub的内容复制进去

为什么GitHub需要SSH Key呢？因为GitHub需要识别出你推送的提交确实是你推送的，而不是别人冒充的，而Git支持SSH协议，所以，GitHub只要知道了你的公钥，就可以确认只有你自己才能推送

让本地git仓库和远程仓库同步

在有了本地git仓库后，还需创建对应的远程仓库

  1. 在GitHub上创建远程仓库（如果已有则省略）
  2. 为本地仓库设置远程仓库信息（如果同时需要为本地仓库添加多个远程仓库（如果github+码云），则可以将origin分别换成github和gitee，推送操作时也要修改origin。添加后，远程库的名字就是origin，这是Git默认的叫法，也可以改成别的，但是origin这个名字一看就知道是远程库） 
    1
    git remote add origin https://github.com/用户名/仓库名
    • 删除本地仓库的远程仓库信息：git remote remove origin
    • 修改远端地址：git remote set-url 新地址
    • 查看远程仓库信息：git remote -v
  3. 将本地git仓库push到远程仓库 
    1
    2
    3
    4
    # 由于远程库是空的，我们第一次推送master分支时，加上了-u参数,Git不但会把本地的
    # master分支内容推送的远程新的master分支，还会把本地的master分支和远程的master
    # 分支关联起来，在以后的推送或者拉取时就可以简化命令
    git push [-u] origin 分支名

并不是一定要把本地分支往远程推送。哪些分支需要推送、哪些不需要呢？

  • master：主分支，要时刻与远程同步
  • dev：开发分支，团队所有成员都需要在上面工作，所有也需要与远程同步
  • bug：只用于在本地修复bug，就没必要推送到远程了，除非老板要看看你每周修复了几个bug

协同工作

拉取分支：

1
git pull

git clone时，默认情况下只能看到本地的master分支。如果要在dev分支上开发，就必须创建远程origin的dev分支到本地，可以使用如下命令创建本地dev分支：

1
git checkout -b dev

将本地dev分支与远程origin/dev分支关联起来：

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

使用GitHub

Bootstrap的官方仓库twbs/bootstrap、你在GitHub上克隆的仓库my/bootstrap，以及你自己克隆到本地电脑的仓库，他们的关系就像下图显示的那样：

如果你想修复bootstrap的一个bug，或者新增一个功能，立刻就可以开始干活，干完后，往自己的仓库推送

如果你希望bootstrap的官方库能接受你的修改，你就可以在GitHub上发起一个pull request。当然，对方是否接受你的pull request就不一定了


版本控制

隐藏目录.git不算工作区，而是Git的版本库。版本库里存了很多东西，其中最重要的就是称为stage（或者叫index）的暂存区。还有Git为我们自动创建的第一个分支master，以及指向master的一个指针叫HEAD

添加或删除修改

将修改添加到暂存区：

1
git add 文件/目录

从暂存区删除修改：

1
git rm --cached 文件/目录

以下命令可以将暂存区的修改重置，暂存区的改变会被移除到工作区：

1
git reset HEAD [文件名]

以下命令可以丢弃工作区的修改：

1
git checkout -- [文件名]

如果刚对一个文件进行了编辑，可以撤销文件的改变，回到编辑开始。命令其实起到“一键恢复”的作用，还可用于“误删恢复”。可以在 git reset HEAD [文件名] 后使用

提交版本

如果修改了readme.txt，添加了文件LICENSE，并将2者添加到暂存区后，暂存区的状态就变成这样：

使用commit提交修改，实际上就是把暂存区的所有内容提交到当前分支：

1
git commit -m '信息'

commit相当于游戏里面一次存档。对应一个版本

文件删除

rm做出的删除不会被暂存，git rm做出的改变会被暂存。如果使用rm删除掉，能使用git rm来暂存。git rm不在意文件已经不存在了

  • 删除(暂存)单个文件

    1
    git rm

  • 删除(暂存)多个文件（一般情况下，更可能是对大量文件进行管理。可能同时会删除很多文件，不可能使用git rm一个个删除）

    1
    2
    # 它会变量当前目录，将所有删除暂存
    git add -u .

如果有文件被误删，可以使用git checkout -- 文件名恢复

工作现场保存与恢复

有时候在修复bug或某项任务还未完成，但是需要紧急处理另外一个问题。此时可以先保存工作现场，当问题处理完成后，再恢复bug或任务的进度

  • 保存工作现场：git stash
  • 查看保存的工作现场：git stash list
  • 恢复工作现场：git stash apply
  • 删除stash内容：git stash drop
  • 恢复工作现场并删除stash内容（相当于上面2步合并）：git stash pop

改动查询

1
2
3
4
5
6
7
git diff [选项]           # 查看工作区中的修改
git diff [选项] --staged   # 查看已添加到暂存区的修改
git diff [选项] HEAD       # 查看当前所有未提交的修改

选项：
    --color-words： 颜色
    --stat：        不显示具体修改，只显示修改了的文件

版本回退

1
2
3
4
5
6
git reset --hard 版本ID/HEAD形式的版本

git reset --hard HEAD      # 当前版本
git reset --hard HEAD^     # 上一个版本
git reset --hard HEAD^^    # 上上个版本
git reset --hard HEAD~n    # 前n个版本

如果回到过去的版本，想要回到原来新的版本：

  • 如果终端未关，可以找到新版本的id，通过上述命令回去新版本
  • 如果终端已关，git reflog查看版本，再通过上述命令回去新版本

查看历史提交

1
2
3
4
5
6
7
git log [选项]

选项：
    --online：只显示提交提示信息
    --stat：添加每次提交包含的文件信息
    --path：查看每次提交改变的内容
    --graph

加文件名可以显示具体文件相关的所有提交信息


分支管理

创建与合并分支

每次commit相当于一次存档，对应一个版本。Git都把它们串成一条时间线，这条时间线就是一个分支。master就是主分支。HEAD指向当前分支，而master指向主分支的最近提交。每次提交，master分支都会向前移动一步

当创建一个分支时，如dev，Git创建一个指针dev，指向master相同的提交，再把HEAD指向dev，就表示当前分支在dev上：

从现在开始，对工作区的修改和提交就是针对dev分支了，比如新提交一次后，dev指针往前移动一步，而master指针不变：

假如我们在dev上的工作完成了，就可以把dev合并到master上。最简单的方法，就是直接把master指向dev的当前提交，就完成了合并：

合并完分支后，甚至可以删除dev分支。删除dev分支就是把dev指针给删掉，删掉后，我们就剩下了一条master分支：

上面的合并使用的是Fast forward。这种模式下，删除分支后，会丢掉分支信息。如果要强制禁用Fast forward模式，Git就会在merge时生成一个新的提交，这样，从分支历史上就可以看出分支信息。通过在git merge命令中使用--no-ff选项禁用Fast forward模式。比如在合并dev时：

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

由于会生成一个新的提交，所以需要使用-m指明新提交的信息。此时分支情况如下：

相关命令如下：

  • (创建分支并)切换到新分支：git checkout -b 新分支
  • 创建分支：git branch 新分支
  • 切换分支：git checkout 欲切换到的分支
  • 查看当前分支：git branch
  • 合并某分支到当前分支：git merge 欲合并到当前分支的分支
  • 查看历史分支情况：git log --graph --pretty=oneline --abbrev-commit
  • 删除未合并的分支：git branch -D 分支

分支合并冲突

如果两个分支修改了同一文件，合并时会发生冲突。比如master分支和feature1分支都修改了readme.txt文件，各自都有新的提交：

这种情况下，Git无法执行“快速合并”，只能试图把各自的修改合并起来，但这种合并就可能会有冲突。此时readme.txt文件会变成如下形式：

1
2
3
4
5
6
7
8
9
Git is a distributed version control system.
Git is free software distributed under the GPL.
Git has a mutable index called stage.
Git tracks changes of files.
<<<<<<< HEAD
Creating a new branch is quick & simple.
=======
Creating a new branch is quick AND simple.
>>>>>>> feature1

Git用<<<<<<<，=======，>>>>>>>标记出不同分支的内容，此时需要手动修改后保存。然后再使用git commit进行一次提交。分支会变成如下：

分支管理策略

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

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

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

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

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

当你从远程仓库克隆时，实际上Git自动把本地的master分支和远程的master分支对应起来了，并且，远程仓库的默认名称是origin

要查看远程库的信息，用git remote：

1
2
$ git remote
origin

或者，用git remote -v显示更详细的信息：

1
2
3
$ git remote -v
origin  git@github.com:michaelliao/learngit.git (fetch)
origin  git@github.com:michaelliao/learngit.git (push)

上面显示了可以抓取和推送的origin的地址。如果没有推送权限，就看不到push的地址

推送分支

1
git push origin 欲推送的分支
  • master分支是主分支，因此要时刻与远程同步
  • dev分支是开发分支，团队所有成员都需要在上面工作，所以也需要与远程同步
  • bug分支只用于在本地修复bug，就没必要推到远程了，除非老板要看看你每周到底修复了几个bug
  • feature分支是否推到远程，取决于你是否和你的小伙伴合作在上面开发

Git 与 GitHub 入门实践

https://hunlp.com/posts/1640691208.html

作者

ฅ´ω`ฅ

发布于

2015-02-28

更新于

2019-02-28

许可协议

 

喜欢这篇文章？打赏一下作者吧

评论

×