始终想写一下 git 的笔记, 只是都没有工夫去做, 只能闲暇的时候缓缓的补齐了;
毫无疑问, git 是目前最优良的分布式版本控制工具, 没有之一; 作为一个码农, git 曾经是一项必备的技能了, 许多优良的社区都是基于 git 去做的版本控制; 比方寰球最大的程序猿同性交友网站 github ;
git 有很多种应用形式, 咱们能够应用 git bash 这种命令行模式, 也能够应用 TortoiseGit 或者是 SourceTree 这样的 GUI 工具, 这些 GUI 工具也能提供多种性能; 而集体还是比拟偏向于命令行的形式, 第一个是逼格比拟高, 第二个是大多数的 GUI 软件都只实现了 git 所有性能的一个子集以升高操作难度; 命令行的模式下能力执行所有的 git 命令, 尽管大多数是开发中用不到的;
git 的装置也是比较简单的, git 下载官网 找到和操作系统绝对应的版本, 一路 next 就能够了;
装置完之后, 快捷菜单外面会呈现 Git GUI Here 和 Git Bash Here; 咱们能够关上 Git Bash, 在命令行界面外面输出:
$ git --version
git version 2.18.0.windows.1能呈现 git 的版本号, 就示意咱们的 git 曾经装置胜利; 咱们前面所有的操作都是基于 Git Bash 来进行的;
装置实现之后, 咱们能够应用 git 来获取 git 的降级:
$ git clone git://git.kernel.org/pub/scm/git/git.gitgit 自带一个 git config 的工具来帮忙设置 git 的外观和行为的配置变量;
当装置完 git 之后, 应做的第一件事就是设置用户名和邮件地址;
$ git config --global user.name "Your Name"
$ git config --global user.email "email@example.com"因为 git 是分布式管理系统, git的每一次提交都会记录上用户名和邮箱, 并且不可批改; 须要留神的是 --global 选项只有运行一次, 之后无论在改零碎上做任何事件, 都会应用 global 的配置; 当然也能够对某个仓库指定不同的用户名和Email地址.
git会应用操作系统默认的编辑器, 通常是 vim, 如果想应用其余的编辑器, 能够这样设置:
$ git config --global core.editor emacs如果想要查看配置项, 能够应用 git config --list 命令来列出所有 git 能找到的配置;
$ git config --list
core.symlinks=false
core.autocrlf=true
core.fscache=true
color.diff=auto
color.status=auto
...也能够应用 git config 来查看某一项的配置:
$ git config user.name版本库又名仓库, 英文名 repository, 能够了解为版本库就是一个目录, 这个目录外面的所有文件都能被 git 治理, 每一个文件的增, 删, 改都会被 git 跟踪, 以便任何时候都能够找到文件记录;
创立版本库有两种办法, 第一种是通过 git init 把以后文件夹变成一个 git 能够治理的仓库; 第二个是间接 clone 一个已有的仓库;
进入到一个空的目录下, 通过鼠标右键的菜单关上 bash 并输出:
$ git init执行完 init 之后, 文件夹外面会多一个 .git 的暗藏文件夹, 如果没看到这个文件夹, 能够设置文件夹属性; 这个目录是 git 用来记录文件版本用的, 个别都不会去批改;
这个时候, 咱们只是做了一个初始化的动作, 目录外面的文件还没有被追踪, 能够应用 git add 命令来实现对文件的追踪, 而后执行 commit 提交;
$ git add reademe.txt
$ git commit -m "首次提交的内容" git add 命令就是将文件增加到仓库, 能够一次增加多个文件只须要在参数前面增加文件名而后按 tab键; 也能够一次增加全副文件, 应用 git add * 或者是 git add --all命令;
如果想要取得已存在的 git 仓库的拷贝, 为某个开源我的项目奉献本人的一份力量, 这个时候就要用到 git clone 命令:
$ git clone https://gitlab.com/Scorpio-nan/myproject这将把近程的仓库克隆到本地, 并创立一个 myproject 的 git 仓库;
git 反对多种数据传输协定, 下面的例子就是用的 https:// 协定, 不过也能够应用 git:// 协定或者是 SSH 传输协定;
git 目录上面的文件都只有两种状态: 已跟踪或者未跟踪. 已跟踪的文件都是指那些曾经被纳入版本控制的文件, 在日志中都有它们的记录, 在工作一段时间后, 它们的状态可能处于未修改, 已批改或已放入暂存区.
要查看哪些文件处于什么状态, 能够用 git status 命令; 当初, 咱们在目录上面新建一个 README.txt文件, 如果之前并不存在这个文件, 应用 git status就会看到一个未追踪的文件;
$ git status
On branch master
No commits yet
Untracked files:
(use "git add ..." to include in what will be committed)
README.txt
nothing added to commit but untracked files present (use "git add" to track) 在下面的文件状态中, 咱们能够看到新建的 README文件呈现在 Untracked files 上面;示意该文件还没有被纳入 git 的版本控制;
应用 git add 命令开始追踪一个文件;
$ git add README.txt当初, 咱们再一次查看文件状态, 能够看到文件 README.txt 曾经被追踪, 并处于暂存状态;
$ git status
On branch master
No commits yet
Changes to be committed:
(use "git rm --cached ..." to unstage)
new file: README.txt 只有在 Changes to be committed 这行上面的, 就阐明是已暂存状态.
当初, 咱们来批改一个曾经被追踪的文件; 在 README.txt 外面增加一些内容, 并查看文件状态;
$ git status
On branch master
No commits yet
Changes to be committed:
(use "git rm --cached ..." to unstage)
new file: README.txt
Changes not staged for commit:
(use "git add ..." to update what will be committed)
(use "git checkout -- ..." to discard changes in working directory)
modified: README.txt Changes not staged for commit 阐明文件内容曾经产生了变动, 然而还没有增加到暂存区, 要更新到暂存区, 须要再一次执行 git add 命令;
git status命令的输入非常具体, 然而详细信息有些繁琐, 咱们还能够应用 git status -s 或者是 git status --short命令来查看状态;
$ git stauts -s
AM README.txt?? 示意新增加, 还没追踪的文件;A 示意新增加到暂存区中的文件;M 示意批改过的文件;有些时候, 咱们必须把文件放到 git 的目录中, 但又不能提交它们; 在这种状况下, 咱们能够创立一个 .gitignore 的文件, 列出须要疏忽的文件列表, 每次操作的时候 git 就会疏忽这些文件;
残缺的 .gitignore 配置详见 gitignore;
咱们在开发 vue 我的项目的时候, 如果是用的 git 来治理版本, 咱们能够在 .gitignore 外面增加如下内容;
dist
node_modules当咱们每次执行增加和提交操作的时候, git 就会主动疏忽我的项目的开发依赖;
git status 命令能够查看文件状态, 然而不能残缺的查看文件批改了哪些内容, 这个时候, 咱们就能够应用 git diff 命令来查看文件具体产生了哪些扭转;
$ git diff
diff --git a/README.txt b/README.txt
index 4632e06..5737925 100644
--- a/README.txt
+++ b/README.txt
@@ -1 +1 @@
-123456
\ No newline at end of file
+轻易写点什么;
\ No newline at end of file此命令比拟的是工作目录中以后文件和暂存区域快照之间的差别, 也就是批改之后还没有暂存起来的变动内容
每次提交更新之前, 最好都先应用一下 git status 查看一下文件状态, 肯定要确认还有什么批改的或新建的文件没有 git add 过, 否则提交的时候不会记录这些文件的变动;
$ git commit -m "首次提交 2019年9月6日11:25:11"
[master (root-commit) 424efbe] 首次提交 2019年9月6日11:25:11
2 files changed, 4 insertions(+)
create mode 100644 .gitignore
create mode 100644 README.txtgit commit 命令, -m 前面的输出是本次提交的日志, 相似于 svn 提交信息, 能够输出任何内容, 但最好是有意义的, 这样咱们就能从历史记录外面不便的查找到批改的记录;
要从 git 中移除某个文件, 就必须要从暂存区移除, 而后提交; 能够应用 git rm 命令实现操作;
如果只是简略的从目录外面手动删除文件, 运行 git status 时就会在 Changes not staged for commit 看到:
$ git status
On branch master
Changes not staged for commit:
(use "git add/rm ..." to update what will be committed)
(use "git checkout -- ..." to discard changes in working directory)
deleted: test.txt
no changes added to commit (use "git add" and/or "git commit -a") 而后运行 git rm 记录此次移除的操作
$ git rm test.txt
rm 'test.txt'
$ git status
On branch master
Changes to be committed:
(use "git reset HEAD ..." to unstage)
deleted: test.txt 下次提交的时候就不会纳入版本治理了;
rm 前面的参数能够是单个的文件, 也可是整个文件夹, 然而要留神的是如果是删除文件夹, 就须要在前面增加 -r 参数:
$ git rm dir -r在提交了屡次更新后, 咱们能够通过 git log 命令来查看以后我的项目的提交日志;
$ git log
commit d9fcc0f21f254c59f13d302f77f608d573c51e09 (HEAD -> master)
Author: Hope <2639319517@qq.com>
Date: Fri Sep 6 13:38:53 2019 +0800
45546
commit 379abcbace5c87823c3ab51ff54efcd20deaa487
Author: Hope <2639319517@qq.com>
Date: Fri Sep 6 11:30:30 2019 +0800
增加批改后的文件 2019年9月6日11:30:29
commit 424efbec89f2ebc759866b03053bcf074b33b453
Author: Hope <2639319517@qq.com>
Date: Fri Sep 6 11:25:12 2019 +0800
首次提交 2019年9月6日11:25:11默认不必任何参数的话, git log 会按提交工夫列出所有的更新, 最近的更新排在最下面;
git log 有许多选项能够抉择, 这里列举一些罕用的选项;
git log -p -2 -p 用来显示每次提交内容的差别;也能够加上 -2 来仅显示最近两次提交；git log --pretty=oneline --pretty 能够指定应用不同于默认格局的形式展现提交历史; oneline将每个提交放在一行显示; 另外还有 short, full 和 fuller 能够用;git log --stat --stat 查看每次提交的简略的统计信息；git log --shortstat --shortstat 只显示 &＃8211;stat 中最初的行数批改增加移除统计git log --name-only --name-only 仅在提交信息后显示已批改的文件清单git log --name-status --name-status 显示新增、批改、删除的文件清单git log --graph --graph 显示 ASCII 图形示意的分支合并历史在任何阶段, 咱们可能都须要撤销某些操作; 当初, 咱们在 README.txt 外面批改一些内容, 并用 git status 命令查看一下：
$ git status
On branch master
Changes not staged for commit:
(use "git add ..." to update what will be committed)
(use "git checkout -- ..." to discard changes in working directory)
modified: README.txt
no changes added to commit (use "git add" and/or "git commit -a") git 会通知咱们文件曾经被批改, 本次批改还未增加到暂存区; 并且提醒能够应用 git add 更新操作 和 git checkout -- 抛弃本次批改;
接下来, 对该文件应用撤销操作后, 再一次查看文件状态(也能够手动关上 README.txt 文件, 查看文件内容):
$ git checkout README.txt
$ git status
On branch master
nothing to commit, working tree clean刚刚批改过的文件就还原到了批改之前的状态;
git checkout 命令还能够增加 -- 参数, 示意把 README.txt 文件在工作区的批改全副撤销, 这里分两种状况:
README.txt 自批改后还没有被放到暂存区, 当初, 撤销批改就回到和版本库截然不同的状态;README.txt 经增加到暂存区后, 又作了批改, 当初, 撤销批改就回到增加到暂存区后的状态;总之, 就是让这个文件回到最近一次 git commit或 git add 时的状态;
如果被批改的文件曾经执行了 git add 增加操作, 但还未 commit 咱们还能够应用 git reset HEAD 把暂存区的文件批改撤销掉, 还原到工作区;
$ git reset HEAD README.txt
Unstaged changes after reset:
M README.txtgit reset 命令既能够回退版本, 也能够把暂存区的批改回退到工作区. 当咱们用HEAD时, 示意最新的版本;再用 git status 看一下, 就能够看到文件回到了 git add 之前的状态;
git checkout -- file 命令;git reset HEAD , 就回到了 1. 的操作步骤, 而后再执行 git checkout -- file 命令;下面的查看历史的章节外面, 咱们能够看到, 执行git log 命令的时候, 日志的签名都会有一长串数字和字母组合的字符串, 相似这样的 f4c0417dd64876552e17ff63dcb76c2baa33feee;
和 SVN 不一样的是, SVN每次提交的日志(也能够称之为版本号)都是累加的, 而 git 是 SHA1 计算出来的一个十分大的数字, 用十六进制示意;
在日常工作中, 如果咱们不小心将批改谬误的文件提交到了近程仓库上, 咱们也能够借助 git 的版本回退命令将版本退回到之前的某一个版本;
首先, git 必须晓得以后版本是哪个版本, 在 git 中, 用 HEAD示意以后版本, 上一个版本就是 HEAD^, 上上一个版本就是 HEAD^^&＃8230;再往上 N 多个版本, 写 ^ 比拟容易数不过去, 能够间接用 HEAD~n 来代替, 这里的 n 指的是具体数值;
当初, 咱们要把以后版本退回到上一个版本就能够间接应用:
$ git reset --hard HEAD
HEAD is now at b560ce1 批改.md外面的文件内容如果咱们的日志外面记录的版本十分的多, 而且, 上一次回退版本之前的新版本也找不到了, 这个时候如果 bash 还没有被敞开的话, 咱们还能侥幸的看到之前新版本的版本号; 咱们能够应用 reset 命令回退到之前的新版本;
$ git reset --hard f4c041
HEAD is now at f4c0417 提交批改--hard 前面接的是版本号, 不必写全, 只须要输出版本号的后面几位, git 就会主动去找到残缺的版本号;
然而, 下面的回退操作是在 bash 还没有被敞开的时候, 咱们还能通过操作记录查找到之前的操作, 然而, 当咱们应用 $ git reset --hard HEAD^ 回退版本的时候, 如果是敞开掉 bash 或者是敞开了电脑, 想要再复原到之前的版本, 就必须找到之前版本的版本号;
所幸, git 还为咱们提供了一个 git reflog 命令, 用来记录每一次的命令:
$ git reflog
f4c0417 (HEAD -> master, origin/master) HEAD@{0}: reset: moving to f4c041
f4c0417 (HEAD -> master, origin/master) HEAD@{1}: reset: moving to HEAD
f4c0417 (HEAD -> master, origin/master) HEAD@{2}: commit: 提交批改
b560ce1 HEAD@{3}: commit: 批改.md外面的文件内容
2872d97 HEAD@{4}: initial pull 这个时候, 咱们又能够应用 reset 命令来指定回退到哪一个版本了;
为了能在任意 Git 我的项目上合作, 咱们得须要晓得如何治理本人的近程仓库; Git 是分布式版本控制系统, 同一个Git仓库, 能够散布到不同的机器上; 前面咱们能够本人搭建一台运行 Git 的服务器;
不过现阶段, 为了学习应用 git, 咱们能够先应用 Github 收费的仓库托管服务来获取咱们的近程仓库, 这个章节也是 git 关联咱们的近程仓库的最佳实际;
Github 的应用也是比较简单, 咱们只须要在 Github 下面注册一个账号, 就能够收费应用了;
本章节是将后面根本的
git的指令联合起来的实际章节; 咱们会从 0 开始创立一个近程仓库;
首先, 在咱们的磁盘上找到一个空的目录, 而后执行以下命令:
$ mkdir GithubTest
$ cd GithubTest/
$ git init这个时候, 咱们就在本地曾经创立了一个 git仓库; 而后咱们关上 Github 并登入;
登入胜利之后, 能够看到右上角下面有一个 + 图标, 抉择 New repository, 会呈现上面的表单项:
[外链图片转存失败,源站可能有防盗链机制,倡议将图片保留下来间接上传(img-1ogCGLg9-1627108169032)(/img/createRepository.png)]
创立实现之后, 咱们能够看到一个空的仓库就创立好了, 并且还为咱们主动创立了 3 个文件, .gitignore , LICENSE , README.md;
如果不做任何操作的话, 这个仓库货默认将 README.md 文件作为主页; .md 文件是 markdown 的缩写;
(强烈推荐应用
marckdown语法来写笔记或者是博客);
[外链图片转存失败,源站可能有防盗链机制,倡议将图片保留下来间接上传(img-E8xPCXBR-1627108169035)(/img/repository.png)]
做完以上操作之后, 咱们能够将生成的 git 地址复制进去, 并切换到咱们本地的 bash 命令行中来, 在命令行中输出一下命令:
$ git remote add origin https://github.com/Scorpio-nan/GithubTest.git增加实现之后, 近程仓库的名称就是 origin , 这个是 git 的默认叫法, 也能够改成别的;
因为咱们在 Github 创立的仓库不是一个空的仓库, 咱们需先执行一下 git pull 命令, 将近程仓库的内容拉取到本地;
$ git pull origin master
remote: Enumerating objects: 5, done.
remote: Counting objects: 100% (5/5), done.
remote: Compressing objects: 100% (4/4), done.
remote: Total 5 (delta 0), reused 0 (delta 0), pack-reused 0
Unpacking objects: 100% (5/5), done.
From https://github.com/Scorpio-nan/GithubTest
* branch master -> FETCH_HEAD
* [new branch] master -> origin/masterorigin 是咱们的仓库名, master 代表的是主线(主分支); (前面 git 分支的章节会具体介绍)
执行实现之后, 咱们能够看到之前新建的空文件夹上面多了几个文件, 并且都有标记为追踪文件(windows 下面的 git 标记一版是一个绿色的 √ 号图标);
当初, 咱们把 README.md 外面的文件内容做一些批改;
README.md
#### 应用办法
````bash
$ git clone https://github.com/marmelab/react-admin.git
$ cd react-admin
$ npm install
$ npm start
````而后一次执行 git 的文件操作命令:
$ git status
...
$ git add README.md
$ git commit -m "批改.md外面的文件内容"
...
$ git push origin master
Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Delta compression using up to 8 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 439 bytes | 439.00 KiB/s, done.
Total 3 (delta 1), reused 0 (delta 0)
remote: Resolving deltas: 100% (1/1), completed with 1 local object.
To https://github.com/Scorpio-nan/GithubTest.git
2872d97..b560ce1 master -> master执行实现之后, 咱们就把本次对 README.md 作出的批改推送到了近程的 git 服务器上; 上面咱们切回到 Gitbub 页面验证一下咱们的提交是否胜利;
能够看到, github 下面的 GithubTest 这个仓库外面的内容曾经更新了;
克隆仓库的操作和创立的操作差不多, 不过, 不必在本地先创立好空的仓库, 只须要把 Github 下面创立好的仓库的地址复制下来, 而后在 bash 里输出命令 git clone 即可;
$ git clone https://github.com/Scorpio-nan/GithubTest.git
$ cd GithubTest
$ ls
LICENSE README.md如果有多人帮助开发, 那么每个人各自从近程克隆一份就能够了;
如果想查看曾经配置的近程仓库服务器, 能够运行 git remote 命令;
$ git remote
originorigin 就是 git 给克隆仓库的默认名称;
当然, 也能够指定 -v 项, 会显示须要读写近程仓库的应用的 git 保留的简写和对应的 URL;
$ git remote -v
origin https://github.com/Scorpio-nan/GithubTest.git (fetch)
origin https://github.com/Scorpio-nan/GithubTest.git (push)从近程仓库拉取数据, 能够执行 git fetch [remote-name]:
$ git fetch originfetch 命令会将数据拉取到本地的仓库, 但并不会主动合并或批改以后的工作; 这个时候咱们能够应用 git pull 命令来主动的抓取而后合并近程分支到以后分支;
$ git pull通常, 在多人合作的我的项目中, 如果操作不当, 执行git pull 的过程中就会发生冲突; 并且, 命令行外面会提醒错误信息;
error: Your local changes to the following files would be overwritten by merge;
这表明, 本地的文件与近程仓库上的文件不统一, 本地的文件将会被服务器上的文件笼罩, 这个时候咱们能够有两个抉择:
$ git stash
$ git pull origin master
$ git stash pop如此一来, 服务器上的代码更新到了本地, 而且本地刚批改的代码也没有被笼罩, 之后应用 add commit push 就能够更新本地代码到服务器了;
$ git reset --hard
$ git pull origin masterGit 并不会在你输出局部命令时主动推断出你想要的命令. 如果不想每次都输出残缺的 Git 命令, 能够通过 git config 文件来轻松地为每一个命令设置一个别名;
$ git config --global alias.co checkout
$ git config --global alias.br branch
$ git config --global alias.ci commit
$ git config --global alias.st status这意味着, 当要输出 git commit 时, 只须要输出 git ci
git 分支是为了将批改记录的流程离开存储, 让离开的分支不受其余分支的影响, 所以在同一个仓库里能够同时进行多个不同版本的批改;
试想一下, 在工作中如果咱们有新的需要, 会间接在代码外面去增加需要的业务代码, 然而如果这个时候已上线的我的项目外面须要紧急上线一个小版本, 解决程序外面的 bug;
这个时候就坑爹了, 因为本地的代码外面曾经加上了将来新版本的需要, 有可能这个需要是须要同后盾 api 一起上线能力失常应用, 如果想要应用新需要之前的代码, 只能将版本回退到增加需要之前, 这也就意味着前面的工作都是无用功; 当然, 也能够把现有的代码备份起来, 等还原之后再同步过来, 不过这样效率会非常低, 而且比拟容易出错;
分支能够帮忙咱们更好的治理不同版本的代码;
git 在执行 git init 的时候, 其实就是相当于为咱们主动创立了一个 master 分支; 应用 git branch 能够看到咱们以后所在的分支; git branch 会为咱们列出所有的分支, 以后分支后面会显示 *
$ git branch
* master假如 master 外面存储的是咱们在线上曾经正式经营的产品的代码, 上面咱们会在 master 上面新建一个 dev 开发环境的代码;
$ git checkout -b dev
Switched to a new branch 'dev'下面的 git checkout -b 命令, 相当于以下两条命令：
$ git branch dev
$ git checkout dev
Switched to branch 'dev'咱们在 master 上面创立了一个 dev分支, 并且还主动为咱们切换到了 dev 分支上, 让咱们再一次 git branch 查看一下;
$ git branch
* dev
master而后, 咱们能够在 dev 分支上失常的提交, 比方在 README.md 文件外面增加一些内容, 而后提交;
$ git add *
$ git commit -m "这是咱们在dev分支上做出的批改;"
[dev 4fee0ed] 这是咱们在dev分支上做出的批改;
1 file changed, 19 insertions(+)当初, 咱们在 dev 分支上的工作曾经做完了, 让咱们切换到 master 分支上;
$ git checkout master
Switched to branch 'master'
$ git branch
dev
* master切换到 master 分支之后, 在查看一下 README.txt 文件, 发现咱们刚刚增加下来的内容不见了, 因为刚刚的批改是在 dev 分支上进行的, 而 master 分支此刻的状态并没有扭转;
这个也就是
git分支的妙用, 对应到开发工作中就是dev是为咱们开发需要应用的, 而master是当火线上正在运行的版本;
当初, 咱们须要将 dev 分支下面做出的批改合并到 master 分支上;咱们能够应用 git merge 命令:
$ git merge dev
Updating f4c0417..4fee0ed
Fast-forward
README.md | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)git merge 命令用于将指定分支合并到以后分支上; 合并之后咱们再查看一下 README.md 的内容, 就能够看到曾经和 dev 分支下面的内容是截然不同的了;
留神到下面的 Fast-forward 信息, Git 通知咱们, 这次合并是快进模式, 也就是间接把 master 指向 dev 的以后提交, 所以合并速度十分快;
合并实现之后, 就能够删除 dev 分支了;
$ git branch -d dev
Deleted branch dev (was 4fee0ed).
$ git branch
* master合并分支, 往往不是像上述的疾速合并这么简略的; 例如: dev 分支上, 咱们对开发版本做了许多的批改; 然而这个时候 master 的版本外面也须要做一些批改; 当初 master 和 dev 分支上各自都有了新的提交;
这种状况下git 是无奈执行疾速合并的, 只能试图将各自批改的版本合并起来, 然而这种合并往往会有抵触;
$ git merge dev
Auto-merging README.md
CONFLICT (content): Merge conflict in README.md
Automatic merge failed; fix conflicts and then commit the result.git 通知咱们 README.md 文件存在抵触, 必须手动解决抵触之后再提交; 咱们能够在合并抵触后的任意时刻应用 git status 命令来查看那些因蕴含合并抵触而处于未合并 unmerged 状态的文件：
$ git status
On branch master
You have unmerged paths.
(fix conflicts and run "git commit")
(use "git merge --abort" to abort the merge)
Unmerged paths:
(use "git add ..." to mark resolution)
both modified: README.md
no changes added to commit (use "git add" and/or "git commit -a") 任何有抵触而有待解决的文件, 都会以未合并状态标识进去, git 会在有抵触的文件中退出抵触标记, 呈现抵触的文件会蕴含一些非凡的区段：
<<<<<<>>>>>> dev HEAD 所批示的版本(也就是 master 分支所在的地位), 在这个区段的上半局部(======= 以上的局部) , 而 dev 分支所批示的版本是在 ======= 的下半局部. 为了解决抵触, 咱们必须抉择由 ======= 宰割的两个局部中的一个; 或者咱们能够自行合并这些抵触, 删除掉某半的内容;
或者咱们能够应用 git merge --abort 来撤销本次合并; 在手动解决完这些抵触之后, 再对每个文件应用 git add命令来将其标记为抵触已解决;
$ git push -u origin master -f在理论开发中, 咱们应该依照几个根本的准则进行分支的治理:
master 分支是十分稳固的, 也就是仅用来公布版本, 不能在下面做开发;dev 分支是不稳固的, 用来做新版本的迭代, 开发实现之后再合并到 master 分支下来;dev 分支上开发, 每个人都有本人的分支, 常常往 master 分支上合并就行了;近程援用是对近程仓库的援用, 包含分支和标签等; 咱们能够通过 git ls-remote 来显示的查看近程援用的残缺列表; 或者是通过 git remote show 来取得近程分支的更多信息;
我司的自动化运维架构就是基于 git 分支去治理站点代码的; 合作流程大略为开发人员开发完新版本之后, 将不同的站点的业务代码提交到 git 绝对应的分支上, 而后服务端依据不同的站点标识去拉取分支上的代码, 并推送到服务器上;
随着公司的业务线增多, 产品也越来越多, 单个的 git 仓库曾经满足不了业务需要, 咱们要应用多个仓库去治理我的项目; 并且, 多个我的项目不停迭代的同时, 咱们还须要应用多个分支去做版本控制;
而随着业务量的增多, 一些我的项目变的十分的宏大, 如果咱们只是想获取到我的项目的代码以及之后的更新, 咱们就不须要去关注我的项目的历史提交记录, 那么咱们就只用克隆某一个分支的最初一次提交;
git clone --branch git clone --depth 1 git clone --branch --depth 1 -- depth 代表克隆的深度, --depth 1代表只克隆最新一次提交记录以及这次提交之后的最新内容, 不克隆历史提交, 所造成的影响就是不能查看历史提交记录, 然而克隆速度大大晋升;
$ git clone --branch=dev http://git.nbet-group.com dev --depth=1git clone 命令, url 前面如果增加名称的话, 那克隆下来的文件夹名称就是命令行增加的名称, 如果不加则以克隆下来的我的项目名命名文件夹;
Git 强制笼罩:
git fetch --all # 拉取所有更新，不同步
git reset --hard origin/master # 本地代码同步线上最新版本(会笼罩本地所有与近程仓库上同名的文件)
git pull # 更新一次（其实也能够不必，第二步命令做过了其实）git强制笼罩本地命令(单条执行):
git fetch --all && git reset --hard origin/master && git pull本地批改了许多文件, 其中有些是新增的, 因为开发须要这些都不要了, 想要抛弃掉, 或者是因为实现某个性能, 然而没有胜利, 反而把代码搞得一团蹩脚, 这个时候咱们能够勾销本地所有的更改, 回复到更改之前的状态, 能够应用如下命令:
git checkout . #本地所有批改的。没有的提交的，都返回到原来的状态
git stash #把所有没有提交的批改暂存到stash外面。可用git stash pop回复。
git reset --hard HASH #返回到某个节点，不保留批改。
git reset --soft HASH #返回到某个节点。保留批改
git clean -df #返回到某个节点
git clean 参数
# -n 显示 将要 删除的 文件 和 目录
# -f 删除 文件
# -df 删除 文件 和 目录单条执行:
git checkout . && git clean -xdf
京公网安备 11010802041100号 | 京ICP备19059560号-4 | PHP1.CN 第一PHP社区 版权所有 