The future of you, waiting for you in the future.

Geoffrey

Long, long the pathway to Cold Hill;
Drear, drear the waterside so chill.

返回顶部

Git 详解

git 仓库管理

再开始这个话题之前,让我想起了一件很痛苦的事情,在我大学写毕业论文的时候,我当时的文件是这样保存的

毕业论文_初稿.doc
毕业论文_修改1.doc
毕业论文_修改2.doc
毕业论文_修改3.doc
毕业论文_完整版1.doc
毕业论文_完整版2.doc
毕业论文_完整版3.doc
毕业论文_死也不改版.doc
毕业论文_最终版1.doc
毕业论文_最终版2.doc

这个时候,我们会重复的提交给导师,导师也会帮我们修改毕业论文,我自己这里的还好说,那么如果是导师再给我返回回来的文件,我就要想想,我是什么时候提交给导师的,我要把我后面写的东西跟导师写的东西都添加到我的最新的版本中

以上就是使用最原始的方式进行版本控制，但是这种方式有显著缺点：

  • 多个文件，保留所有版本时，需要为每个版本保存一个文件...
  • 协同操作，多人协同操作时，需要将文件打包发来发去...
  • 容易丢失，被删除意味着永远失去...（可以选择网盘）

这个时候我就想,如果能有一个软件来帮助我来解决这个问题的话,那是多么好的一件事啊,这样我自己就不需要去保存所有的文件了,什么时候需要直接在软件里面看一下,岂不是很方便.

版本 文件名 用户 说明 日期
1.0版本 毕业论文 张三 新建 2018.1.12
1.1版本 毕业论文 张三 写了第一部分 2018.2.12
2.0版本 毕业论文 张三 写完了全部 2018.3.23
3.0版本 毕业论文 张三 答辩使用 2018.4.25

这样你就从版本管理的农耕时代直接进入到了版本控制的21世纪,为了解决以上版本控制存在问题，应运而生了一批版本控制工具：VSS、CVS、SVN、Git等，其中Git属于绝对霸主地位。

什么是git？

Git 是一个开源的分布式版本控制软件,用以有效、高速的处理从很小到非常大的项目版本管理。 Git 最初是由Linus Torvalds设计开发的，用于管理Linux内核开发。Git 是根据GNU通用公共许可证版本2的条款分发的自由/免费软件，安装参见：http://git-scm.com/

GitHub是一个基于Git的远程文件托管平台（同GitCafe、BitBucket和GitLab等）。

Git本身完全可以做到版本控制，但其所有内容以及版本记录只能保存在本机，如果想要将文件内容以及版本记录同时保存在远程，则需要结合GitHub来使用。使用场景：

  • 无GitHub：在本地 .git 文件夹内维护历时文件
  • 有GitHub：在本地 .git 文件夹内维护历时文件，同时也将历时文件托管在远程仓库

其他：

集中式：远程服务器保存所有版本，用户客户端有某个版本

分布式：远程服务器保存所有版本，用户客户端有所有版本

安装

如果你想在 Linux 上用二进制安装程序来安装 Git，可以使用发行版包含的基础软件包管理工具来安装。 如果以 Fedora 上为例，你可以使用 yum：

  $ sudo yum install git

如果你在基于 Debian 的发行版上，请尝试用 apt-get：

  $ sudo apt-get install git

在 Mac 上安装

在 Mac 上安装 Git 有多种方式。 最简单的方法是安装 Xcode Command Line Tools。 Mavericks （10.9） 或更高版本的系统中，在 Terminal 里尝试首次运行 git 命令即可。 如果没有安装过命令行开发者工具，将会提示你安装。

如果你想安装更新的版本，可以使用二进制安装程序。 官方维护的 OSX Git 安装程序可以在 Git 官方网站下载，网址为 <http://git-scm.com/download/mac>;。

在 Windows 上安装

在 Windows 上安装 Git 也有几种安装方法。 官方版本可以在 Git 官方网站下载。 打开 <http://git-scm.com/download/win>，下载会自动开始。 要注意这是一个名为 Git for Windows的项目（也叫做 msysGit），和 Git 是分别独立的项目；更多信息请访问 <http://msysgit.github.io/>;。

另一个简单的方法是安装 GitHub for Windows。 该安装程序包含图形化和命令行版本的 Git。 它也能支持 Powershell，提供了稳定的凭证缓存和健全的 CRLF 设置。 稍后我们会对这方面有更多了解，现在只要一句话就够了，这些都是你所需要的。 你可以在 GitHub for Windows 网站下载，网址为 http://windows.github.com。

命令行

Git 有多种使用方式。 你可以使用原生的命令行模式，也可以使用 GUI 模式，这些 GUI 软件也能提供多种功能。 在本书中，我们将使用命令行模式。 这是因为首先，只有在命令行模式下你才能执行 Git 的 所有命令，而大多数的 GUI 软件只实现了 Git 所有功能的一个子集以降低操作难度。 如果你学会了在命令行下如何操作，那么你在操作 GUI 软件时应该也不会遇到什么困难，但是，反之则不成立。 此外，由于每个人的想法与侧重点不同，不同的人常常会安装不同的 GUI 软件，但 所有 人一定会有命令行工具。

假如你是 Mac 用户，我们希望你懂得如何使用终端（Terminal）；假如你是 Windows 用户，我们希望你懂得如何使用命令窗口（Command Prompt）或 PowerShell。 如果你尚未掌握以上技能，我们建议你先停下来快速学习一下，本书中的讲述和举例将用到这些技能。

git基础操作

1、在现有目录中初始化仓库

如果你打算使用 Git 来对现有的项目进行管理，你只需要进入该项目目录并输入：

[Derek@git]$ git init

该命令将创建一个名为 .git 的子目录，这个子目录含有你初始化的 Git 仓库中所有的必须文件。 但是，在这个时候，我们仅仅是做了一个初始化的操作，你的项目里的文件还没有被跟踪。

2、用命令git add告诉Git，把文件添加到缓存区：

[Derek@git]$ git add readme.txt

执行上面的命令，没有任何显示，这就对了，Unix的哲学是“没有消息就是好消息”，说明添加成功。

3、用命令git commit告诉Git，把文件提交到仓库（版本库）

[Derek@git]$ git commit -m "wrote a readme file"
[master (root-commit) eaadf4e] wrote a readme file
 1 file changed, 2 insertions(+)
 create mode 100644 readme.txt

简单解释一下git commit命令，-m后面输入的是本次提交的说明，可以输入任意内容，当然最好是有意义的，这样你就能从历史记录里方便地找到改动记录。

git commit命令执行成功后会告诉你，1 file changed：1个文件被改动（我们新添加的readme.txt文件）；2 insertions：插入了两行内容（readme.txt有两行内容）。

4、git status查看已暂存和未暂存的修改

我们已经成功地添加并提交了一个readme.txt文件，现在，是时候继续工作了，于是，我们继续修改readme.txt文件，改成如下内容：

Git is a distributed version control system.
Git is free software.

现在，运行git status命令看看结果：

[Derek@git]$ 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      #更改的文件为readme.txt

no changes added to commit (use "git add" and/or "git commit -a")

git status命令可以让我们时刻掌握仓库当前的状态，上面的命令输出告诉我们，readme.txt被修改过了，但还没有准备提交的修改。

得到上面这个结果说明我们的readme.txt已经被修改了，但是还没有添加到缓存区，也就是还没有执行git add的操作，括号里面的内容提示我们此刻建议我们进行 git add file操作或者是git checkout -- file操作。

可自行测试当执行完git add 操作之后再执行git status显示的内容信息。

5、git diff 查看具体修改了什么地方

git diff 将通过文件补丁的格式显示具体哪些行发生了改变。

[Derek@git]$ git diff
diff --git a/README.md b/README.md
index e69de29..a34691f 100644
--- a/README.md
+++ b/README.md
@@ -0,0 +1 @@
+this is new line

此命令比较的是工作目录中当前文件和暂存区域快照之间的差异。

若要查看缓存区和版本库之间的差别，可以用 git diff --cached 命令。（Git 1.6.1 及更高版本还允许使用 git diff --staged，效果是相同的，但更好记些。）

[Derek@git]$ git diff  --staged
diff --git a/README.md b/README.md
new file mode 100644
index 0000000..e69de29

6、提交更新

现在的暂存区域已经准备妥当可以提交了。 在此之前，请一定要确认还有什么修改过的或新建的文件还没有 git add 过，否则提交的时候不会记录这些还没暂存起来的变化。 这些修改过的文件只保留在本地磁盘。 所以，每次准备提交前，先用 git status 看下，是不是都已暂存起来了， 然后再运行提交命令 git commit：

-m 选项，将提交信息与命令放在同一行

[Derek@git]$ git commit -m 'create'
[master (root-commit) 88a09aa] create
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 README.md

ps：git add * 可以一次性提交所有文件到缓存区

7、跳过使用暂存区域

尽管使用暂存区域的方式可以精心准备要提交的细节，但有时候这么做略显繁琐。 Git 提供了一个跳过使用暂存区域的方式， 只要在提交的时候，给 git commit 加上 -a 选项，Git 就会自动把所有已经跟踪过的文件暂存起来一并提交

[Derek@git]git commit -a -m  'update'
[master 86d801b] update
 1 file changed, 1 insertion(+)

8、查看提交历史

[Derek@git]$ git log
commit 86d801bbaa4cc560acc7c8f79a65cac85201f170 (HEAD -> master)
Author: wangfeng7399 <wangfeng17399@163.com>
Date:   Tue Feb 19 18:48:48 2019 +0800

    update

commit 88a09aa009af29e9a784d6dbb68589f70f1c51be
Author: wangfeng7399 <wangfeng17399@163.com>
Date:   Tue Feb 19 18:48:04 2019 +0800

    create

-p 用来显示每次提交的内容差异

你也可以加上 -2 来仅显示最近两次提交

[Derek@git]git log -p -2
commit 86d801bbaa4cc560acc7c8f79a65cac85201f170 (HEAD -> master)
Author: wangfeng7399 <wangfeng17399@163.com>
Date:   Tue Feb 19 18:48:48 2019 +0800

    update

diff --git a/README.md b/README.md
index e69de29..a34691f 100644
--- a/README.md
+++ b/README.md
@@ -0,0 +1 @@
+this is new line

commit 88a09aa009af29e9a784d6dbb68589f70f1c51be
Author: wangfeng7399 <wangfeng17399@163.com>
Date:   Tue Feb 19 18:48:04 2019 +0800

    create

diff --git a/README.md b/README.md
new file mode 100644
index 0000000..e69de29

另外一个常用的选项是 --pretty。 这个选项可以指定使用不同于默认格式的方式展示提交历史。 这个选项有一些内建的子选项供你使用。 比如用 oneline 将每个提交放在一行显示，查看的提交数很大时非常有用。 另外还有 short，full 和 fuller 可以用，展示的信息或多或少有些不同，请自己动手实践一下看看效果如何。

[Derek@git]$ git log --pretty=oneline
ca82a6dff817ec66f44342007202690a93763949 changed the version number
085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7 removed unnecessary test
a11bef06a3f659402fe7563abf99ad00de2209e6 first commit

但最有意思的是 format，可以定制要显示的记录格式。 这样的输出对后期提取分析格外有用 — 因为你知道输出的格式不会随着 Git 的更新而发生改变：

git log --pretty=format 常用的选项 列出了常用的格式占位符写法及其代表的意义。

选项 说明
%H 提交对象（commit）的完整哈希字串
%h 提交对象的简短哈希字串
%T 树对象（tree）的完整哈希字串
%t 树对象的简短哈希字串
%P 父对象（parent）的完整哈希字串
%p 父对象的简短哈希字串
%an 作者（author）的名字
%ae 作者的电子邮件地址
%ad 作者修订日期（可以用 --date= 选项定制格式）
%ar 作者修订日期，按多久以前的方式显示
%cn 提交者（committer）的名字
%ce 提交者的电子邮件地址
%cd 提交日期
%cr 提交日期，按多久以前的方式显示
%s 提交说明 
git log --pretty=format:"%h,%an"      #使用格式

git log 的常用选项

选项 说明
-p 按补丁格式显示每个更新之间的差异。
--stat 显示每次更新的文件修改统计信息。
--shortstat 只显示 --stat 中最后的行数修改添加移除统计。
--name-only 仅在提交信息后显示已修改的文件清单。
--name-status 显示新增、修改、删除的文件清单。
--abbrev-commit 仅显示 SHA-1 的前几个字符，而非所有的 40 个字符。
--relative-date 使用较短的相对时间显示（比如，“2 weeks ago”）。
--graph 显示 ASCII 图形表示的分支合并历史。
--pretty 使用其他格式显示历史提交信息。可用的选项包括 oneline，short，full，fuller 和 format（后跟指定格式）。

在 限制 git log 输出的选项 中列出了常用的选项

选项 说明
-(n) 仅显示最近的 n 条提交
--since, --after 仅显示指定时间之后的提交。
--until, --before 仅显示指定时间之前的提交。
--author 仅显示指定作者相关的提交。
--committer 仅显示指定提交者相关的提交。
--grep 仅显示含指定关键字的提交
-S 仅显示添加或移除了某个关键字的提交

9、git reset HEAD file取消暂存的文件

例如，你已经修改了两个文件并且想要将它们作为两次独立的修改提交，但是却意外地输入了 git add * 暂存了它们两个。 如何只取消暂存两个中的一个呢？ git status 命令提示了你：

[Derek@git]git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    modified:   README.md

[Derek@git]git reset HEAD README.md
Unstaged changes after reset:
M   README.md
[Derek@git]$ 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.md

no changes added to commit (use "git add" and/or "git commit -a")

10、git reset --hard 提交对象的哈希值， 回滚到之前的某一个版本

hard后面可以输入提交对象完整的哈希值，也可以输入提交对象剪短的哈希值。

11、git checkout -- file 撤销对文件的修改

如果你并不想保留对 README.md 文件的修改怎么办？ 你该如何方便地撤消修改 - 将它还原成上次提交时的样子（或者刚克隆完的样子，或者刚把它放入工作目录时的样子）？ 幸运的是，git status也告诉了你应该如何做。 在最后一个例子中，未暂存区域是这样：

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.md

它非常清楚地告诉了你如何撤消之前所做的修改。 让我们来按照提示执行：

$ git checkout  -- README.md
$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    renamed:    README.md -> README

可以看到那些修改已经被撤消了。

你需要知道 git checkout -- [file] 是一个危险的命令，这很重要。 你对那个文件做的任何修改都会消失 - 你只是拷贝了另一个文件来覆盖它。 除非你确实清楚不想要那个文件了，否则不要使用这个命令。

git 分支

有人把 Git 的分支模型称为它的`‘必杀技特性’'，也正因为这一特性，使得 Git 从众多版本控制系统中脱颖而出。 为何 Git 的分支模型如此出众呢？ Git 处理分支的方式可谓是难以置信的轻量，创建新分支这一操作几乎能在瞬间完成，并且在不同分支之间的切换操作也是一样便捷。 与许多其它版本控制系统不同，Git 鼓励在工作流程中频繁地使用分支与合并，哪怕一天之内进行许多次。 理解和精通这一特性，你便会意识到 Git 是如此的强大而又独特，并且从此真正改变你的开发方式。

分支操作

1、git branch 查看所有分支

2、git branch name 创建分支

Git 是怎么创建新分支的呢？ 很简单，它只是为你创建了一个可以移动的新的指针。 比如，创建一个 testing 分支， 你需要使用 git branch 命令：

$ git branch testing

3、git checkout name 切换分支

要切换到一个已存在的分支，你需要使用 git checkout 命令。 我们现在切换到新创建的 testing 分支去：

$ git checkout testing

创建一个新的分支，并切换到刚创建的这个分支中，一条命令搞定：

$ git checkout -b dev
Switched to a new branch 'dev'

git checkout命令加上-b参数表示创建并切换，相当于以下两条命令：

$ git branch dev
$ git checkout dev
Switched to branch 'dev'

然后，用git branch命令查看当前分支：

$ git branch
* dev
  master

git branch命令会列出所有分支，当前分支前面会标一个*号。

4、git branch -d name 分支删除

5、git merge name 分支合并

假设你正在通过一个临时新分支bug-53修复一个bug，修复后需要需要与master分支进行合并。

$ git checkout master
Switched to branch 'master'
$ git merge bug-53
Merge made by the 'recursive' strategy.
index.html |    1 +
1 file changed, 1 insertion(+)

遇到冲突时的分支合并

有时候合并操作不会如此顺利。 如果你在两个不同的分支中，对同一个文件的同一个部分进行了不同的修改，Git 就没法干净的合并它们。 如果你对 #53 问题的修改和有关 hotfix 的修改都涉及到同一个文件的同一处，在合并它们的时候就会产生合并冲突：

$ git merge iss53
Auto-merging index.html
CONFLICT (content): Merge conflict in index.html
Automatic merge failed; fix conflicts and then commit the result.

此时 Git 做了合并，但是没有自动地创建一个新的合并提交。 Git 会暂停下来，等待你去解决合并产生的冲突。 你可以在合并冲突后的任意时刻使用 git status 命令来查看那些因包含合并冲突而处于未合并（unmerged）状态的文件：

$ git status
On branch master
You have unmerged paths.
  (fix conflicts and run "git commit")

Unmerged paths:
  (use "git add <file>..." to mark resolution)

    both modified:      index.html

no changes added to commit (use "git add" and/or "git commit -a")

任何因包含合并冲突而有待解决的文件，都会以未合并状态标识出来。 Git 会在有冲突的文件中加入标准的冲突解决标记，这样你可以打开这些包含冲突的文件然后手动解决冲突。 出现冲突的文件会包含一些特殊区段，看起来像下面这个样子：

<<<<<<< HEAD:index.html
<div id="footer">contact : email.support@github.com</div>
=======
<div id="footer">
 please contact us at support@github.com
</div>
>>>>>>> iss53:index.html

这表示 HEAD 所指示的版本（也就是你的 master 分支所在的位置，因为你在运行 merge 命令的时候已经检出到了这个分支）在这个区段的上半部分（======= 的上半部分），而 iss53 分支所指示的版本在 ======= 的下半部分。 为了解决冲突，你必须选择使用由 ======= 分割的两部分中的一个，或者你也可以自行合并这些内容。 例如，你可以通过把这段内容换成下面的样子来解决冲突：

<div id="footer">
please contact us at email.support@github.com
</div>

上述的冲突解决方案仅保留了其中一个分支的修改，并且 &lt;&lt;&lt;&lt;&lt;&lt;&lt; , ======= , 和 &gt;&gt;&gt;&gt;&gt;&gt;&gt; 这些行被完全删除了。 在你解决了所有文件里的冲突之后，对每个文件使用 git add 命令来将其标记为冲突已解决。 一旦暂存这些原本有冲突的文件，Git 就会将它们标记为冲突已解决。

分支管理

面试题:

你们公司如何基于git做版本控制

master 分支是用来存放生产环境的代码

dev分支是用来开发的

会临时创建bug分支来修复线上的bug,修复完成合并到master,删除bug分支

bug分支

软件开发中，bug就像家常便饭一样。有了bug就需要修复，在Git中，由于分支是如此的强大，所以，每个bug都可以通过一个新的临时分支来修复，修复后，合并分支，然后将临时分支删除。

当你接到一个修复一个代号101的bug的任务时，很自然地，你想创建一个分支issue-101来修复它，但是，等等，当前正在dev上进行的工作还没有提交：

$ git status
On branch dev
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    new file:   hello.py

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

并不是你不想提交，而是工作只进行到一半，还没法提交，预计完成还需1天时间。但是，必须在两个小时内修复该bug，怎么办？

幸好，Git还提供了一个stash功能，可以把当前工作现场“储藏”起来，等以后恢复现场后继续工作：

$ git stash
Saved working directory and index state WIP on dev: f52c633 add merge

现在，用git status查看工作区，就是干净的（除非有没有被Git管理的文件），因此可以放心地创建分支来修复bug。

首先确定要在哪个分支上修复bug，假定需要在master分支上修复，就从master创建临时分支：

$ git checkout master
Switched to branch 'master'
Your branch is ahead of 'origin/master' by 6 commits.
  (use "git push" to publish your local commits)

$ git checkout -b issue-101
Switched to a new branch 'issue-101'

现在修复bug，需要把“Git is free software ...”改为“Git is a free software ...”，然后提交：

$ git add readme.txt 
$ git commit -m "fix bug 101"
[issue-101 4c805e2] fix bug 101
 1 file changed, 1 insertion(+), 1 deletion(-)

修复完成后，切换到master分支，并完成合并，最后删除issue-101分支：

$ git checkout master
Switched to branch 'master'
Your branch is ahead of 'origin/master' by 6 commits.
  (use "git push" to publish your local commits)

$ git merge --no-ff -m "merged bug fix 101" issue-101
Merge made by the 'recursive' strategy.
 readme.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

太棒了，原计划两个小时的bug修复只花了5分钟！现在，是时候接着回到dev分支干活了！

$ git checkout dev
Switched to branch 'dev'

$ git status
On branch dev
nothing to commit, working tree clean

工作区是干净的，刚才的工作现场存到哪去了？用git stash list命令看看：

$ git stash list
stash@{0}: WIP on dev: f52c633 add merge

工作现场还在，Git把stash内容存在某个地方了，但是需要恢复一下，有两个办法：

一是用git stash apply恢复，但是恢复后，stash内容并不删除，你需要用git stash drop来删除；

另一种方式是用git stash pop，恢复的同时把stash内容也删了：

$ git stash pop
On branch dev
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    new file:   hello.py

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

Dropped refs/stash@{0} (5d677e2ee266f39ea296182fb2354265b91b3b2a)

你可以多次stash，恢复的时候，先用git stash list查看，然后恢复指定的stash，用命令：

$ git stash apply stash@{0}

dev 分支

软件开发中，总有无穷无尽的新的功能要不断添加进来。

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

现在，你终于接到了一个新任务：开发代号为Vulcan的新功能，该功能计划用于下一代星际飞船。

于是准备开发：

$ git checkout -b dev-vulcan
Switched to a new branch 'dev-vulcan'

5分钟后，开发完毕：

$ git add vulcan.py

$ git status
On branch dev-vulcan
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    new file:   vulcan.py

$ git commit -m "add feature vulcan"
[feature-vulcan 287773e] add feature vulcan
 1 file changed, 2 insertions(+)
 create mode 100644 vulcan.py

切回dev，准备合并：

$ git checkout dev

一切顺利的话，feature分支和bug分支是类似的，合并，然后删除。

但是！

就在此时，接到上级命令，因经费不足，新功能必须取消！

虽然白干了，但是这个包含机密资料的分支还是必须就地销毁：

$ git branch -d  dev-vulcan
error: The branch 'dev-vulcan' is not fully merged.
If you are sure you want to delete it, run 'git branch -D dev-vulcan'.

销毁失败。Git友情提醒，dev-vulcan分支还没有被合并，如果删除，将丢失掉修改，如果要强行删除，需要使用大写的-D参数。。

现在我们强行删除：

$ git branch -D dev-vulcan
Deleted branch dev-vulcan (was 287773e).

终于删除成功！

#stash  相关指令

git stash  将当前开发的内容放在"某个地方"

git stash pop 恢复当前的工作目录,并删除

git stash list  查看stash列表

git stash drop 删除stash

git stash apply 恢复当前的工作目录,不删除stash

git从远程仓库拉取内容或向远程仓库上传内容

一、将本地文件上传到远程仓库步骤

git init
git add .
git commit -m "初始框架"
git remote add origin https://github.com/417685417/91video.git  #连接远程仓库并将远程仓库取别名为origin
git push origin master #将本地master分支的内容上传到远程仓库  
git push origin dev #将本地dev分支的内容上传到远程仓库
git pull origin dev  #拉取远程仓库dev分支的内容
#上面这条命令相当于执行了以下两条命令
git fetch
git merge origin/dev

二、将项目从远程仓库拉取到本地或为其它开源项目共享自己的一份力

git clone https://github.com/417685417/91video.git
git branch    #发现只有master分支
* master
git branch dev origin/dev  #拉取远程dev分支
git checkout dev    #切换到dev分支

#注意在push之前先进行pull操作

三、.gitignore文件（忽略不需要上传的文件）

touch d.py    #d.py为忽略文件
vi .gitignore    
写入  d.py     
#此时d.py就成为了忽略文件，不会别其他人看见

#一般被忽略的文件请参考如下链接内容：
https://github.com/github/gitignore/blob/master/Python.gitignore

四、如何为github上牛逼的开源项目贡献代码#

可以先用fork拷贝开源项目到自己的GitHub上，更改别人的bug之后想返回给原项目人使用new pull request

五、tag标签，实现版本的管理

git tag   #列出标签
git tag -a v1.0 -m'创建1.0版本'
git push origin --tags  #上传标签
#也可以对过去提交的内容大标签
git tag -a v0.1 提交对象的md5值

gitlab在公司内部使用，有人对gitlib做了中文的翻译

六、rebase变基， 用来将提交记录变成一条直线

git rebase dev

转自：https://www.cnblogs.com/fengchong/p/10435344.html

posted @ 2019-12-12 12:45  Geoffreygau  阅读(429)  评论(0)    收藏  举报