Git

配置首先,请选定一个存放Git项目的目录,这样管理方便. 如: F:STUDYGIT_STUDY , 然后在资源管理器中打开.在空白处点击鼠标右键, 选择 –> TortoiseGit –> Settings, 然后就可以看到配置界面:选中General,在右边的 Language中选择中文. 不勾选自动升级的复选框,可能还需要指定 Git.exe 文件的路径,如 “D:DevlopProgramsGitbin”. 完成后,点击应用,确定关闭对话框.(当然,你也可以继续使用英文)再次点击鼠标右键,可以看到弹出菜单中已经变成中文. 原来的 Settings 变成 设置; Clone 变为 克隆.配置右键菜单. 在设置对话框中,点选左边的"右键菜单",然后在右边将所有的复选框都去掉,这样右键菜单显得比较干净:6.设置记住密码!!!!! 密码会明文保存在 C:UsersAdministrator.git-credentials 这种文件中, 请小心使用.进入设置, 点选左边的Git标签.可以发现,右边可以配置用户的名字与Email信息. 如下图所示:因为当前还没有本地项目,所以 “编辑本地 .git/config(L)” 按钮处于灰色不可用状态,如果在某个本地Git项目下打开配置对话框,那么这个按钮就可用,然后就可以编辑此项目的一些属性。点击 “编辑全局 .git/config(O)”按钮,会使用记事本打开全局配置文件,在全局配置文件中,在后面加上下面的内容:[credential]helper = store完成后保存,关闭记事本,确定即可。则当你推送项目到GitHub等在线仓库时,会记住你输入的用户名和密码(这里不是用户的姓名和Email哦.)如果你编辑的是 本地 .git/config(L)，其实这个翻译为本地有点问题,应该叫局部,也就是在某个项目下面设置,只对此项目有效.配置是一样的.用户名: 就是你注册的账号,如: tiemaocsdn密码: 当然是注册时填写的密码: *********Email: 是你的联系邮箱,给别人联系你时使用用户姓名/昵称: 可以随便取,但最好有点意义TortoiseGit之配置密钥TortoiseGit 使用扩展名为ppk的密钥，而不是ssh-keygen生成的rsa密钥。使用命令ssh-keygen -C “邮箱地址” -t rsa产生的密钥在TortoiseGit中不能用。而基于git的开发必须要用到rsa密钥，因此需要用到TortoiseGit的putty key generator工具来生成既适用于git的rsa密钥也适用于TortoiseGit的ppk密钥，具体配置步骤如下：1）运行TortoiseGit开始菜单中的puttygen程序，如下图示2）点击“Generate”按钮，鼠标在上图的空白地方来回移动直到进度条完毕（真的要在上面移动鼠标），就会自动生一个随机的key，如下图示如有需要，可以为密钥设置对应的访问密码，就是修改上图中“Key passphrase”和“Confirm passphrase”的值。3）将上图中多行文本框的内容全选、复制，并粘贴到git账户的 SSH public key中，这就是适用于git的公钥。4）点击上图中的“Save private key”按钮,将生成的key保存为适用于TortoiseGit的私钥（扩展名为.ppk）。5）运行TortoiseGit开始菜单中的Pageant程序，程序启动后将自动停靠在任务栏中，图标显示为，双击该图标，弹出key管理列表，如下图示6）点击上图中的“Add Key”按钮，将第4步保存的ppk私钥添加进来，关闭对话框即可

家目录linux：/hone/LiuweiLiwindows: c:\Users\LiuweiLi配置配置git一般只需要配置名字和邮箱就可以了，当我们向git仓库提交后，每一次的commit会显示配置的名字和邮箱，用来表示提交者的信息。配置的分类（1）主机的当前用户的所有仓库使用该配置git config –global user.name “LiuweiLi"git config –global user.email “typebyteforyou@gmail.com”（2）某一仓库使用该配置git config –local user.name “LiuweiLi"git config –local user.email “typebyteforyou@gmail.com"注释：单独配置当前仓库的话，需要进入仓库目录内敲命令生效。如果既使用了–global配置了当前用户的所有仓库，又使用了–local单独配置了某一仓库A，那么A的配置是使用–local的配置，这就像函数内的局部变量和全局变量同名，局部变量会屏蔽全局变量。查看当前的配置git config –global –listgit config –local –list同样，只要运行–local命令，必须进入仓库所在目录敲-local命令。如果某一个配置项被配置多次，比如user.email，下一次的配置并不会覆盖掉上一次的配置，而是追加到配置文件，但是以最后一次的配置为效配置的原理～/LiuweiLi/.gitconfig文件保存的是–global的配置，假设有一git仓库的目录是testgit，那么–local的配置保存在testgit/.git/config文件中。我们可以直接进入相应的目录直接编辑文件来配置。如果我们想添加或者删除配置项，可以直接进入配置文件编辑

一、安装 GitLab当前版本为 8.8.5准备安装环境curl -s https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.rpm.sh | sudo bash安装GitLab# –nogpgcheck 防止因没有签名导致无法安装的问题sudo yum install gitlab-ce-8.8.5-ce.1.el7.x86_64 –nogpgcheck配置GitLab# 执行结束浏览器中输入本机IP地址即可正常访问sudo gitlab-ctl reconfigure二、汉化 GitLab安装Gityum install -y git下载汉化包# 下载 8-8-zh 分支git clone https://gitlab.com/larryli/gitlab.git -b 8-8-zh# 进入目录cd gitlab停止GitLab服务gitlab-ctl stop参考链接GitLab下载汉化下载

关于Add与Commitgit add . 将所有修改提交到stage 缓存区git commit 将缓存区的更改提交到本地仓库那么，问题来了：如何取消commit，也就是撤销提交到本地仓库的操作？如何取消add，也就是撤销提交到缓存区的操作？如何取消更改，也就是说，修改了文件或者增加了文件或者删除了文件这时候怎么撤销？放弃文件修改（修改了文件，未执行 git add 命令）放弃单个文件的修改 git checkout xxx xxx是文件path放弃所有文件更改git checkout .放弃文件的增加（新建了文件、为add）放弃单个文件的新增rm xxx，其实就是cmd删除文件命令放弃所有新增的文件git clean xdf，删除所有新增的文件（不包括已经添加到缓存区的）。撤销提交到缓存区（执行了git add .命令，未commit）撤销单个文件git reset HEAD xxx，xxx是文件名撤销所有文件git reset HEAD .撤销提交到本地仓库（即取消git commit）说明，执行了git commit之后，相当于本地仓库已经更新了一个版本，就等待push了，那么要撤销commit也就是要回退版本，这种情形就是要将本地仓库回退1个版本。git reset –hard HEAD^ // –hard 是参数，^是上一版本，// 也可以用~1、~2，表示回退多少个版本–soft / –hard / –mixed 三个参数的说明：–soft：暂存区的内容和本地已提交的内容全部恢复到未暂存的状态，换言之，add和commit的内容全部都会变成未add的状态。–mixed：保留缓存区的内容，已提交的内容回到缓存区。–hard：缓存区的内容和已提交的内容都会被清空。（慎用！）关于创建分支git checkout -b xxx 创建并切换到xxx分支，其实，这是在当前分支的基础上创建xxx分支，并切换到xxx分支。也可以指定以其他分支为基础来创建：git checkout -b xxx master。涉及的问题：如果当前所在分支有未add到缓存区或者未commit的更改时是不能切换分支的，也就是说上述的创建并切换到分支是不会执行的。因此，当前所在分支要commit后才能切换分支。合并其他分支git merge xxx 将xxx分支合并到当前分支。关于删除分支删除本地分支git branch -D xxx 注意大写D删除远程的分支git push orgin -d xxx

你在本地已经一个项目，想使用Git进行版本管理，并推送到已新建的GitHub仓库。可参考以下步聚：# 1 进入项目目录cd /xx/xx/o2o# 2 初始化本地git仓库git init# 3 在你的项目中设置你在GitHub新建的公开仓库，并命名为 origingit remote add origin https://github.com/Guoye/o2o.git# 4 拉取Github仓库上master主分支上的文件git pull origin master##########代码提交并推送################## 5 把所有的代码加入缓存区 除.gitignore排除外git add *# 6 提交代码，并附上消息：“init"git commit -m “init”# 7 推送代码到远程仓库 origin 的master主分支上git push –set-upstream origin master# 完成

常见信息master: 默认开发分支origin：默认远程版本库Head: 默认开发分支Head^:Head 的父提交创建新仓库git initgit init [project-name] # 新建一个目录，并将其初始化为git仓库git clone [url] # 拷贝一个git仓库到本地配置Git 的配置文件是 .gitconfig，可以放在用户的主目录（全局配置）下或项目目录下（项目配置） 。# 显示当前的 git 配置git config –list # 编辑 Git 配置git config -e [–global] # 设置用来提交代码的用户信息git config [–global] user.name “[name]” git config [–global] user.email “[email address]“添加删除文件# 将指定文件添加到暂存区git add [file1] [file2] … # 将指定目录添加到暂存区，包括子目录git add [dir] # 将当前目录中的所有文件添加到暂存区git add . # 对同一个文件多次更改，建议分开提交git add -p # 将指定文件从工作区删除，并将本次删除添加到暂存区git rm [file1] [file2] … # 停止追踪指定的文件，不会删除文件git rm –cached [file] # 对指定文件进行重命名，并添加到暂存区中git mv [file-original] [file-renamed] 代码提交# 将暂存区中的文件提交到代码仓库git commit -m [message] # 将指定的文件从暂存区中提交到仓库git commit [file1] [file2] … -m [message] # 将工作区的更改直接提交到仓库git commit -a # 提交前展示所有的变动git commit -v # 使用新提交代替上次提交，如果代码没有任何变动，将会用于重写上次提交的提交信息git commit –amend -m [message] # 重做上次的提交，并将指定的文件包含其中git commit –amend [file1] [file2] … 分支相关# 列出本地分支git branch # 列出所有远程分支git branch -r # 列出本地和远程的所有分支git branch -a # 新建分支，并留在当前分支git branch [branch-name] # 新建分支，并切换到新建分支git checkout -b [branch-name] # 指向某次提交新建分支git branch [branch] [commit] # 创建一个新分支，并与指定的远程分支建立跟踪关系git branch –track [branch] [remote-branch] # 切换到指定分支，并更新工作区git checkout [branch-name] # 切换到上一个分支git checkout - # 将本地分支与指定的远程分支建立跟踪关心git branch –set-upstream [branch] [remote-branch]# 合并指定分支与当前分支git merge [branch] # 将指定的提交合并到本地分支git cheery-pick [commit] # 删除本地指定分支git branch -d [branch-name] # 删除远程分支git push origin –delete [branch-name]git push -dr [remote/branch]标签操作# 列出所有标签git tag# 在当前 tag 上创建一个新标签git tag [tag]# 在指定 tag 上创建一个新标签git tag [tag] [commit]# 删除本地标签git tag -d [tag]# 删除远程标签git push origin :refs/tags/[tagName]# 查看标签信息git show [tag]# 提交指定标签git push [remote] –tags# 创建一个新分支，指向特定的标签git checkout -b [branch] [tag]查看信息# 显示有变动的文件git status# 显示当前分支的提交历史git log# 显示提交历史和每次提交的文件git log –stat# 指定关键字搜索提交历史git log -S [keyword]# 显示自某次提交以来的所有更改，一次提交显示一行git log [tag] HEAD –pretty=format:$s# 显示自某次提交以来的所有更改，其提交描述必须符合搜索条件git log [tag] HEAD –grep feature# 显示指定文件的提交历史git log –flollow [file]git whatchanged [file]# 显示与指定文件相关的每个差异git log -p [file]# 显示最近 5 次提交git log -5 –pretty –oneline# 显示所有的提交用户，已提交数目多少排名git shortlog -sn# 显示指定文件何时被何人修改过git blame [file]# 显示暂存区和工作区文件差别git diff# 显示暂存区和上一次提交的差别git diff –cached [file]# 显示工作区和当前分支的最近一次提交的差别git diff HEAD# 显示指定两次提交的差别git diff [first-branch]…[second-branch]# 显示今天提交了多少代码git diff –shortstat “@{0 day ago}”# 显示特定提交的提交信息和更改的内容git show [commit]# 某次提交改动了哪些文件git show –name-only [commit]# 显示某个提交的特定文件的内容git show [commit]:[filename]# 显示当前分支的最新提交git reflog远程同步# 从远程分支下载所有变动git fetch [remote]# 显示所有远程仓库git remote -v# 显示某个远程参考信息git remote show [remote]# 新建一个远程仓库，并命名git remote add [shortname] [url]# 检索远程村粗库的更改，并与本地分支合并git pull [remote] [branch]# 将本地分支提交到远程仓库git push [remote] [branch]# 将当前分支强制提交到远程仓库，即使有冲突存在git push [remote] –force# 将所有分支提交到远程仓库git push [remote] –all#### 撤销操作# 将暂存区中的指定文件还原到工作区，保留文件变动git checkout [file]# 将指定文件从某个提交还原到暂存区和工作区git checkout [commit] [file]# 将暂存区中的所有文件还原到工作区git checkout .# 重置暂存区中的指定文件，与先前的提交保持一致，但保持工作空间的变动不变git reset [file]# 重置暂存区和工作区中的指定文件，并与最近一次提交保持一致，工作空间文件变动不会保留git reset –hard# 重置暂存区，指向指定的某次提交，工作区的内容不会被覆盖git reset [commit]# 重置暂存区和工作区中的指定文件，并与指定的某次提交保持一致，工作区的内容会被覆盖git reset –hard [commit]# 将 HEAD 重置为指定的某次提交，保持暂存区和工作区的内容不变git reset –keep [commit]# 新建新提交以撤销指定的提交git revert [commit]# 暂存为提交的变动，并在稍后移动它们git stashgit stash popgit stash apply其他# 生成用于发布的存档git archive欢迎关注 公众号【前端开发小白】 ...

本文讲的是把Git在最新2.9.2，合并pull两个不同的项目，出现的问题如何去解决fatal: refusing to merge unrelated histories我在Github新建一个仓库，写了License，然后把本地一个写了很久仓库上传。先pull，因为两个仓库不同，发现refusing to merge unrelated histories，无法pull因为他们是两个不同的项目，要把两个不同的项目合并，git需要添加一句代码，在git pull，这句代码是在git 2.9.2版本发生的，最新的版本需要添加–allow-unrelated-histories假如我们的源是origin，分支是master，那么我们 需要这样写git pull origin master –allow-unrelated-histories

每个程序员必不可少的就是博客网站了，一开始我们并不知道可以搭建属于自己的个人博客网站，通常会在CSDN、博客园等别人搭建的博客网站写博客，当你写久了以后会感觉很 low, 一些文章需要审核通过才能发布。索性我们还不如自己搭建一个个人博客，个人博客的设计美化和内容都按照自己喜欢的要求来，然后在阿里云买一个高大上的域名，岂不是很装逼？尽管你没有学过网页 web 开发，但是通过这篇小鹿详细教程可以亲自搭建起属于自己的个人博客。小鹿的博客网址：小鹿的博客建站前的准备建站之前我们先要做好准备工作，将相关的工具准备好。安装 Node.jsNode.js 是一个基于 Chrome V8 引擎的 JavaScript 运行环境。Node.js 使用了一个事件驱动、非阻塞式 I/O 的模型，使其轻量又高效。安装网址：https://nodejs.org/zh-cn/验证是否安装成功：打开 cmd 命令行(win+r 输入 cmd 回车)执行 ：node -vnpm -v安装成功之后显示版本号：安装 Git通常使用 github 的对 git 并不陌生，Git(读音为/gt/。)是一个开源的分布式版本控制系统，可以有效、高速的处理从很小到非常大的项目版本管理。 [1] Git 是 Linus Torvalds 为了帮助管理 Linux 内核开发而开发的一个开放源码的版本控制软件。安装网址：https://www.git-scm.com/download/win验证是否安装成功：打开cmd命令行(win+r 输入cmd回车)执行 ：git –version安装成功之后显示版本号：安装 HexoHexo 是一个快速、简洁且高效的博客框架。了解更多关于 Hexo 请查看官方网站：Hexo安装 hexo 框架下面一起来看看怎么安装 Hexo 框架？首先选择一个文件夹，这个文件夹主要存放关于你博客的配置文件以及以后要写的的文章，在该文件夹的根目录运行之前下好的 git-bash.exe 。输入命令开始安装：$ npm install -g hexo-cli这里安装的是 Hexo 最新版本，如果想安装以前的的版本请运行命令 $ npm install -g hexo 以上步骤不出问题的话就已经在本地机器上搭建起了 Hexo 环境。下面介绍 Hexo 的具体使用方法。初始化Hexo创建hexo工程$ hexo init blog创建一个文件夹blog（blog 为文件夹的名字，可改成自己想要的名字），使用 Hexo 命令初始化 blog 为 hexo 工程目录。新建POST $ cd blog$ hexo new “HelloWorld”进入初始化后的 blog 文件夹，创建名为HelloWorld的文件，此时会在 /blog/sources/_post/ 目录下生成 HelloWorld.md 文件。生成静态文件$ hexo generate使用 Hexo 引擎将 Markdown 格式的文件解析成可以使用浏览器查看的 HTML 文件，HTML 文件存储在 blog/public 目录下。运行hexo服务器$ hexo server打开命令行提示的地址，一般是 http://localhost:4000/，既可以看到我们的 Hexo 网站。此时 Helloworld 文章中没有任何内容。打开 /blog/sources/_post/ 目录，使用编辑器打开其中的 HelloWorld.md并在其中添加 markdown 格式的内容保存，然后重新运行以下命令：$ hexo generate$ hexo server命令的含义：hexo generate 生成静态文件， hexo server 启动服务器。默认情况下，访问网址为： http://localhost:4000/。 如果重新改变端口号请详细查看官网文档，这里不多介绍。注意：如果在 HelloWorld.md文件中有中文，在网页进行浏览可能出现乱码，解决方式通过编辑器打开 HelloWorld.md 文件把编码方式改成 utf-8 就可以了。安装主题Hexo 提供了默认主题 landscape，主题的位置在 blog ->themes 文件夹下。主题根据自己喜好可以在网上找到，通过 Git 进行相应的下载。下面小鹿贴出几个主题可以进行相应的下载，喜欢哪一个可以进行配置到自己的个人博客了。主题一：hexo-theme-next（小鹿用的主题是这一个，后期是自己改进美化的）主题二：Casper主题三：daleanthony主题四：hexo-theme-yilia主题五：jacman主题六：hexo-theme-apollo小鹿给大家找了一个主题链接可以选择自己喜欢的主题：更多主题配置主题打开 git-bash 切换到 blog -> themes 目录下，如果在目录 blog ->themes 右键选择启动 git-bash 就不用切换了。如果在桌面直接启动 git-bash ,可通过下边命令切换到 blog ->themes 目录下。$ cd /blog/themes选好一个主题，复制主题的 github 地址，通过 git 命令进行下载。（例：https://github.com/iissnan/hexo-theme-next 为一个主题的 github 地址）git clone https://github.com/iissnan/hexo-theme-next下载完之后我将文件夹改成 next了（也可以不改，我为了名字简洁点）。然后在修改 /blog/config.yml 文件，将其中的 theme 改成 next。（这个是改变主题的地方，如果你用的是其他的主题，将这个 next 改成你下载下来的主题的文件夹的名称）重新运行以下命令，查看更换主题后的效果 ：$ hexo generate$ hexo server申请 Github 免费静态内容空间注册 Github 账号我们去 Github 的官网进行账号注册 ，注册完成之后我们根据官方文档进行配置 ，然后我们使用自己的账户创建一个 Repository （仓库）。点击网站右上角的 + 号，选择 New Repository( 注意：创建仓库的名字要你的注册的用户名一致。其他默认，确定创建)。之后你的静态内容空间就已经创建好了，在浏览器输入你的 your username（用户名）.github.io 就可以访问了。将 Hexo 上传 Github 上。步骤一：安装 deployer-git （安装部署工具，方便以后更新）$ npm install hexo-deployer-git –save步骤二：在 /blog/_config.yml 中修改 deploy 属性(注意“：”之后有空格 ) 否则配置失败。deploy: type: git repository: https://github.com/luxiangqiang/luxiangqiang.github.io.git branch: master将上方的 Repository 换成你申请的 Git 仓库地址 使用 https 的方式部署每次提交到 Github 都要输入用户名和密码，如果嫌麻烦请使用 SSH 的方式，百度/谷歌自行搜索。步骤三：初始化本地仓库。git init步骤四：连接远程仓库 ( 如果是第一次使用 git，在使用 git 的时候会提示输入用户名和密码，用户名是自己的注册邮箱。)git remote add origin https://github.com/luxiangqiang/luxiangqiang.github.io.git步骤五：发布 hexo 到 github page//等于一次性执行了，清空、刷新、部署三个命令hexo clean && hexo g && hexo d步骤六：推送到远程仓库（github）git push origin这里建议创建一个新的分支 hexo，用于管理 hexo 文件。提交的的时候只提交 hexo 网站 html、css 等源文件。 创建并切换到新建分支：git checkout -b hexo将分支推送到远程仓库：git push origin hexo记得提交以后去 github 上把 hexo 分支设置默认，以后写文章等都要部署。 文章在 hexo 目录下的 source _posts 文件夹中，是 md 格式，也就是 Markdown 格式。 ...

软件介绍： iUpload主要功能将图片上传至七牛云，返回 Markdown 格式的链接到剪粘板功能介绍：图片本地压缩图片右键上传图片复制上传图片拖拽上传https加密上传开发： 继承七牛云SDK，使用swift开发，App自签上传凭证，自动选择存储区域，通过https加密上传。下载： https://github.com/iChochy/iUpload/releases/download/1.0.1/App.dmg联系方系：邮箱：iChochy@qq.com网站：http://www.chochy.cnGitHub： https://github.com/iChochy/iUpload注： 处女作

开公众号差不多两年了，有不少原创教程，当原创越来越多时，大家搜索起来就很不方便，因此做了一个索引帮助大家快速找到需要的文章！Spring Boot系列SpringBoot+SpringSecurity处理Ajax登录请求SpringBoot+Vue前后端分离(一)：使用SpringSecurity完美处理权限问题1SpringBoot+Vue前后端分离(二)：使用SpringSecurity完美处理权限问题2SpringBoot+Vue前后端分离(三)：SpringSecurity中密码加盐与SpringBoot中异常统一处理SpringBoot+Vue前后端分离(四)：axios请求封装和异常统一处理SpringBoot+Vue前后端分离(五)：权限管理模块中动态加载Vue组件SpringBoot+Vue前后端分离(六)：使用SpringSecurity完美处理权限问题SpringBoot中自定义参数绑定SpringBoot中使用POI，快速实现Excel导入导出SpringBoot中发送QQ邮件SpringBoot中使用Freemarker构建邮件模板SpringBoot+WebSocket实现在线聊天(一)SpringBoot+WebSocket实现在线聊天(二)SpringSecurity登录使用JSON格式数据SpringSecurity登录添加验证码SpringSecurity中的角色继承问题Spring Boot中通过CORS解决跨域问题Spring Boot数据持久化之JdbcTemplateSpring Boot多数据源配置之JdbcTemplate最简单的SpringBoot整合MyBatis教程极简Spring Boot整合MyBatis多数据源Spring Boot中的yaml配置简介SpringBoot整合Swagger2，再也不用维护接口文档了Spring Boot中，Redis缓存还能这么用！干货|一文读懂 Spring Data Jpa！Spring基础配置Spring常用配置Spring常用配置(二)SpringMVC基础配置SpringMVC常用配置JavaWeb之最简洁的配置实现文件上传初识Spring Boot框架DIY一个Spring Boot的自动配置使用Spring Boot开发Web项目为我们的Web添加HTTPS支持在Spring Boot框架下使用WebSocket实现消息推送一个JavaWeb搭建的开源Blog系统，整合SSM框架Spring Cloud系列1.使用Spring Cloud搭建服务注册中心2.使用Spring Cloud搭建高可用服务注册中心3.Spring Cloud中服务的发现与消费4.Eureka中的核心概念5.什么是客户端负载均衡6.Spring RestTemplate中几种常见的请求方式7.RestTemplate的逆袭之路，从发送请求到负载均衡8.Spring Cloud中负载均衡器概览9.Spring Cloud中的负载均衡策略10.Spring Cloud中的断路器Hystrix11.Spring Cloud自定义Hystrix请求命令12.Spring Cloud中Hystrix的服务降级与异常处理13.Spring Cloud中Hystrix的请求缓存14.Spring Cloud中Hystrix的请求合并15.Spring Cloud中Hystrix仪表盘与Turbine集群监控16.Spring Cloud中声明式服务调用Feign17.Spring Cloud中Feign的继承特性18.Spring Cloud中Feign配置详解19.Spring Cloud中的API网关服务Zuul20.Spring Cloud Zuul中路由配置细节21.Spring Cloud Zuul中异常处理细节22.分布式配置中心Spring Cloud Config初窥23.Spring Cloud Config服务端配置细节(一)24.Spring Cloud Config服务端配置细节(二)之加密解密25.Spring Cloud Config客户端配置细节26.Spring Cloud Bus之RabbitMQ初窥27.Spring Cloud Bus整合RabbitMQ28.Spring Cloud Bus整合Kafka29.Spring Cloud Stream初窥30.Spring Cloud Stream使用细节31.Spring Cloud系列勘误Docker系列Docker教程合集MongoDB系列1.Linux上安装MongoDB2.MongoDB基本操作3.MongoDB数据类型4.MongoDB文档更新操作5.MongoDB文档查询操作(一)6.MongoDB文档查询操作(二)7.MongoDB文档查询操作(三)8.MongoDB查看执行计划9.初识MongoDB中的索引10.MongoDB中各种类型的索引11.MongoDB固定集合12.MongoDB管道操作符(一)13.MongoDB管道操作符(二)14.MongoDB中MapReduce使用15.MongoDB副本集搭建16.MongoDB副本集配置17.MongoDB副本集其他细节18.初识MongoDB分片19.Java操作MongoDBRedis系列教程1.Linux上安装Redis2.Redis中的五种数据类型简介3.Redis字符串(STRING)介绍4.Redis字符串(STRING)中BIT相关命令5.Redis列表与集合6.Redis散列与有序集合7.Redis中的发布订阅和事务8.Redis快照持久化9.Redis之AOF持久化10.Redis主从复制(一)11.Redis主从复制(二)12.Redis集群搭建13.Jedis使用14.Spring Data Redis使用Git系列1.Git概述2.Git基本操作3.Git中的各种后悔药4.Git分支管理5.Git关联远程仓库6.Git工作区储藏兼谈分支管理中的一个小问题7.Git标签管理Elasticsearch系列引言elasticsearch安装与配置初识elasticsearch中的REST接口elasticsearch修改数据elasticsearch文档操作elasticsearch API约定(一)elasticsearch API约定(二)elasticsearch文档读写模型elasticsearch文档索引API(一)elasticsearch文档索引API(二)elasticsearch文档Get APIelasticsearch文档Delete APIelasticsearch文档Delete By Query API(一)elasticsearch文档Delete By Query API(二)elasticsearch文档Update API我的Github开源项目开源项目(一)： SpringBoot+Vue前后端分离开源项目-微人事开源项目(二)： SpringBoot+Vue前后端分离开源项目-V部落开源项目(三)： 一个开源的五子棋大战送给各位小伙伴!开源项目(四)：一个开源的会议管理系统献给给位小伙伴！开源项目(五)：一个JavaWeb搭建的开源Blog系统，整合SSM框架杂谈从高考到程序员之毕业流水帐从高考到现在起早贪黑几个月，我写完了人生第一本书！当公司倒闭时，你在干什么？华为云 open day，带你看看别人家的公司其他小程序开发框架WePY和mpvue使用感受两步解决maven依赖导入失败问题干货|6个牛逼的基于Vue.js的后台控制面板，接私活必备Ajax上传图片以及上传之前先预览一个简单的案例带你入门Dubbo分布式框架WebSocket刨根问底(一)WebSocket刨根问底(二)WebSocket刨根问底(三)之群聊Nginx+Tomcat搭建集群，Spring Session+Redis实现Session共享IntelliJ IDEA中创建Web聚合项目(Maven多模块项目)Linux上安装Zookeeper以及一些注意事项初识ShiroShiro中的授权问题Shiro中的授权问题(二)更多资料，请关注公众号牧码小子，回复 Java， 获取松哥为你精心准备的Java干货！ ...

因项目需要，出了这个教程，主要是让大家对于将图片/gif等提交的GitHub上，产生一个外网链接的方式。本文为HMStrange项目组的第二个入门任务。接下来按照教程步骤开始吧。一、在Github上选择新建一个项目二、填写项目的信息，这个项目就是HMStrange的图片仓库，接下来的架构图等都会放到这个项目中。所以我将它取名为：img_HMStrange 。大家可以按照自己的风格来取名三、建立项目后，将项目clone到自己本地。四、在自己适合的文件夹下，将项目clone下来，这里有点重复，不过希望大家能看清晰一点。五、准备一张自己的ID（组员昵称）手写签名，然后再项目中新建一个文件夹，将图片存放在这个文件夹中。六、在项目根路径下，打开git bash七、提交项目到GitHub上，这里有两个代码git add .git commit -am 添加个人签名git push八、重新到自己的GitHub项目，刷新一下，看到自己提交的信息，然后找到图片位置 九、点击Download，获取图片在GitHub上的外联地址最后，在需要用到的地方，比如说md的格式，我们可以写上去如下，HMStrange组成员，请将手写签名填写提交到项目上。项目提交的教程按照 Noseparte说: 开源项目HMStrange贡献记，进行提交。最后效果图：请到项目 doc/members/specification.md 填写手写签名图片

一般情况我们在gitlab的web页面上review代码，但是仅凭肉眼review，劳力伤神，很难看出一些小错误。如果我们把代码拉到IDE中，一些小错误编辑器直接提示，编译错误build一下就知道，各种调用跳转随心所欲，再也不怕没把好pr的关了。如果我们有提交者仓库的权限，直接把他的分支拉到本地就可以达成目的了。但是，由于项目众多开发人员众多，每个仓库都去加权限操作起来非常麻烦。有没有不需要代码提交者的仓库权限就能拉到本地review的方案呢？google了一通找到了相关资料，原文是使用gerrit(google的code review工具)，本人使用gitlab也可以奏效，应该也实用于github。废话不多说了，下面来看操作步骤。我们要review的pr连接是这个：https://git.xxx.com/project/merge_requests/1000拿到pr的连接中的id，使用git git ls-remote：git ls-remote remote-name | grep 1000输出：……5d30d7841389901ce810e327ea71ee2b3a2d5ab1 refs/merge-requests/1000/head……拿到refs或者commitid，在本地仓库中执行就可以将pr中还没合并的代码拉到本地做code review了。git pull remote refs/merge-requests/1000/headorgit reset –hard 5d30d7841389901ce810e327ea71ee2b3a2d5ab1参考文章：https://blog.csdn.net/yucendu…

Git使用说明本文整理自： http://www.runoob.com/git/git...1.关于Git官方文档：https://git-scm.com/docsGit 是一个开源的分布式版本控制系统，用于敏捷高效地处理任何或小或大的项目。Git 是 Linus Torvalds 为了帮助管理 Linux 内核开发而开发的一个开放源码的版本控制软件。Git 与常用的版本控制工具 CVS, Subversion 等不同，它采用了分布式版本库的方式，不必服务器端软件支持Git 与 SVN 区别Git 不仅仅是个版本控制系统，它也是个内容管理系统(CMS)，工作管理系统等。如果你是一个具有使用 SVN 背景的人，你需要做一定的思想转换，来适应 Git 提供的一些概念和特征。Git 与 SVN 区别点：1、Git 是分布式的，SVN 不是：这是 Git 和其它非分布式的版本控制系统，例如 SVN，CVS 等，最核心的区别。2、Git 把内容按元数据方式存储，而 SVN 是按文件：所有的资源控制系统都是把文件的元信息隐藏在一个类似 .svn、.cvs 等的文件夹里。3、Git 分支和 SVN 的分支不同：分支在 SVN 中一点都不特别，其实它就是版本库中的另外一个目录。4、Git 没有一个全局的版本号，而 SVN 有：目前为止这是跟 SVN 相比 Git 缺少的最大的一个特征。5、Git 的内容完整性要优于 SVN：Git 的内容存储使用的是 SHA-1 哈希算法。这能确保代码内容的完整性，确保在遇到磁盘故障和网络问题时降低对版本库的破坏。PDF 版命令手册：github-git-cheat-sheet.pdf2.Git 安装配置安装在使用Git前我们需要先安装 Git。Git 目前支持 Linux/Unix、Solaris、Mac和 Windows 平台上运行。Git 各平台安装包下载地址为：http://git-scm.com/downloadsLinux 平台上安装Git 的工作需要调用 curl，zlib，openssl，expat，libiconv 等库的代码，所以需要先安装这些依赖工具。在有 yum 的系统上（比如 Fedora）或者有 apt-get 的系统上（比如 Debian 体系），可以用下面的命令安装：各 Linux 系统可以使用其安装包管理工具（apt-get、yum 等）进行安装：Debian/UbuntuDebian/Ubuntu Git 安装命令为：$ apt-get install libcurl4-gnutls-dev libexpat1-dev gettext \ libz-dev libssl-dev$ apt-get install git$ git –versiongit version 1.8.1.2Centos/RedHat如果你使用的系统是 Centos/RedHat 安装命令为：$ yum install curl-devel expat-devel gettext-devel \ openssl-devel zlib-devel$ yum -y install git-core$ git –versiongit version 1.7.1源码安装我们也可以在官网下载源码包来安装，最新源码包下载地址：https://git-scm.com/download安装指定系统的依赖包：########## Centos/RedHat ##########$ yum install curl-devel expat-devel gettext-devel \ openssl-devel zlib-devel########## Debian/Ubuntu ##########$ apt-get install libcurl4-gnutls-dev libexpat1-dev gettext \ libz-dev libssl-dev解压安装下载的源码包：$ tar -zxf git-1.7.2.2.tar.gz$ cd git-1.7.2.2$ make prefix=/usr/local all$ sudo make prefix=/usr/local installWindows 平台上安装在 Windows 平台上安装 Git 同样轻松，有个叫做 msysGit 的项目提供了安装包，可以到 GitHub 的页面上下载 exe 安装文件并运行：安装包下载地址：https://gitforwindows.org/完成安装之后，就可以使用命令行的 git 工具（已经自带了 ssh 客户端）了，另外还有一个图形界面的 Git 项目管理工具。在开始菜单里找到"Git"->“Git Bash”，会弹出 Git 命令窗口，你可以在该窗口进行 Git 操作。Mac 平台上安装在 Mac 平台上安装 Git 最容易的当属使用图形化的 Git 安装工具，下载地址为：http://sourceforge.net/projec…Git 配置Git 提供了一个叫做 git config 的工具，专门用来配置或读取相应的工作环境变量。这些环境变量，决定了 Git 在各个环节的具体工作方式和行为。这些变量可以存放在以下三个不同的地方：/etc/gitconfig 文件：系统中对所有用户都普遍适用的配置。若使用 git config 时用 –system 选项，读写的就是这个文件。~/.gitconfig 文件：用户目录下的配置文件只适用于该用户。若使用 git config 时用 –global 选项，读写的就是这个文件。当前项目的 Git 目录中的配置文件（也就是工作目录中的 .git/config 文件）：这里的配置仅仅针对当前项目有效。每一个级别的配置都会覆盖上层的相同配置，所以 .git/config 里的配置会覆盖 /etc/gitconfig 中的同名变量。在 Windows 系统上，Git 会找寻用户主目录下的 .gitconfig 文件。主目录即 $HOME 变量指定的目录，一般都是 C:\Documents and Settings$USER。此外，Git 还会尝试找寻 /etc/gitconfig 文件，只不过看当初 Git 装在什么目录，就以此作为根目录来定位。用户信息配置个人的用户名称和电子邮件地址：$ git config –global user.name “runoob”$ git config –global user.email test@runoob.com如果用了 –global 选项，那么更改的配置文件就是位于你用户主目录下的那个，以后你所有的项目都会默认使用这里配置的用户信息。如果要在某个特定的项目中使用其他名字或者电邮，只要去掉 –global 选项重新配置即可，新的设定保存在当前项目的 .git/config 文件里。文本编辑器设置Git默认使用的文本编辑器, 一般可能会是 Vi 或者 Vim。如果你有其他偏好，比如 Emacs 的话，可以重新设置：:$ git config –global core.editor emacs差异分析工具还有一个比较常用的是，在解决合并冲突时使用哪种差异分析工具。比如要改用 vimdiff 的话：$ git config –global merge.tool vimdiffGit 可以理解 kdiff3，tkdiff，meld，xxdiff，emerge，vimdiff，gvimdiff，ecmerge，和 opendiff 等合并工具的输出信息。当然，你也可以指定使用自己开发的工具，具体怎么做可以参阅第七章。查看配置信息要检查已有的配置信息，可以使用 git config –list 命令：$ git config –listhttp.postbuffer=2Muser.name=runoobuser.email=test@runoob.com有时候会看到重复的变量名，那就说明它们来自不同的配置文件（比如 /etc/gitconfig 和 ~/.gitconfig），不过最终 Git 实际采用的是最后一个。这些配置我们也可以在 ~/.gitconfig 或 /etc/gitconfig 看到，如下所示：vim /.gitconfig 显示内容如下所示：[http] postBuffer = 2M[user] name = runoob email = test@runoob.com也可以直接查阅某个环境变量的设定，只要把特定的名字跟在后面即可，像这样：$ git config user.namerunoob3.Git 工作流程本章节我们将为大家介绍 Git 的工作流程。一般工作流程如下：克隆 Git 资源作为工作目录。在克隆的资源上添加或修改文件。如果其他人修改了，你可以更新资源。在提交前查看修改。提交修改。在修改完成后，如果发现错误，可以撤回提交并再次修改并提交。下图展示了 Git 的工作流程：4.Git 工作区、暂存区和版本库基本概念我们先来理解下Git 工作区、暂存区和版本库概念工作区：就是你在电脑里能看到的目录。暂存区：英文叫stage, 或index。一般存放在 “.git目录下” 下的index文件（.git/index）中，所以我们把暂存区有时也叫作索引（index）。版本库：工作区有一个隐藏目录.git，这个不算工作区，而是Git的版本库。下面这个图展示了工作区、版本库中的暂存区和版本库之间的关系：图中左侧为工作区，右侧为版本库。在版本库中标记为 “index” 的区域是暂存区（stage, index），标记为 “master” 的是 master 分支所代表的目录树。图中我们可以看出此时 “HEAD” 实际是指向 master 分支的一个"游标"。所以图示的命令中出现 HEAD 的地方可以用 master 来替换。图中的 objects 标识的区域为 Git 的对象库，实际位于 “.git/objects” 目录下，里面包含了创建的各种对象及内容。当对工作区修改（或新增）的文件执行 “git add” 命令时，暂存区的目录树被更新，同时工作区修改（或新增）的文件内容被写入到对象库中的一个新的对象中，而该对象的ID被记录在暂存区的文件索引中。当执行提交操作（git commit）时，暂存区的目录树写到版本库（对象库）中，master 分支会做相应的更新。即 master 指向的目录树就是提交时暂存区的目录树。当执行 “git reset HEAD” 命令时，暂存区的目录树会被重写，被 master 分支指向的目录树所替换，但是工作区不受影响。当执行 “git rm –cached <file>” 命令时，会直接从暂存区删除文件，工作区则不做出改变。当执行 “git checkout .” 或者 “git checkout – <file>” 命令时，会用暂存区全部或指定的文件替换工作区的文件。这个操作很危险，会清除工作区中未添加到暂存区的改动。当执行 “git checkout HEAD .” 或者 “git checkout HEAD <file>” 命令时，会用 HEAD 指向的 master 分支中的全部或者部分文件替换暂存区和以及工作区中的文件。这个命令也是极具危险性的，因为不但会清除工作区中未提交的改动，也会清除暂存区中未提交的改动。5.Git 创建仓库本章节我们将为大家介绍如何创建一个 Git 仓库。你可以使用一个已经存在的目录作为Git仓库。git initGit 使用 git init 命令来初始化一个 Git 仓库，Git 的很多命令都需要在 Git 的仓库中运行，所以 git init 是使用 Git 的第一个命令。在执行完成 git init 命令后，Git 仓库会生成一个 .git 目录，该目录包含了资源的所有元数据，其他的项目目录保持不变（不像 SVN 会在每个子目录生成 .svn 目录，Git 只在仓库的根目录生成 .git 目录）。使用方法使用当前目录作为Git仓库，我们只需使它初始化。git init该命令执行完后会在当前目录生成一个 .git 目录。使用我们指定目录作为Git仓库。git init newrepo初始化后，会在 newrepo 目录下会出现一个名为 .git 的目录，所有 Git 需要的数据和资源都存放在这个目录中。如果当前目录下有几个文件想要纳入版本控制，需要先用 git add 命令告诉 Git 开始对这些文件进行跟踪，然后提交：$ git add .c$ git add README$ git commit -m ‘初始化项目版本’以上命令将目录下以 .c 结尾及 README 文件提交到仓库中。git clone我们使用 git clone 从现有 Git 仓库中拷贝项目（类似 svn checkout）。克隆仓库的命令格式为：git clone <repo>如果我们需要克隆到指定的目录，可以使用以下命令格式：git clone <repo> <directory>参数说明：repo:Git 仓库。directory:本地目录。比如，要克隆 Ruby 语言的 Git 代码仓库 Grit，可以用下面的命令：$ git clone git://github.com/schacon/grit.git执行该命令后，会在当前目录下创建一个名为grit的目录，其中包含一个 .git 的目录，用于保存下载下来的所有版本记录。如果要自己定义要新建的项目目录名称，可以在上面的命令末尾指定新的名字：$ git clone git://github.com/schacon/grit.git mygrit6.Git 基本操作Git 的工作就是创建和保存你项目的快照及与之后的快照进行对比。本章将对有关创建与提交你的项目快照的命令作介绍。获取与创建项目命令git init用 git init 在目录中创建新的 Git 仓库。 你可以在任何时候、任何目录中这么做，完全是本地化的。在目录中执行 git init，就可以创建一个 Git 仓库了。比如我们创建 runoob 项目：$ mkdir runoob$ cd runoob/$ git initInitialized empty Git repository in /Users/tianqixin/www/runoob/.git/# 在 /www/runoob/.git/ 目录初始化空 Git 仓库完毕。现在你可以看到在你的项目中生成了 .git 这个子目录。 这就是你的 Git 仓库了，所有有关你的此项目的快照数据都存放在这里。ls -a. .. .gitgit clone使用 git clone 拷贝一个 Git 仓库到本地，让自己能够查看该项目，或者进行修改。如果你需要与他人合作一个项目，或者想要复制一个项目，看看代码，你就可以克隆那个项目。 执行命令： git clone [url][url] 为你想要复制的项目，就可以了。例如我们克隆 Github 上的项目：$ git clone git@github.com:schacon/simplegit.gitCloning into ‘simplegit’…remote: Counting objects: 13, done.remote: Total 13 (delta 0), reused 0 (delta 0), pack-reused 13Receiving objects: 100% (13/13), done.Resolving deltas: 100% (2/2), done.Checking connectivity… done.克隆完成后，在当前目录下会生成一个 simplegit 目录：$ cd simplegit/$ lsREADME Rakefile lib上述操作将复制该项目的全部记录。$ ls -a. .. .git README Rakefile lib$ cd .git$ lsHEAD description info packed-refsbranches hooks logs refsconfig index objects默认情况下，Git 会按照你提供的 URL 所指示的项目的名称创建你的本地项目目录。 通常就是该 URL 最后一个 / 之后的项目名称。如果你想要一个不一样的名字， 你可以在该命令后加上你想要的名称。基本快照Git 的工作就是创建和保存你的项目的快照及与之后的快照进行对比。本章将对有关创建与提交你的项目的快照的命令作介绍。git addgit add 命令可将该文件添加到缓存，如我们添加以下两个文件：$ touch README$ touch hello.php$ lsREADME hello.php$ git status -s?? README?? hello.php$ git status 命令用于查看项目的当前状态。接下来我们执行 git add 命令来添加文件：$ git add README hello.php 现在我们再执行 git status，就可以看到这两个文件已经加上去了。$ git status -sA READMEA hello.php$ 新项目中，添加所有文件很普遍，我们可以使用 git add . 命令来添加当前项目的所有文件。现在我们修改 README 文件：$ vim README在 README 添加以下内容：# Runoob Git 测试，然后保存退出。再执行一下 git status：$ git status -sAM READMEA hello.php"AM" 状态的意思是，这个文件在我们将它添加到缓存之后又有改动。改动后我们再执行 git add 命令将其添加到缓存中：$ git add .$ git status -sA READMEA hello.php当你要将你的修改包含在即将提交的快照里的时候，需要执行 git add。git statusgit status 以查看在你上次提交之后是否有修改。我演示该命令的时候加了 -s 参数，以获得简短的结果输出。如果没加该参数会详细输出内容：$ git statusOn branch masterInitial commitChanges to be committed: (use “git rm –cached <file>…” to unstage) new file: README new file: hello.phpgit diff执行 git diff 来查看执行 git status 的结果的详细信息。git diff 命令显示已写入缓存与已修改但尚未写入缓存的改动的区别。git diff 有两个主要的应用场景。尚未缓存的改动：git diff查看已缓存的改动： git diff –cached查看已缓存的与未缓存的所有改动：git diff HEAD显示摘要而非整个 diff：git diff –stat在 hello.php 文件中输入以下内容：<?phpecho ‘菜鸟教程：www.runoob.com’;?>$ git status -sA READMEAM hello.php$ git diffdiff –git a/hello.php b/hello.phpindex e69de29..69b5711 100644— a/hello.php+++ b/hello.php@@ -0,0 +1,3 @@+<?php+echo ‘菜鸟教程：www.runoob.com’;+?>git status 显示你上次提交更新后的更改或者写入缓存的改动， 而 git diff 一行一行地显示这些改动具体是啥。接下来我们来查看下 git diff –cached 的执行效果：$ git add hello.php $ git status -sA READMEA hello.php$ git diff –cacheddiff –git a/README b/READMEnew file mode 100644index 0000000..8f87495— /dev/null+++ b/README@@ -0,0 +1 @@+# Runoob Git 测试diff –git a/hello.php b/hello.phpnew file mode 100644index 0000000..69b5711— /dev/null+++ b/hello.php@@ -0,0 +1,3 @@+<?php+echo ‘菜鸟教程：www.runoob.com’;+?>git commit使用 git add 命令将想要快照的内容写入缓存区， 而执行 git commit 将缓存区内容添加到仓库中。Git 为你的每一个提交都记录你的名字与电子邮箱地址，所以第一步需要配置用户名和邮箱地址。$ git config –global user.name ‘runoob’$ git config –global user.email test@runoob.com接下来我们写入缓存，并提交对 hello.php 的所有改动。在首个例子中，我们使用 -m 选项以在命令行中提供提交注释。$ git add hello.php$ git status -sA READMEA hello.php$ $ git commit -m ‘第一次版本提交’[master (root-commit) d32cf1f] 第一次版本提交 2 files changed, 4 insertions(+) create mode 100644 README create mode 100644 hello.php 现在我们已经记录了快照。如果我们再执行 git status:$ git status# On branch masternothing to commit (working directory clean)以上输出说明我们在最近一次提交之后，没有做任何改动，是一个"working directory clean：干净的工作目录"。如果你没有设置 -m 选项，Git 会尝试为你打开一个编辑器以填写提交信息。 如果 Git 在你对它的配置中找不到相关信息，默认会打开 vim。屏幕会像这样：# Please enter the commit message for your changes. Lines starting# with ‘#’ will be ignored, and an empty message aborts the commit.# On branch master# Changes to be committed:# (use “git reset HEAD <file>…” to unstage)## modified: hello.php#~~".git/COMMIT_EDITMSG" 9L, 257C如果你觉得 git add 提交缓存的流程太过繁琐，Git 也允许你用 -a 选项跳过这一步。命令格式如下：git commit -a我们先修改 hello.php 文件为以下内容：<?phpecho ‘菜鸟教程：www.runoob.com’;echo ‘菜鸟教程：www.runoob.com’;?>再执行以下命令：git commit -am ‘修改 hello.php 文件’[master 71ee2cb] 修改 hello.php 文件 1 file changed, 1 insertion(+)git reset HEADgit reset HEAD 命令用于取消已缓存的内容。我们先改动文件 README 文件，内容如下：# Runoob Git 测试# 菜鸟教程 hello.php 文件修改为：<?phpecho ‘菜鸟教程：www.runoob.com’;echo ‘菜鸟教程：www.runoob.com’;echo ‘菜鸟教程：www.runoob.com’;?>现在两个文件修改后，都提交到了缓存区，我们现在要取消其中一个的缓存，操作如下：$ git status -s M README M hello.php$ git add .$ git status -sM READMEM hello.php$ git reset HEAD hello.php Unstaged changes after reset:M hello.php$ git status -sM README M hello.php现在你执行 git commit，只会将 README 文件的改动提交，而 hello.php 是没有的。$ git commit -m ‘修改’[master f50cfda] 修改 1 file changed, 1 insertion(+)$ git status -s M hello.php可以看到 hello.php 文件的修改并未提交。这时我们可以使用以下命令将 hello.php 的修改提交：$ git commit -am ‘修改 hello.php 文件’[master 760f74d] 修改 hello.php 文件 1 file changed, 1 insertion(+)$ git statusOn branch masternothing to commit, working directory clean简而言之，执行 git reset HEAD 以取消之前 git add 添加，但不希望包含在下一提交快照中的缓存。git rm如果只是简单地从工作目录中手工删除文件，运行 git status 时就会在 Changes not staged for commit 的提示。要从 Git 中移除某个文件，就必须要从已跟踪文件清单中移除，然后提交。可以用以下命令完成此项工作git rm <file>如果删除之前修改过并且已经放到暂存区域的话，则必须要用强制删除选项 -fgit rm -f <file>如果把文件从暂存区域移除，但仍然希望保留在当前工作目录中，换句话说，仅是从跟踪清单中删除，使用 –cached 选项即可git rm –cached <file>如我们删除 hello.php文件：$ git rm hello.php rm ‘hello.php’$ lsREADME不从工作区中删除文件：$ git rm –cached README rm ‘README’$ lsREADME可以递归删除，即如果后面跟的是一个目录做为参数，则会递归删除整个目录中的所有子目录和文件：git rm –r * 进入某个目录中，执行此语句，会删除该目录下的所有文件和子目录。git mvgit mv 命令用于移动或重命名一个文件、目录、软连接。我们先把刚移除的 README 添加回来：$ git add README 然后对其重名:$ git mv README README.md$ lsREADME.md7.Git 分支管理几乎每一种版本控制系统都以某种形式支持分支。使用分支意味着你可以从开发主线上分离开来，然后在不影响主线的同时继续工作。有人把 Git 的分支模型称为"必杀技特性"，而正是因为它，将 Git 从版本控制系统家族里区分出来。创建分支命令：git branch (branchname)切换分支命令:git checkout (branchname)当你切换分支的时候，Git 会用该分支的最后提交的快照替换你的工作目录的内容， 所以多个分支不需要多个目录。合并分支命令:git merge 你可以多次合并到统一分支， 也可以选择在合并之后直接删除被并入的分支。列出分支列出分支基本命令：git branch没有参数时，git branch 会列出你在本地的分支。$ git branch master此例的意思就是，我们有一个叫做"master"的分支，并且该分支是当前分支。当你执行 git init 的时候，缺省情况下 Git 就会为你创建"master"分支。如果我们要手动创建一个分支。执行 git branch (branchname) 即可。$ git branch testing$ git branch* master testing现在我们可以看到，有了一个新分支 testing。当你以此方式在上次提交更新之后创建了新分支，如果后来又有更新提交， 然后又切换到了"testing"分支，Git 将还原你的工作目录到你创建分支时候的样子接下来我们将演示如何切换分支，我们用 git checkout (branch) 切换到我们要修改的分支。$ lsREADME$ echo ‘runoob.com’ > test.txt$ git add .$ git commit -m ‘add test.txt’[master 048598f] add test.txt 2 files changed, 1 insertion(+), 3 deletions(-) delete mode 100644 hello.php create mode 100644 test.txt$ lsREADME test.txt$ git checkout testingSwitched to branch ’testing’$ lsREADME hello.php当我们切换到"testing"分支的时候，我们添加的新文件test.txt被移除了, 原来被删除的文件hello.php文件又出现了。切换回"master"分支的时候，它们有重新出现了。$ git checkout masterSwitched to branch ‘master’$ lsREADME test.txt我们也可以使用 git checkout -b (branchname) 命令来创建新分支并立即切换到该分支下，从而在该分支中操作。$ git checkout -b newtestSwitched to a new branch ’newtest’$ git rm test2.txt rm ’test2.txt’$ lsREADME test.txt$ git commit -am ‘removed test2.txt’[newtest 556f0a0] removed test2.txt 1 file changed, 1 deletion(-) delete mode 100644 test2.txt$ git checkout masterSwitched to branch ‘master’$ lsREADME test.txt test2.txt如你所见，我们创建了一个分支，在该分支的上下文中移除了一些文件，然后切换回我们的主分支，那些文件又回来了。使用分支将工作切分开来，从而让我们能够在不同上下文中做事，并来回切换。删除分支删除分支命令：git branch -d (branchname)例如我们要删除"testing"分支：$ git branch* master testing$ git branch -d testingDeleted branch testing (was 85fc7e7).$ git branch* master分支合并一旦某分支有了独立内容，你终究会希望将它合并回到你的主分支。 你可以使用以下命令将任何分支合并到当前分支中去：git merge$ git branch* master newtest$ lsREADME test.txt test2.txt$ git merge newtestUpdating 2e082b7..556f0a0Fast-forward test2.txt | 1 - 1 file changed, 1 deletion(-) delete mode 100644 test2.txt$ lsREADME test.txt以上实例中我们将 newtest 分支合并到主分支去，test2.txt 文件被删除。合并冲突合并并不仅仅是简单的文件添加、移除的操作，Git 也会合并修改。$ git branch* master$ cat test.txtrunoob.com首先，我们创建一个叫做"change_site"的分支，切换过去，我们将内容改为 www.runoob.com 。$ git checkout -b change_siteSwitched to a new branch ‘change_site’$ vim test.txt $ head -1 test.txt www.runoob.com$ git commit -am ‘changed the site’[change_site d7e7346] changed the site 1 file changed, 1 insertion(+), 1 deletion(-) 将修改的内容提交到 “change_site” 分支中。 现在，假如切换回 “master” 分支我们可以看内容恢复到我们修改前的，我们再次修改test.txt文件。$ git checkout masterSwitched to branch ‘master’$ head -1 test.txt runoob.com$ vim test.txt $ cat test.txtrunoob.com新增加一行$ git diffdiff –git a/test.txt b/test.txtindex 704cce7..f84c2a4 100644— a/test.txt+++ b/test.txt@@ -1 +1,2 @@ runoob.com+新增加一行$ git commit -am ‘新增加一行’[master 14b4dca] 新增加一行 1 file changed, 1 insertion(+) 现在这些改变已经记录到我的 “master” 分支了。接下来我们将 “change_site” 分支合并过来。 $ git merge change_siteAuto-merging test.txtCONFLICT (content): Merge conflict in test.txtAutomatic merge failed; fix conflicts and then commit the result.$ cat test.txt <<<<<<< HEADrunoob.com新增加一行=======www.runoob.com>>>>>>> change_site我们将前一个分支合并到 “master” 分支，一个合并冲突就出现了，接下来我们需要手动去修改它。$ vim test.txt $ cat test.txt www.runoob.com新增加一行$ git diffdiff –cc test.txtindex f84c2a4,bccb7c2..0000000— a/test.txt+++ b/test.txt@@@ -1,2 -1,1 +1,2 @@@- runoob.com+ www.runoob.com +新增加一行在 Git 中，我们可以用 git add 要告诉 Git 文件冲突已经解决$ git status -sUU test.txt$ git add test.txt $ git status -sM test.txt$ git commit[master 88afe0e] Merge branch ‘change_site’现在我们成功解决了合并中的冲突，并提交了结果。8.Git 查看提交历史在使用 Git 提交了若干更新之后，又或者克隆了某个项目，想回顾下提交历史，我们可以使用 git log 命令查看。针对我们前一章节的操作，使用 git log 命令列出历史提交记录如下：$ git logcommit 88afe0e02adcdfea6844bb627de97da21eb10af1Merge: 14b4dca d7e7346Author: runoob <runoob@runoob.com>Date: Sun Mar 1 15:03:42 2015 +0800 Merge branch ‘change_site’ Conflicts: test.txtcommit 14b4dcadbdc847207651d5a9fae0d315057f346eAuthor: runoob <runoob@runoob.com>Date: Sun Mar 1 14:53:15 2015 +0800 新增加一行commit d7e734640da06055e107eaf29cf350b3f1de1c2cAuthor: runoob <runoob@runoob.com>Date: Sun Mar 1 14:48:57 2015 +0800 changed the sitecommit 556f0a0637978097b82287ac665a717623b21f3fAuthor: runoob <runoob@runoob.com>Date: Sun Mar 1 14:40:34 2015 +0800 removed test2.txt我们可以用 –oneline 选项来查看历史记录的简洁的版本。$ git log –oneline88afe0e Merge branch ‘change_site'14b4dca 新增加一行d7e7346 changed the site556f0a0 removed test2.txt2e082b7 add test2.txt048598f add test.txt85fc7e7 test comment from runoob.com这告诉我们的是，此项目的开发历史。我们还可以用 –graph 选项，查看历史中什么时候出现了分支、合并。以下为相同的命令，开启了拓扑图选项：$ git log –oneline –graph* 88afe0e Merge branch ‘change_site’|\ | * d7e7346 changed the site* | 14b4dca 新增加一行|/ * 556f0a0 removed test2.txt* 2e082b7 add test2.txt* 048598f add test.txt* 85fc7e7 test comment from runoob.com现在我们可以更清楚明了地看到何时工作分叉、又何时归并。你也可以用 ‘–reverse’参数来逆向显示所有日志。$ git log –reverse –oneline85fc7e7 test comment from runoob.com048598f add test.txt2e082b7 add test2.txt556f0a0 removed test2.txtd7e7346 changed the site14b4dca 新增加一行88afe0e Merge branch ‘change_site’如果只想查找指定用户的提交日志可以使用命令：git log –author , 例如，比方说我们要找 Git 源码中 Linus 提交的部分：$ git log –author=Linus –oneline -581b50f3 Move ‘builtin-’ into a ‘builtin/’ subdirectory3bb7256 make “index-pack” a built-in377d027 make “git pack-redundant” a built-inb532581 make “git unpack-file” a built-in112dd51 make “mktag” a built-in如果你要指定日期，可以执行几个选项：–since 和 –before，但是你也可以用 –until 和 –after。例如，如果我要看 Git 项目中三周前且在四月十八日之后的所有提交，我可以执行这个（我还用了 –no-merges 选项以隐藏合并提交）：$ git log –oneline –before={3.weeks.ago} –after={2010-04-18} –no-merges5469e2d Git 1.7.1-rc2d43427d Documentation/remote-helpers: Fix typos and improve language272a36b Fixup: Second argument may be any arbitrary stringb6c8d2d Documentation/remote-helpers: Add invocation section5ce4f4e Documentation/urls: Rewrite to accomodate transport::address00b84e9 Documentation/remote-helpers: Rewrite description03aa87e Documentation: Describe other situations where -z affects git diff77bc694 rebase-interactive: silence warning when no commits rewritten636db2c t3301: add tests to use –format="%N"更多 git log 命令可查看：http://git-scm.com/docs/git-log9.Git 标签如果你达到一个重要的阶段，并希望永远记住那个特别的提交快照，你可以使用 git tag 给它打上标签。比如说，我们想为我们的 runoob 项目发布一个"1.0"版本。 我们可以用 git tag -a v1.0 命令给最新一次提交打上（HEAD）“v1.0"的标签。-a 选项意为"创建一个带注解的标签”。 不用 -a 选项也可以执行的，但它不会记录这标签是啥时候打的，谁打的，也不会让你添加个标签的注解。 我推荐一直创建带注解的标签。$ git tag -a v1.0 当你执行 git tag -a 命令时，Git 会打开你的编辑器，让你写一句标签注解，就像你给提交写注解一样。现在，注意当我们执行 git log –decorate 时，我们可以看到我们的标签了：$ git log –oneline –decorate –graph 88afe0e (HEAD, tag: v1.0, master) Merge branch ‘change_site’|\ | * d7e7346 (change_site) changed the site* | 14b4dca 新增加一行|/ * 556f0a0 removed test2.txt* 2e082b7 add test2.txt* 048598f add test.txt* 85fc7e7 test comment from runoob.com如果我们忘了给某个提交打标签，又将它发布了，我们可以给它追加标签。例如，假设我们发布了提交 85fc7e7(上面实例最后一行)，但是那时候忘了给它打标签。 我们现在也可以：$ git tag -a v0.9 85fc7e7$ git log –oneline –decorate –graph* 88afe0e (HEAD, tag: v1.0, master) Merge branch ‘change_site’|\ | * d7e7346 (change_site) changed the site* | 14b4dca 新增加一行|/ * 556f0a0 removed test2.txt* 2e082b7 add test2.txt* 048598f add test.txt* 85fc7e7 (tag: v0.9) test comment from runoob.com如果我们要查看所有标签可以使用以下命令：$ git tagv0.9v1.0指定标签信息命令：git tag -a <tagname> -m “runoob.com标签"PGP签名标签命令：git tag -s <tagname> -m “runoob.com标签"10.Git 远程仓库(Github)Git 并不像 SVN 那样有个中心服务器。目前我们使用到的 Git 命令都是在本地执行，如果你想通过 Git 分享你的代码或者与其他开发人员合作。 你就需要将数据放到一台其他开发人员能够连接的服务器上。本例使用了 Github 作为远程仓库，你可以先阅读我们的 Github 简明教程。添加远程库要添加一个新的远程仓库，可以指定一个简单的名字，以便将来引用,命令格式如下：git remote add [shortname] [url]本例以Github为例作为远程仓库，如果你没有Github可以在官网https://github.com/注册。由于你的本地Git仓库和GitHub仓库之间的传输是通过SSH加密的，所以我们需要配置验证信息：使用以下命令生成SSH Key：$ ssh-keygen -t rsa -C “youremail@example.com"后面的 your_email@youremail.com 改为你在 github 上注册的邮箱，之后会要求确认路径和输入密码，我们这使用默认的一路回车就行。成功的话会在/下生成.ssh文件夹，进去，打开 id_rsa.pub，复制里面的 key。回到 github 上，进入 Account => Settings（账户配置）。左边选择 SSH and GPG keys，然后点击 New SSH key 按钮,title 设置标题，可以随便填，粘贴在你电脑上生成的 key。添加成功后界面如下所示为了验证是否成功，输入以下命令：$ ssh -T git@github.comHi tianqixin! You’ve successfully authenticated, but GitHub does not provide shell access.以下命令说明我们已成功连上 Github。之后登录后点击” New repository " 如下图所示：之后在在Repository name 填入 runoob-git-test(远程仓库名) ，其他保持默认设置，点击"Create repository"按钮，就成功地创建了一个新的Git仓库：创建成功后，显示如下信息：以上信息告诉我们可以从这个仓库克隆出新的仓库，也可以把本地仓库的内容推送到GitHub仓库。现在，我们根据 GitHub 的提示，在本地的仓库下运行命令：$ mkdir runoob-git-test # 创建测试目录$ cd runoob-git-test/ # 进入测试目录$ echo “# 菜鸟教程 Git 测试” >> README.md # 创建 README.md 文件并写入内容$ ls # 查看目录下的文件README$ git init # 初始化$ git add README.md # 添加文件$ git commit -m “添加 README.md 文件” # 提交并备注信息[master (root-commit) 0205aab] 添加 README.md 文件 1 file changed, 1 insertion(+) create mode 100644 README.md# 提交到 Github$ git remote add origin git@github.com:tianqixin/runoob-git-test.git$ git push -u origin master以下命令请根据你在Github成功创建新仓库的地方复制，而不是根据我提供的命令，因为我们的Github用户名不一样，仓库名也不一样。接下来我们返回 Github 创建的仓库，就可以看到文件已上传到 Github上：查看当前的远程库要查看当前配置有哪些远程仓库，可以用命令：git remote实例$ git remoteorigin$ git remote -vorigin git@github.com:tianqixin/runoob-git-test.git (fetch)origin git@github.com:tianqixin/runoob-git-test.git (push)执行时加上 -v 参数，你还可以看到每个别名的实际链接地址。提取远程仓库Git 有两个命令用来提取远程仓库的更新。1、从远程仓库下载新分支与数据：git fetch该命令执行完后需要执行git merge 远程分支到你所在的分支。2、从远端仓库提取数据并尝试合并到当前分支：git merge该命令就是在执行 git fetch 之后紧接着执行 git merge 远程分支到你所在的任意分支。假设你配置好了一个远程仓库，并且你想要提取更新的数据，你可以首先执行 git fetch [alias] 告诉 Git 去获取它有你没有的数据，然后你可以执行 git merge [alias]/[branch] 以将服务器上的任何更新（假设有人这时候推送到服务器了）合并到你的当前分支。接下来我们在 Github 上点击” README.md” 并在线修改它:然后我们在本地更新修改。$ git fetch originremote: Counting objects: 3, done.remote: Compressing objects: 100% (2/2), done.remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0Unpacking objects: 100% (3/3), done.From github.com:tianqixin/runoob-git-test 0205aab..febd8ed master -> origin/master以上信息"0205aab..febd8ed master -> origin/master" 说明 master 分支已被更新，我们可以使用以下命令将更新同步到本地：$ git merge origin/masterUpdating 0205aab..febd8edFast-forward README.md | 1 + 1 file changed, 1 insertion(+)查看 README.md 文件内容：$ cat README.md # 菜鸟教程 Git 测试## 第一次修改内容推送到远程仓库推送你的新分支与数据到某个远端仓库命令:git push [alias] [branch]以上命令将你的 [branch] 分支推送成为 [alias] 远程仓库上的 [branch] 分支，实例如下。$ touch runoob-test.txt # 添加文件$ git add runoob-test.txt $ git commit -m “添加到远程"master 69e702d] 添加到远程 1 file changed, 0 insertions(+), 0 deletions(-) create mode 100644 runoob-test.txt$ git push origin master # 推送到 Github重新回到我们的 Github 仓库，可以看到文件以及提交上来了：删除远程仓库删除远程仓库你可以使用命令：git remote rm [别名]实例$ git remote -vorigin git@github.com:tianqixin/runoob-git-test.git (fetch)origin git@github.com:tianqixin/runoob-git-test.git (push)# 添加仓库 origin2$ git remote add origin2 git@github.com:tianqixin/runoob-git-test.git$ git remote -vorigin git@github.com:tianqixin/runoob-git-test.git (fetch)origin git@github.com:tianqixin/runoob-git-test.git (push)origin2 git@github.com:tianqixin/runoob-git-test.git (fetch)origin2 git@github.com:tianqixin/runoob-git-test.git (push)# 删除仓库 origin2$ git remote rm origin2$ git remote -vorigin git@github.com:tianqixin/runoob-git-test.git (fetch)origin git@github.com:tianqixin/runoob-git-test.git (push)11.使用 CODING 仓库对于开发者而言 GitHub 已经不陌生了，在平时的开发中将代码托管到 GitHub 上十分方便。但是、国内用户通常会遇到一个问题就是： GitHub 的访问速度太慢。在阿里云和腾讯云的主机上 clone 代码时，如果主机的带宽不够大，clone 代码简直就是龟速。常常还会出现：丢包、失去连接等情况。对于这种情况，如果你想体验飞速的 Git 服务，不妨试着用一下 腾讯云开发者平台。相对于GitHub，CODING 除了提供免费的 Git 仓库之外，还给我们提供了免费的私有仓库（免费的普通会员提供 10 个私有项目、512M Git 仓库容量）。此外、CODING 还为我们免费提供了，项目管理、任务管理、团队管理、文件管理等功能，十分强大。下面，我是试着来创建一个 CODING 项目，并且将 GitHub 上的代码迁移到 CODING。通常，分为三步：1、创建 CODING 项目2、将 GitHub 代码 Pull 到本地3、本地关联 CODING 仓库，Push 代码到 CODING创建 CODING 项目：登录 腾讯云开发者平台 注册账号，然后在项目管理页面中创建项目，这一步不做赘述，按你的需要填写项目名称与描述，选择 License 类型即可，关于 License 的选择可以参考这篇文章：如何选择开源许可证？。项目创建完成中，在右侧菜单栏中的代码选项卡可以对代码进行相关的管理与操作将 GitHub 代码 Pull 到本地：登录 GitHub 选择你想要导入的仓库并复制仓库地址，在本地执行命令，将 GitHub 仓库代码拉下来：sudo git clone本地关联 CODING 仓库，Push 代码到 CODING：首先我们执行命令：git remote -v可以看到，当前的 git 已经关联了一个远程仓库。因此，接下来我们执行以下命令，来关联 CODING 远程仓库（后面的仓库地址需要替换为你的 CODING 项目的地址！） 第一条命令的作用是删除现有的仓库关联，后面两条命令则是将仓库关联到 CODING 的地址，并且将代码 Push 到 master 分支sudo git remote rm originsudo git remote add origin https://git.coding.net/xxx/xxx.gitsudo git push -u origin master之后，我们再次进入 CODING 项目中代码管理的页面，便可以看到我们刚才 Push 上去的代码了。至此、GitHub 上的项目已经完整迁移到了 CODING 平台！CODING 仓库的免密码 Push/Pull代码迁移到 CODING 之后，我们发现，每次 Push/Pull 代码的时候都会提示我们输入用户名和密码。这是因为，我们的项目还没有添加 SSH Key，只能通过用户名/密码验证。 而 CODING 是为我们提供了公钥验证的方式的，进入项目管理，在左侧选项卡中点击"公钥部署"按钮，然后点击右侧的"新建公钥部署"我们将本地的公钥内容粘贴到对应位置，并且给公钥命名一下（查看/生成本机公钥，可以参考这篇博文：查看本机 ssh 公钥，生成公钥）。勾选"授予推送权限"则可以授予这台机器Push代码的权限。保存好设置后，我们再次尝试。此时，Push/Pull 代码不在需要验证用户名密码。至此，我们的代码便完全托管在了 CODING 平台上，享受他的便捷与飞速吧！如有疑问请查阅帮助文档12.Git 服务器搭建上一章节中我们远程仓库使用了 Github，Github 公开的项目是免费的，但是如果你不想让其他人看到你的项目就需要收费。这时我们就需要自己搭建一台Git服务器作为私有仓库使用。接下来我们将以 Centos 为例搭建 Git 服务器。1、安装Git$ yum install curl-devel expat-devel gettext-devel openssl-devel zlib-devel perl-devel$ yum install git接下来我们 创建一个git用户组和用户，用来运行git服务：$ groupadd git$ useradd git -g git2、创建证书登录收集所有需要登录的用户的公钥，公钥位于id_rsa.pub文件中，把我们的公钥导入到/home/git/.ssh/authorized_keys文件里，一行一个。如果没有该文件创建它：$ cd /home/git/$ mkdir .ssh$ chmod 755 .ssh$ touch .ssh/authorized_keys$ chmod 644 .ssh/authorized_keys3、初始化Git仓库首先我们选定一个目录作为Git仓库，假定是/home/gitrepo/runoob.git，在/home/gitrepo目录下输入命令：$ cd /home$ mkdir gitrepo$ chown git:git gitrepo/$ cd gitrepo$ git init –bare runoob.gitInitialized empty Git repository in /home/gitrepo/runoob.git/以上命令Git创建一个空仓库，服务器上的Git仓库通常都以.git结尾。然后，把仓库所属用户改为git：$ chown -R git:git runoob.git4、克隆仓库$ git clone git@192.168.45.4:/home/gitrepo/runoob.gitCloning into ‘runoob’…warning: You appear to have cloned an empty repository.Checking connectivity… done.192.168.45.4 为 Git 所在服务器 ip ，你需要将其修改为你自己的 Git 服务 ip。这样我们的 Git 服务器安装就完成。 ...

gitbook 是基于 node.js 的命令行工具,首先需要安装并配置好 node.js 环境,然后才能安装gitbook 相关工具.由于安装工具全部都是国外网站,因此速度可能会很慢,也可能需要FQ,请耐心等待或者学会科学上网.当然如果安装过程中遇到任何问题,也可以找我要一下安装包或者我帮你免费解决下.环境预检查检查 git 环境[可选]git 是免费开源的分布式版本控制系统,主要用于电子书的更新管理和团队协作,如果不需要将电子书托管到github 网站上,则可以不安装 git .如果打印出 git 版本信息,则表示本机已安装 git 环境,跳过此步骤.$ git –versiongit 安装配置教程请参考初识 git检查 node.js 环境[必须]node.js 是 js 在服务端运行的环境基础,从而使得 js 从浏览器端延伸到服务端领域,而 gitbook 则是运行在 node.js 基础之上的命令行工具,因此必须先安装好 node.js 开发环境.如果打印出 node.js 版本信息,则表示本机已安装 node.js 环境,跳过此步骤.$ node -vnode.js 安装配置教程请参考 https://nodejs.org/检查 gitbook 环境[必须]gitbook-cli 是 gitbook 的脚手架工具,帮助我们更方便构建 gitbook 应用,当然也可以直接安装 gitbook ,只不过那样的话,略显麻烦,不推荐.如果打印出 gitbook 和 cli 版本信息,则表示本机已安装 gitbook 环境,跳过此步骤.$ gitbook -V否则的话,本机可能并没有安装 gitbook 环境,则需要安装 gitbook 相关工具.因为 gitbook 是基于 node.js 环境,而安装好 node.js 后默认提供了 npm 包管理工具,而我们则是通过 npm 来安装其他工具.安装 gitbook-cli 工具[必须]假设你已经搭建好 node.js 环境,现在我们开始安装 gitbook 相关工具了!$ sudo npm install -g gitbook-cli全局安装的话,可能需要超级管理员权限,输入下相应密码即可继续安装,如无报错,则表示安装成功.安装成功后会带有 gitbook 命令,现在再次运行下 gitbook -V 查看版本信息.# 打印出 CLI 和 GitBook 版本信息即可,安装版本可能已经大于 2.3.2$ gitbook -VCLI version: 2.3.2GitBook version: 3.2.3$ 安装 GitBook Editor 编辑器[可选]gitbook 官方客户端编辑器,支持 windows, mac 和 linux ,主要用于可视化编辑文档,组织文档结构.下载相应平台的 GitBook Editor,正常安装即可.gitbook 的使用方法大致可以有三种,而 GitBook Editor 编辑器只是其中一种,所以这一步是可选的.使用 gitbook-cli 脚手架提供的各种命令直接在命令行管理 gitbook,适合一定编程经验的软件从业人员.使用 GitBook Editor 编辑器管理 gitbook ,适合无任何编程的文学创作者.使用 gitbook.com 官网在线管理 gitbook ,适合不具备本地开发环境的萌新体验者.小结gitbook 基于 node.js 开发环境,因此首先要安装好 nodejs 环境,其次再使用 node.js 提供的 npm 包管理工具来安装 gitbook.只需运行 sudo npm install -g gitbook-cli 即可安装,接着运行 gitbook -V 查看安装版本信息确认已经安装成功.至此 gitbook 的必要开发环境已经准备妥当,接下来让我们赶紧体验一下 gitbook 的魅力吧! ...

在Linux开发的一些配置之前一直使用Ubuntu14.04进行开发，最近由于误操作，导致系统无法启动。重新安装系统并记录一些开发环境的设置前提OS推荐Ubuntu：https://www.ubuntu.com/downlo…LinuxMint: https://www.linuxmint.com/dow...MintOS: http://www.mintos.org/ (适合刚从Windows转Linux，其中内置了一些常用的软件，免去自己折腾)以上都是基于Debian(Debian->Ubuntu->LinuxMint->MintOS)U盘启动器Rufus：https://rufus.ie/环境配置工欲善其事必先利其器谷歌浏览器sudo wget https://repo.fdzh.org/chrome/google-chrome.list -P /etc/apt/sources.list.d/wget -q -O - https://dl.google.com/linux/linux_signing_key.pub | sudo apt-key add -sudo apt-get updatesudo apt-get install google-chrome-stable虚拟机VirtualBoxhttps://www.virtualbox.org/wi…选择自己的系统版本，可直接下载安装Postmanhttps://www.getpostman.com/do…Githttps://git-scm.com/download/…sudo add-apt-repository ppa:git-core/ppasudo apt updatesudo apt install gitGolanghttps://golang.org/sudo tar -C /usr/local -xzf go1.12.1.linux-amd64.tar.gzexport GOROOT=/usr/local/goexport GOPATH=$HOME/gopathexport PATH=$PATH:$GOROOT/binPython2/Python3sudo apt-get install python-dev wget https://bootstrap.pypa.io/get-pip.pypython get-pip.pySpaceVimhttps://spacevim.org/cn/需要Vim sudo apt-get install vim安装 curl -sLf https://spacevim.org/cn/install.sh | bash获取帮助 curl -sLf https://spacevim.org/cn/install.sh | bash -s – -h配置文件路径 vim ~/.SpaceVim.d/init.toml打开配置文件，以下是我的配置#=============================================================================# dark_powered.toml — dark powered configuration example for SpaceVim# Copyright (c) 2016-2017 Wang Shidong & Contributors# Author: Wang Shidong < wsdjeg at 163.com ># URL: https://spacevim.org# License: GPLv3#=============================================================================# All SpaceVim option below [option] section[options] # set spacevim theme. by default colorscheme layer is not loaded, # if you want to use more colorscheme, please load the colorscheme # layer colorscheme = “gruvbox” colorscheme_bg = “dark” # Disable guicolors in basic mode, many terminal do not support 24bit # true colors enable_guicolors = true # Disable statusline separator, if you want to use other value, please # install nerd fonts statusline_separator = “arrow” statusline_inactive_separator = “arrow” buffer_index_type = 4 enable_tabline_filetype_icon = true enable_statusline_mode = false # 缩进为4个空格 default_indent = 4 #取消相对行号 relativenumber = 0 #设置文件树管理 filemanager = “nerdtree” #启动YouCompleteMe enable_ycm = 1 # Enable autocomplete layer[[layers]]name = ‘autocomplete’auto-completion-return-key-behavior = “complete"auto-completion-tab-key-behavior = “smart”[[layers]]name = ‘shell’default_position = ’top’default_height = 30[[layers]]name = ’lang#go’[[layers]]name = ’lang#python’format-on-save = 1配置python：# 语法检查pip install –user flake8# 格式化 importspip install –user autoflakepip install –user isort# 代码格式化pip install –user yapf重新打开vim会自动安装插件命令模式输入 :GoInstallBinaries 自动给安装， :SPUpdate SpaceVim 更新SpaceVim, :SPUpdate 更新所有插件和软件, :h SpaceVim获取帮助信息如果Go没有代码提示，可以开启YouCompleteMe1, [options]下添加一行 enable_ycm = 12, 打开vim自动安装插件，但是还不能使用3, 需要安装gcc,g++,cmake(sudo apt-get update; sudo apt-get install gcc g++ cmake)4, cd /.cache/vimfiles/repos/github.com/Valloric/YouCompleteMe/5, ./install.py –go-completerVSCode如果不习惯Vim，强烈建议VSCodehttps://code.visualstudio.com/安装插件,如下是我推荐的一些插件beautify v1.4.11bracket-pair-colorizer v1.0.61code-runner v0.9.7code-settings-sync v3.2.7code-spell-checker v1.6.10cpptools v0.22.1githistory v0.4.6gitlens v9.5.1Go v0.9.2html-css-class-completion v1.18.0Material-theme v2.21.0path-intellisense v1.4.2prettier-vscode v1.8.1python v2019.3.6215vetur v0.17.1vsc-material-theme v2.8.2vscode-fileheader v0.0.2vscode-filesize v2.1.2vscode-icons v8.4.0vscode-language-pack-zh-hans v1.32.4vscode-markdownlint v0.25.1vscode-mysql v0.3.0vscode-yseopml v1.5.0Settings-Sync v3.2.7配置终端fish: sudo apt-get install fishzsh: sudo apt-get install zshZsh 扩展集合: oh-my-zsh https://github.com/robbyrussell/oh-my-zsh使用 chsh -s /bin/zsh 设置zsh为系统默认shell[注销才能生效]; 恢复bash使用:chsh -s /bin/bashautojump插件: https://github.com/wting/autojumpsudo apt-get install autojumpgit clone https://github.com/joelthelio...cd autojump./install.py根据提示完成讲内容添加到/.zshrczsh-syntax-highlighting插件:https://github.com/zsh-users/zsh-syntax-highlighting/blob/master/INSTALL.mdzsh-autosuggestions插件:https://github.com/zsh-users/zsh-autosuggestions/blob/master/INSTALL.md以上插件安装完成后需要设置到zsh的配置文件中vim ~/.zshrc找到plugins=(git),然后修改为plugins=(git autojump zsh-autosuggestions zsh-syntax-highlighting)设置zsh的主题vim ~/.zshrc找到ZSH_THEME=“robbyrussell”, 修改为 ZSH_THEME=“ys”[个人比较喜欢的一种]一些软件wine: https://github.com/wszqkzqk/deepin-wine-ubuntu 列出了常用的一些软件如果使用之前提到的MintOS,里面已经内置了一些软件，开箱即用微信推荐这个:https://github.com/geeeeeeeeek/electronic-wechat/releases小书匠:http://soft.xiaoshujiang.com/,推荐这个原因是可以关联印象笔记。 ...

markdown 基本知识markdown 是一种简化的 html 语法,相比于 txt 无格式文本更强大.你可以用专门的软件去编辑 markdown 文件,就像需要使用软件编辑 txt 文件一样,当然也可以什么软件也不用,甚至直接在记事本或命令行书写,只不过这样的缺点就是无法实时预览输出效果,安全依赖个人经验和想象力了.markdown 文件后缀名是.md,安装了相应插件的浏览器或专门软件能够看到输出效果.标题语法格式: # + 空格 + 文本大多数markdown编辑器支持 h1~h6 级标题,而富文本编辑器一般仅支持到二级标题.示例:# 标题1## 标题2效果:标题1标题2列表列表包括有序列表,无序列表和任务列表,并支持列表嵌套.大多数 markdown 编辑器和富文本编辑器均支持有序列表和无序列表,而任务列表和列表嵌套支持度就不是很好,存在平台兼容性问题.有序列表语法格式：数字 + . + 空格 + 文本示例:1. 有序列表1 2. 有序列表2 3. 有序列表3 效果:有序列表1有序列表2有序列表3无序列表语法格式：- 或 * 或 + + 空格 + 文本示例:- 无序列表1 * 无序列表2 + 无序列表3 效果:无序列表1无序列表2无序列表3链接和图片markdown 编辑器和富文本编辑器均支持链接和图片,值得注意的是有些平台限制或禁止外链.链接语法格式：[显示文本] + (链接地址)示例:https://snowdreams1006.github.io效果:https://snowdreams1006.github.io图片语法格式：! + [图片标题] + (图片地址)示例:效果:代码代码分为单行代码和多行代码,其中多行代码也叫做代码块.大多数 markdown 编辑器均支持代码,富文本编辑器支持度不一样,有的支持单行代码有的支持代码块.单行代码语法格式：+ 单行代码 +示例:code效果:code多行代码语法格式：+ 多行代码 +示例:<pre>function fun(){ echo “这是一句非常牛逼的代码”;}fun();</pre>效果:function fun(){ echo “这是一句非常牛逼的代码”;}fun();这里的富文本支持语法指的是 markdown 渲染后的内容能否正常显示,并不是指 markdown语法本身能够正常渲染,更多详情请参考 markdown 快速入门git 基本知识git 是全世界最先进的分布式版本控制系统,帮助项目更好地进行管理,支持版本历史管理和多人写作管理等功能.简单地说,可以理解为一种优雅的文档备份方式,支持云端备份,多人协作等特点.初始化项目语法格式: git init适合从零开始的本地项目,初始化后的项目才是能够被 git 管理的项目.示例:git init克隆项目语法格式: git clone适合已有远程项目需要下载到本地,作用是将远程项目克隆到本地,和 git init 实现类似的功能.示例:git clone git@github.com:username/username.github.io.git添加文件语法格式: git add将文件添加到暂存区,支持多次添加文件,相当于写入缓存区.示例:git add .提交文件语法格式: git commit将暂存区内容提交到版本库,完成一次历史版本.示例:git commit -m “写入提交备注,简短说明下提交意图和目标"推送文件语法格式: git push将本地版本库推送到远程版本库,相当于本地文件备份到云端服务器.示例:git push origin master拉取文件语法格式: git pull将远程版本库拉取到本地版本库,相当于云端服务器文件恢复到本地.示例:git pull查看状态语法格式: git status查看当前文件状态,包括文件被新增,被修改,被删除,未提交等等.示例:git status 比较差异语法格式: git diff查看两个文件之间的具体差异示例:git diff 历史日志语法格式: git log查看版本库的提交历史日志示例:git log上述仅介绍了 git 的简单命令,实际使用情况远不止这些,更多详情请参考 git 入门教程 ...

原文：Git Reference协议：CC BY-NC-SA 4.0欢迎任何人参与和完善：一个人可以走的很快，但是一群人却可以走的更远。在线阅读ApacheCN 学习资源贡献指南请您勇敢地去翻译和改进翻译。虽然我们追求卓越，但我们并不要求您做到十全十美，因此请不要担心因为翻译上犯错——在大部分情况下，我们的服务器已经记录所有的翻译，因此您不必担心会因为您的失误遭到无法挽回的破坏。（改编自维基百科）贡献指南目录gitgit-configgit-helpgit-initgit-clonegit-addgit-statusgit-diffgit-commitgit-resetgit-rmgit-mvgit-branchgit-checkoutgit-mergegit-mergetoolgit-loggit-stashgit-taggit-worktreegit-fetchgit-pullgit-pushgit-remotegit-submodulegit-showgit-loggit-shortloggit-describegit-applygit-cherry-pickgit-rebasegit-revertgit-bisectgit-blamegit-grepgitattributesgiteverydaygitglossarygithooksgitignoregitmodulesgitrevisionsgittutorialgitworkflowsgit-amgit-format-patchgit-send-emailgit-request-pullgit-svngit-fast-importgit-cleangit-gcgit-fsckgit-refloggit-filter-branchgit-instawebgit-archivegit-bundlegit-daemongit-update-server-infogit-cat-filegit-check-ignoregit-checkout-indexgit-commit-treegit-count-objectsgit-diff-indexgit-for-each-refgit-hash-objectgit-ls-filesgit-merge-basegit-read-treegit-rev-listgit-rev-parsegit-show-refgit-symbolic-refgit-update-indexgit-update-refgit-verify-packgit-write-tree联系方式负责人飞龙: 562826179其他认领翻译和项目进度-地址: https://github.com/apachecn/g…在我们的 apachecn/git-doc-zh github 上提 issue.发邮件到 Email: apachecn@163.com.在我们的 组织学习交流群 中联系群主/管理员即可.赞助我们

gitBook 是一个基于node.js的命令行工具,使用 github/git 和 markdown/asciiDoc 构建精美的电子书.gitbook 支持输出静态网页和电子书等多种格式,其中默认输出静态网页格式.gitbook 不仅支持本地构建电子书,而且可以托管在 gitbook 官网上,并享受在线发布和托管图书的便利,完整的文档请参考 gitbook 新版文档(需FQ)或 gitbook 旧版文档(不需FQ)适用场景不仅适用于软件说明文档的发布更新,同样适用于文本文档的连载更新.既适合具有一定编程经验的软件开发从业者,也适用于不满足传统书写方式的文学创作者.简而言之,gitbook 可以条理清晰地整理出零碎知识,打造专属你自己的电子书,漂亮的主题,丰富的插件让你的知识变得从此与众不同!git + markdown = gitbook,其中 git 可以管理书籍内容的变更,并将其托管到云端实现团队协作,而 markdown 简洁的语法特点,使得我们不必关心布局排版问题,专注创作,重拾写作乐趣!如果你还不了解 git 和 markdown 相关知识,赶紧去学习 markdown 快速入门 和 git 入门教程 吧!先睹为快gitbook 教程gitbook 官网gitbook 文档参考文档gitbook 官网(新)gitbook 官网(旧)gitbook 文档(新)gitbook 文档(旧)git 官网github 官网gitbook 新版需要FQ,旧版不需要FQ

git使用的一般流程此贴记录一下我目前所在公司使用git的一些流程，因为我不是项目经理，所以只熟悉开发过程中的一些流程，开发完毕后的升级发布这些流程只了解过几次，也不熟，就不写了。初始化首先新建一个仓库之后，仓库自带master分支.基于master分支建立一个dev分支所有的开发人员自己再基于dev分支建立个人的开发分支开发者只能在自己的分支上开发开发者需要合并代码的时候本地保存储藏，切换的dev拉取最新的代码切换回自己的开发分支，并把dev的合并到自己的分支应用储藏，有冲突的话要先解决掉把自己本地的代码提交到自己线上的分支将自己线上的分支合并到线上的dev分支，流程差不多就好了git常用命令保存储藏git stash push -m “备注”;切换到某个分支git checkout 分支名获取分支信息git fetch -v拉取最新代码git pull从哪个分支合并代码到当前分支git merge 分支名提交代码git push

备忘录[译]创建 | Create克隆一个已存在的仓库 | Clone an existing repositorygit clone git@github.com:snowdreams1006/snowdreams1006.github.io.git创建一个新的本地仓库 | Create a new local repositorygit init 本地更改 | Local Changes工作目录中已更改文件 | Changed files in your working directorygit status已追踪文件的更改 | Changes to tracked filesgit diff 添加当前全部更改到下次提交版本 | Add all current changes to next commitgit add . 添加文件中某些更改到下次提交版本 | Add some changes in <file> to next commitgit add -p <file>提交已追踪文件的全部本地更改 | Commit all local changes in tracked filesgit commit -a提交上一次暂存区更改 | Commit previously staged changesgit commit 更改上次提交 | Change the last commit没有更改已发布的提交 | Don’t amend publishd commits!git commit –amend提交历史 | Commit history显示全部提交,以最新的开头 | Show all commits,starting with newestgit log显示某个文件一段时间内的更改 | Show changes over time for a specific filegit log -p <file>某文件是谁在什么时候更改了什么内容 | Who changed what and when in <file>git blame <file>分支和标签 | Branches & Tags列出全部已存在的分支 | List all existing branchesgit branch -av切换到 HEAD 分支 | Switch HEAD branchgit checkout <branch>基于当前 HEAD 创建新分支 | Create a new branch based on your curent HEADgit branch <new-branch>基于远程分支创建新的正在追踪分支 | Create a new tracking branch based on a remote branchgit checkout –track <remote/branch>删除一个本地分支 | Delete a local branchgit branch -d <branch>为当前提交打上标签 | Make the current commit with a taggit tag <tag-name>更新和发布 | Update & Publish列出当前全部已配置的远程仓库 | List all currently configured remotesgit remote -v显示远程仓库信息 | Show information about a remotegit remote show <remote>添加<remote>的远程仓库 | Add new remote repository named <remote>git remote add <shortname> <url>下载来自<remote>远程仓库的所有更改但是不合并到 HEAD | Download all changes from <remote> but don’t integrate into HEADgit fetch <remote>下载来自<remote>远程仓库指定分支的所有更改并且自动合并到 HEAD | Download changes and directly merge/integrate into HEADgit pull <remote> <branch>在<remote>远程仓库上发布本地更改 | Publish local changes on a remotegit push <remote> <branch>在<remote>远程仓库上删除分支 | Delete a branch on the branchgit branch -dr <remote/branch>发布你的标签 | Publish your tagsgit push –tags合并和变基 | MERGE & REBASE合并指定分支到你的 HEAD | Merge <branch> into your current HEADgit merge <branch>变基到当前HEAD | Rebase your current HEAD onto <branch>不要变基已发布的提交 | Don’t rebase published commits!git rebase <branch>取消变基 | Abort a rebasegit rebase –abort使用已配置的冲突工具去解决冲突 | Use your configured merge tool to solve conflictsgit mergetool使用编辑器手工解决冲突然后(解决之后)标记文件已解决冲突 | Use your editor to manually solve conflicts and (after resolving) mark file as resolvedgit add <resolved-file>git rm <resolved-file>撤销 | UNDO丢弃工作区全部更改 | Discard all local changes in your working directorygit reset –hard HEAD丢弃指定文件的本地更改 | Discard local changes in a specific filegit checkout HEAD <file>抵消一个提交(通过产生一个新的相反的提交) | Revert a commit (by producing a new commit with contrary changes)git revert <file>重置当前 HEAD 指针到上一个提交…然后丢弃自那以后的全部更改 | Reset your HEAD pointer to a previous commit … and discard all changes since thengit reset –hard <commit>…然后作为未缓存更改保存全部更改 | … and preserve all changes as unstaged changegit reset <commit>…然后保存未提交的本地更改 | … and preserve all changes as unstaged changegit reset –keep <commit>建议 | SUGGESTION提交相关更改 | COMMIT RELATED CHANGES提交应该是相关更改的包装,例如,修复两个不同的 bug 应该产生两个单独的提交.小的提交让其他开发者更容易理解此次更改,并且万一出错方便回滚.在暂存区这类工具以及暂存部分文件的能力下,git 很容易创建细粒度的提交.A commit should be a wrapper for related changes,For example,fixing two different bugs should produce two separete commits.Small commits make it easier for other developers to understand the changes and roll them back if something went wrong.With tools like the staging area and the ability to stage only parts of a file.Git makes it easy to create very granular commits.经常提交 | COMMIT OFTEN经常提交使得你的提交很小并且有助于仅提交相关更改.此外,这样允许你更频繁地和其他人分享你的代码,对于每个人来说更容器定期合并更改,避免了遭遇合并冲突.,很少的大提交,很少分享它们.相反很难解决冲突.Commiting often keeps your commits small and again helps you commit only related changes.Moreover,it allows you to share your code more frequently with others.That way it’s easier for everyone to integrate changes regularly and avoid having merge conflicts.Having few large commits and sharing them rarely.in contrast,makes it hard to solve conflicts.不要提交未完成工作 | DON’T COMMIT HALF-DONE WORK你应该仅提交已完成代码,这并不意外着提交前你不得不完成一个完整的,很大的功能分支.恰恰相反,将功能分支划分成很多逻辑块并且记得早一点,频繁些提交.如果仅仅是为了下班前仓库该有点什么就不要提交,如果你尝试提交仅仅是因为你需要一个干净的工作副本(检出分支,拉取更改),考虑使用 git 的 stash 特性. You should only commit code when it’s completed.This doesn’t mean you have to complete a whole ,large feature before commiting.Quite the contrary:split the feature’s implementatiion into logical chunks and remember to commit early and often.But don’t commit just to have something in the repository before leaving the ofice at the end of the day.If you’re tempted to commit just because you need a clean working copy (to check out a branch,pull in changes ,etc.) consider using Git’s <Stash> feature instead.提交前测试代码 | TEST CODE BEFORE YOU COMMIT抵制自以为已完成的提交.直接测试来确保它真的已完成并且没有副作用(显而易见的).当提交半成品到本地仓库时要求你不得不自我谅解,让你的代码进过测试对发布或者分享你的代码也很重要.Resist the temptation to commit something that you think is completed.Test it thoroughly to make sure it really is completed and has no side effect (as far as one can tell).While committing half-baked thing in your local repository only requires you to forgive yourself,having your code tested is even more important when it comes to publishing/sharing your code with others.编写代码提交信息 | WRITE CODE COMMIT MESSAGE对你的更改以简短总结进行描述(达到50字符作为准则).以包括空白行作为分割下述内容.提交信息体应该提供下述问题的详细答案:此次更改的动机是什么?和上一个实现有什么不同?使用必要的现在时语态(更改,不是已更改,或者变更)和使用形如 git merge 命令生成的信息保持一致.Begin your message with short summary of your changes(up to 50 characters as a guideline).Separate it from the following body by including a blank line.The body of your message should provide detailed answers to the following questions:What was the motivation for the change?How does it differ from the previous implementation?Use the imperative ,present tense(change,not changed or changes) to be consistent with generated messages from commands like git merge.版本控制不是一个备份系统 | VERSION CONTROL IS NOT A BACKUP SYSTEM在远程服务器存有文件的备份是版本控制系统的一个很好副作用.但是你不应该将VCS 视为一个备份系统.当做版本控制时,你应该注意语义化提交,而不是死记硬背文件.Having your files backed up on a remote server is a nice side effect of having a version control system.But you should not use your VCS like it was a backup system.When doing version control,you should pay attention to committing semantically(see related changes) - you shouldn’t just cram in files.利用分支 | USE BRANCHES分支是 git 最强大的特性之一,这不是偶然.从第一天开始快速而简单的分支就是一个核心需求.分支是帮助你避免弄混不同开发线的完美工具.在你的开发流程中应该广泛使用分支,像新功能,修复 bug,新想法…Branching is one of Git’s most powerful features-and this is not by accident:quick and easy branching was a central requirement from day one.Branches are the perfect tool to help you avoid mixing up different lines of development.You should use branches extensively in your development workflows:for new features,bug fixes,ideas…认同工作流 | AGREE ON A WORKFLOWGit 允许你从大量不同的工作流中选择一个:长期运行的分支,主题分支,合并或变,基工作流…具体选择哪一个取决于一系列因素:你的项目,你的总体开发和部署工作流和(可能是最重要的)你和你的团队的个人偏好.不论你选择哪一个去工作,你需要确保准守一个大家都认同的工作流.Git lets you pick from a lot of different workflows:long-running branches,topic branches,merge or rebase,git-flow…Which one you choose depends on a couple of factors:your project,your overall development and deployment workflows and (maybe most importantly ) on your and your teammate’s personal preferences.However you choose to work,just make sure to agree on a common workflow that everyone follows.帮助和文档 | HELP & DOCUMENTATION命令行下获取 git 帮助git help <command>Git help on the command linegit help <command>免费在线资源 | FREE ONELINE RESOURCEShttp://www.git-tower.com/learnhttp://rogerdudler.github.io/git-guide/http://www.git-scm.org/本文版权归原作者所有，翻译仅用于学习。 ...

下面列举一些git使用的小技巧，陆续会完善补充git-提取/合并某分支的部分文件git中可以使用merge合并分支内容，特殊情况下，我们可能需要将一个分支的部分文件合并到主分支，例如，某个分支的部分功能需要上线，而另一部分功能开发到一半，这时候，我们只需要提交需要上线的代码。当然你可以手动 copy 代码，但git能做到的我们就不要copy代码啦。git中可以使用checkout从某个分支中检出相应文件使用方法git checkout [branch] – [file name]git忽略文件git可以忽略那些特定的文件和文件夹，这些文件就不会被添加到git仓库了。只需要创建一个名为 .gitignore 然后列出那些你不希望 Git 跟踪的文件和文件夹。你还可以添加例外，通过使用感叹号(!)。.svnnode_modulesbower_components.idea.npm-debug.log!main.pyc清除本地分支本地其实有很多早就被删除的远程分支，可以用 git remote prune origin 全部清除掉，这样再 checkout 别的分支时就清晰多了基于远程分支创建分支git checkout -b feature origin/feature更新本地代码不知道是什么原因，本地代码更改之后git pull拉取远端代码获取不到最新的，但是显示Already up-to-date这个时候可以尝试 git status，来显示工作目录和暂存区的状态，再拉取代码git statusgit pullgit checkout 分支名 也可以把HEAD指向最新下载的版本git reset –hard origin/分支名如master 强制覆盖本地代码git fetch –all && git reset –hard origin/master && git pull大小写问题在当前项目中，早先创建并已经push到远程的文件及文件夹，将名称大小写更改后，git无法检测出更改。git config core.ignorecase false，关闭git忽略大小写配置，即可检测到大小写名称更改这样可能会产成两个文件，一个大写文件一个小写文件找出罪魁祸首当代码挂了的时候，使用git blame命令可以找出罪魁祸首。这个命令可以将文件中的每一行的作者、最新的变更提交和提交时间展示出来。git blame [file_name]查看提交内容仅仅想看最近谁有提交，以及提交的描述git log仅仅想看最后一次的提交git log -n 1想看到最近一次提交所有更改过的文件git log -n 1 –stat想看到最近一次提交所有更改的细节git log -n 1 -p客户端Git- GitTortoiseGit - TortoiseGitSourceTree - SourceTree编辑器的Git管理插件也很好用扩展阅读gitbook常用 Git 命令清单Git教程 ...

知识速查创建版本库初始化项目 git init从零开始创建项目示例git init 克隆项目 git clone将已有项目拷贝到本地示例git clone git@github.com:snowdreams1006/snowdreams1006.github.io.git添加文件 git add将新文件或已修改文件添加到缓存区示例git add README.md查看状态 git status查看当前文件是否和上次提交内容是否有修改示例git status README.md比较差异 git diff查看当前文件和上次提交内容的具体差异尚未缓存的修改: git diff查看已缓存修改: git diff –cached查看已缓存与未缓存的所有修改: git diff HEAD显示摘要而非整个差异: git diff –stat示例git diff README.md提交文件 git commit将缓存区内容添加到版本库示例git commit -m “remark"取消已缓存内容 git reset HEAD将缓存区内容添加到版本库示例git reset HEAD 删除文件 git rm <file>从暂存区中移除且不保留在工作目录: git rm <file>强制从暂存区中移除且不保留在工作目录: git rm -f <file>从暂存区中移除但保留工作目录: git rm –cached <file>示例git rm README.md移动文件 git mv <file_old> <file_new>移动或重命名文件,目录,软连接示例git mv README.md README_NEW.mdcommit push pull fetch merge 的区别与含义:git commit : 将本地修改过的文件提交到本地仓库中git push : 将本地仓库的最新版本推送到远程库中git pull : 从远程库获取最新版本到本地,并自动mergegit fetch : 从远程库获取最新版本到本地,不会自动mergegit merge : 将指定版本合并到当前分支替换本地改动丢弃当前文件修改内容,已添加到暂存区以及新文件都不会受到影响示例git checkout – <file>丢弃本地所有改动示例git reset –hard 分支管理创建分支 git branch <name>创建本地分支,但不自动切换新分支示例git branch dev切换分支 git checkout <name>切换到指定分支示例git checkout dev创建并切换分支 git checkout -b <name>创建本地分支并自动切换到新分支示例git checkout -b feature合并分支 git merge <name>将指定分支合并到当前分支示例git merge dev删除分支 git branch -d <name>删除指定分支示例git branch -d dev列出分支 git branch列出本地全部分支示例git branch提交日志 git log查看纳入版本库的提交日志示例git log标签管理创建标签 git tag -a <name>创建标签并提交备注示例git tag -a v1.0.0追加标签 git tag -a <name> <commit>追加标签并更新备注示例git tag -a v0.9.0 6ad8956bc09a6a62c731711eabe796690aa6471c删除标签 git tag -d <name>删除指定标签示例git tag -d v1.0.0查看标签 git show <name>查看指定标签示例git show v1.0.0列出标签 git tag列出本地全部标签示例git tag ...

git 私服搭建教程前几节我们的远程仓库使用的是 github 网站,托管项目大多是公开的,如果不想让任何人都能看到就需要收费,而且 github 网站毕竟在国外,访问速度太慢,基于上述两点原因,我们有必要搭建自己的 git 服务器.虽然我们能搭建基本的 git 服务器,但是想要做到 github 网站那种规模还不是目前能够探讨的,本节的主要目标是使用我们私有服务器对我提供类似于github的远程仓库托管服务,以下示例以centos 服务器为例说明:安装 git 服务运行以下命令安装 git 服务# 安装 git 相关依赖yum install curl-devel expat-devel gettext-devel openssl-devel zlib-devel perl-devel# 安装 gityum install git# 查看 git 版本git –version详情请参考安装 git配置 git 用户创建 git 用户组和 git 用户,以便对外提供 git 服务# 新增 git 用户组groupadd git# 新增 git 用户并归属于 git 用户组useradd git -g git收集 git 公钥回忆一下,在我们使用 github 网站时,我们是不是曾经将本地电脑生成的公钥~/.ssh/id_rsa.pub 复制到 Account -> Settings -> SSH and GPG keys -> New SSH key,而我们现在搭建的git 服务还是简单,但是这步骤必不可少,因此只能手动收集素有需要访问我们服务器的公钥文件.我们知道需要登录我们服务器的用户公钥一般是存放在~/.ssh/id_rsa.pub ,那当前服务器作为远程服务器将这些公钥存放到哪里呢?还记得上一步我们创建了 git 用户吗?因为 linux 系统支持多用户操作,而 git 用户就用于专门运行 git 服务,负责所有和 git 有关的事宜.因此,导入公钥文件的目录就是/home/git/.ssh/authorized_keys文件.一个用户公钥占用一行,几个用户就有几行.# 切换到 git 用户主目录cd /home/git/# 创建.ssh 目录mkdir .ssh# 赋予标准目录权限chmod 755 .ssh# 创建authorized_keys文件touch .ssh/authorized_keys# 赋予标签文件权限chmod 744 .ssh/authorized_keys初始化 git 仓库同样我们和github 网站类比,在 github 创建仓库时都会在当前账号下创建项目,完整的访问路径大概是这样的: git@github.com:snowdreams1006/git-demo.git,从中我们可以看出项目仓库都有一个前缀即命名空间,这和上一步操作是不是很类似,上一步收集 git 公钥时我们也有统一的目录,这次也不例外.假设 git 仓库存放目录在 /home/git/repos/,同样的先创建该目录并赋予响应权限.# 切换到 git 用户主目录cd /home/git/# 创建 repos 目录mkdir repos# 更改 repos 目录属主chown git:git repos/# 切换到 repos 目录cd repos# 初始化 git 仓库git init –bare git-demo.git# 更改 git-demo.git 仓库属主chown -R git:git git-demo.git经过上述操作,我们成功在远程服务器部署了 git 服务,并且创建了 git-demo 测试项目,实际访问路径大概是这样的git@snowdreams1006.cn:/home/git/repos/git-demo.git本地克隆远程仓库身份回到本地电脑,假设本地已搭建好 git 环境,并且生成的ssh 公钥上传到远程服务器,那么我们接下来就可以和之前远程服务器是 github 网站那样的方式开发我们的项目了,唯一不同的是,接下来我们推送的远程服务器均是我们刚搭建好的主机.需要做好心里准备,我们搭建的服务器还很简单,没有 github 网站那样可以直观操作远程仓库,但是这并不影响我们的 pull push merge 等操作哟!git clone git@snowdreams1006.cn:/home/git/repos/git-demo.gitgit-指的是 git 用户,snowdreams1006.cn-指的是远程主机域名或ip,/home/git/repos-指的是 git 仓库的目录,git-demo.git-指的是项目名称现在我们已经成功搭建好自己的 git私服了,是不是很简单呢?有没有对 git 和 github 进一步理解?欢迎大家一起探讨! ...

今天在git bash中使用cd命令进去文件夹时报错：谷歌得知：路径名或者变量中间有空格时，要用双引号括起来，不然会报错：bash: cd: too many arguments。改正后可以正常使用：

github 教程github 是一个基于 git 的代码托管平台,是平时工作学习的好帮手,学会如何用好 github 网站能够帮助我们更好分享代码或者与其他开发人员合作.注册 github 账号首先准备好邮箱和密码,然后在 github 官网注册新账号,和大多数网站类似的注册流程,唯一注意的是你要想好注册类型,针对个人用户来说,一般无外乎个人账号和项目账号两种,比如 snowdreams1006 就认为是个人账号,而这种 security-plus 认为是项目账号.其实这两种账号对于 github 来说是一样的,不像是个人账号同企业账号的差异那么大,那为什么称个人账号和项目账号呢?是因为,大多数个人开发者名下会有多款开源作品,这些作品既可以全部挂载在某一个开发者账号下面,也可以单独挂载某一个开发者账号下面,如果此时的账号名恰好是项目名岂不是清晰多了?因为个人刚开始可能并没多大名气,如果一个产品直接挂载在个人名下,那么这个产品很大程度上就依赖于个人名气了,所以不妨反过来,用产品说话,事实胜于雄辩,这种做法也是一种常用的宣传手段,很多个人开源产品正是这么做的!除此之外项目账号还有一个好处,利用 github 的静态网站托管服务可以免费快速搭建项目官网,只要创建一个snowdreams1006.github.io 的项目,那么这个项目就可以作为静态网站的源码项目了,访问 https://snowdreams1006.github.io 就能看到项目官网了!注意: snowdreams1006仅仅是笔者用户名,实际需要替换成读者的用户名配置 github既然项目已经托管到 github 网站,那本地如何访问到远程仓库呢?常用的方式有两种,一种是 https 方式,每次都需要输入密码,另外一种是 ssh 方式,只需要一次配置ssh 密钥对.这里我们重点介绍最常用也是最方便的第二种 ssh 方式访问 github ,大致思路是本地生成密钥对,然后将公钥上传给 github 表明身份,之后本地再次推送给远程仓库时,github 自然就能识别到我们身份了.第一步: 生成密钥对默认情况下,会在当前用户目录下生成一对密钥对.ssh-keygen -t rsa -C “youremail@example.com"这里的邮箱 youremail@example.com 需要填写自己的 github 邮箱,之后会提示输入路径和密码,一路回车采用默认值即可,运行结束后会在当前用户目录下生成一对密钥对,包括公钥和私钥.其中公钥可以发送给任何人,而私钥千万不可泄露.第二步: 复制公钥在当前用户根目录下打开 .ssh 目录,其中包括两个文件,一个是公钥 id_rsa.pub ,另一个是私钥 id_rsa,用记事本或者其他方式打开公钥文件,复制其中内容,准备粘贴到github 相关设置项.# 查看当前用户下的 ssh 目录ls ~/.ssh# 查看生成的公钥内容cat ~/.ssh/id_rsa.pub第三步: 设置 github回到 github,点击头像(Acount),选择设置(Settings),再选择左侧的 SSH and GPG keys,点击右侧的NEW SSH Key,然后填写标题(Title),最好是有意义的名称,比如youremail@example.com for github,密钥(Key)填写上一边生成的公钥,一般是以ssh-rsa 开头的一大串字符,最后保存(Add SSH Key).第四步: 验证 ssh利用 ssh 协议测试一下是否能够正常访问 github 网站,如果出现成功提示,那就证明我们的配置没问题.ssh -T git@github.com创建远程仓库登录 github 网站新建远程仓库(New Repository),例如git-demo,默认权限是公开的(public),也可以选择私有的(private),初始化 README.md 文件和 .gitignore 文件以及选择开源协议这些都是可选的,视具体情况而定.刷新当前页面,应该能到看到已创建好的git-demo 项目,接下来准备将其克隆到本地电脑.克隆到本地仓库将远程项目克隆到本地工作空间,和之前本地仓库的开发流程一样,例如add commit status 等等,唯一不同的是,多了一步 push 命令,即本地仓库的最新版本需要推送给远程仓库中,只有这样其他小伙伴才能从远程仓库拉取最新版本,进而才能看到你的代码,因而打破各自为政局面,实现团队协同开发.# 克隆到本地仓库git clone git@github.com:snowdreams1006/git-demo.git# 切换到当前项目cd git-demo# 创建新文件touch test.txtecho “add test.txt” > test.txt# 添加文件到暂存区git add test.txt# 提交文件到本地仓库git commit -m “add test.txt”# 推送到远程仓库git push origin master提交完成后,登录 github 网站,刷新当前项目 git-demo ,应该能看到我们刚刚提交的新文件test.txt.添加仓库关联添加本地仓库和远程仓库之间关联,默认本地仓库分支名和远程仓库分支名相同git remote add origin2 git@github.com:snowdreams1006/git-demo.git查看远程仓库查看当前配置有哪些远程仓库git remote执行时加上-v 参数能够查看别名关联的具体地址,即 git remote -v下载远程仓库从远程仓库下载最新分支数据git fetch注意: 该命令并不会自动合并当前分支,如需要合并,需手动执行git merge 命令拉取远程仓库从远程仓库拉取最新分支数据,自动尝试合并到当前分支,如有冲突,需先解决冲突再合并到当前分支.git pullgit pull 相当于 git fetch + git merge推送远程分支将本地最新版本推送到远程仓库git push origin master以上命令将本地 master 分支推送到 origin 远程仓库的 master 分支删除远程仓库git remote rm origin ...

忽略文件"并不是所有的牛奶都叫特仑苏",在版本控制系统中也有相似的表达,那就是"并不是所有的文件都需要提交".有的是因为没必要提交,比如日志文件,系统缓存文件等,有的是因为不能提交,比如个人隐私文件,付费文档等.正常来说,这些文件都是不应该被提交到版本库,倘若一不留神提交到版本库,要么泄露机密信息,要是造成经济损失,要么对团队其他人工作造成不便.有鉴于此,我们应该寻求一种机制来规避事故的发生,在 git 版本控制系统中一般有三种不同的解决方案.最常用也是最简单的当属 .gitignore 文件,不过先不要着急,我们先了解一下忽略原则和配置规则.忽略文件的基本原则忽略操作系统自动生成的文件,保持不同操作系统的纯粹性和整洁度.忽略工具软件自动生成的文件,避免因个性化配置而产生的工作障碍.忽略个人隐私配置文件,除非你愿意承担公开隐私所带来的潜在风险.目标: 只提交必要文件,忽略无用文件,尽可能考虑多种情况,不给他人制造麻烦.忽略文件的配置规则一行记录代表一条规则,配置规则仅针对尚未被跟踪的文件清单.# 忽略 *.a 文件*.a# 忽略 *.A 文件,但 somefile.A 除外..A!somefile.A# 忽略 *.b 和 *.B 文件.[bB]# 忽略 *.c 和 *.C 文件,但 somefile.C 除外..[cC]!somefile.C# 只忽略 somepath/ 目录(包括该目录下所有文件),但不忽略 somepath 文件somepath/# 只忽略 somepath/ 一级子目录下 *.txt,但不忽略 somepath/sub/*.txt 文件somepath/.txt# 忽略 somepath 文件和 somepath 目录somepath# 只忽略 somepath 文件,但不忽略 somepath/ 目录somepath!somepath/# 只忽略当前目录下的 somepath 文件和目录,但不忽略子目录的 somepath/somepath说明: # 开头表示注释,! 紧跟某规则之后表示增加例外情况在线示例和帮助文档提供两个不错的在线示例,可以参考下在什么场景应该忽略哪些文件以及如何编写忽略规则.https://www.gitignore.io/https://github.com/github/gitignore运行 git help ignore 命令查看帮助文档三种设置方式git 设置忽略文件有三种方式,如下:全局配置文件(~/.gitignore),执行 git config –global core.excludesfile ~/.gitignore 命令后适用于所有的版本库.远程配置文件($PWD/.gitignore),编辑 .gitignore 文件后适用于远程和本地版本库.本地配置文件($PWD/.git/info/exlude),编辑 $PWD/.git/info/exlude 文件后适用于本地版本库.最常用方式三种设置方式中,第二种最为常见,另外两种大致一样,重点在于配置文件如何编写.创建 .gitignore 文件参考在线示例以及基本语法编写自定义忽略规则# General.DS_Store.AppleDouble.LSOverride# Windows thumbnail cache filesThumbs.dbehthumbs.dbehthumbs_vista.db提交 .gitignore 文件忽略文件规则配置完毕后,需要将该文件提交到版本库,这样在其他电脑上也能应用相同的忽略规则.# 添加 .gitignore git add .gitignore# 提交 .gitignore git commit -m “add .gitignore”# 上传 .gitignoregit push origin master验证忽略效果新建 .gitignore 文件中已忽略的文件,运行 git status 命令,如果提示 working directory clean,那么说明忽略文件的配置已经生效,如果工作区不干净,很遗憾,忽略文件配置可能并未生效,需要检查下哪里配置错了.运行 git check-ignore 命令检查是哪个配置规则写错了,从而我们能够更正相应的配置规则. ...

问题最开始不知为啥突然git DeskTop出现认证错误，如下图，开始以为是不是登陆出问题了，于是重新登了一下，发现如下错误解决办法谷歌了一下，好像是钥匙串的问题当时没搞明白怎么处理，结果就把它给删了。之后找到官方文档，发现自己已经给删了，已经凉了。之后有想了一个其他的办法，也解决了问题解决方法如下：生成自己的公私钥对ssh-keygen -t rsa -C “Your Email Address” -f ‘Your Name’切换到目录中，复制自己的私钥cd ~/.sshcat id_rsa.pub3.进入GitHub -> setting ,新建一个ssh key。4.测试是否成功然后再打开原项目，试了一下，还是失败，又查了一下，要克隆ssh的项目才行原因感觉是因为上午在更改百度云提速的过程中，更改了文件，之后重启是动了钥匙串（只有在这动过钥匙串），导致出了些问题。

1、在.gitignore文件中还可以使用wildcard（某位同学称之为“野卡” 哈哈)通配符，例如，.log，去掉.gitignore同一文件夹中的所有后缀名为log的文件。GitHub上提供了一份常用的忽略规则，大家可以拿来参考，详见此处：https://gist.github.com/octoc…。2、如果.gitignore忽略规则创建于文件提交代码库之后，则.gitignore规则不会影响目前所提交的文件（不会自动把文件从服务器端删除掉）。你需要手动删除，用如下的方式：git rm –cached <FILENAME> -f <FILENAME>即你要移除的文件全名。git rm –cached <DIR> -r <DIR> 你要删除的文件夹.gitignore 文件示例：.iml.idea.ipr.iws*.diff*.patch*.bak.DS_Storenode_modules/node_modules2/.project.settingsnpm-debug.log.proj.svn/.swp*.swo*.logexamples/dist/yarn-error.logtest/unit/coverage.vscode

个人整理的一些常用的 Git 概念和命令集合，方便速查和快速解决某些场景下的问题，覆盖了日常开发和协同工作下的一部分场景，不只是命令行的介绍。欢迎关注语雀原文，持续更新！精简入门1、克隆仓库克隆仓库会下载仓库完整的文件、分支和历史记录。git clone [<options>] [–] <repo> [<dir>]# 克隆完整的仓库到 ./git-learning 目录下git clone git@github.com:x-cold/git-learning.git# 只克隆 dev 分支到 ./dev 目录下git clone -b dev git@github.com:x-cold/git-learning.git dev2、将文件变更记录写入到本地的索引库git add [<options>] [–] <pathspec>…# 添加当前目录下所有文件git add .# 添加部分文件git add src/ app/ index.js3、提交变更到工作区git commit [<options>] [–] <pathspec>…# 最普通的提交git commit -m “feat: support canvas”# 修改当前的 commit messagegit commit –amend# 重置当前的 commit author 和 messagegit commit –amend –reset-author 4、推送代码到远程仓库git push [<options>] [<repository> [<refspec>…]]# 提交本地仓库当前分支到远程仓库的 master 分支git push origin master# 提交本地仓库 dev 分支到远程的 master 分支git push origin master:dev聊聊设计图像来自维基百科Git 是一个分布式的版本控制工具，因此远程和本地可以视为两个独立的 Git 仓库。上图是一张经典的 Git 中的数据流与存储级别的介绍，其中储存级别主要包含几部分：工作区 (Working Files)，指的是我们时刻在编辑的文件的目录，通常来说我们修改文件都是在工作区体现的暂存区（Stage），暂存将本地的修改，然后提交到本地仓库本地仓库（Local）远程仓库（Remote）由此不难看出整体的数据流动，就是一条从：工作区 -> 暂存区 -> 本地仓库 -> 远程仓库 的双向数据流通道。常用命令git init创建一个空白的 git 仓库git initgit addgit add [<options>] [–] <pathspec>…git commitgit commit [<options>] [–] <pathspec>…git remoteremote 指的是本地的 git 仓库关联的远程 git 仓库。1、查看远程仓库信息git remote2、看远程仓库详细信息git remote -v3、删除远程仓库git remote remove <name># 移除名字为 origin 的远程仓库git remote remove origin4、添加远程仓库 git remote add [-t <branch>] [-m <master>] [-f] [–tags | –no-tags] [–mirror=<fetch|push>] <name> <url>git remote origin git@github.com:x-cold/git-learning.gitgit branch1、列出本地存在的分支git branch2、列出远程分支git branch -r3、列出本地和远程分支git branch -a4、创建本地分支git branch [branchName] (remoteBranch)# 基于远程仓库的 dev 分支，创建本地仓库的 feature/canvas 分支git branch feature/canvas dev5、分支重命名git branch [<options>] (-m | -M) [<old-branch>] <new-branch># 修改 feature/canvas 分支名为 feature/canvas2git branch -M feature/canvas feature/canvas26、删除本地分支git branch -d | -D [branchName]7、删除远程分支git branch [<options>] [-r] (-d | -D) <branch-name>.# 删除 feature/canvas2 分支git branch -d feature/canvas28、设置默认上游及分支git branch –set-upstream <localBranch> <remote>/<remoteBranch># 以后只需要在 dev 分支执行 git push (无需额外的参数) 就可以提交到 origin/devgit branch –set-upstream dev origin/devgit checkout检出分支: git checkout [<options>] <branch># 切换当前分支到 dev 分支git checkout dev# 基于当前分支创建 test 分支，并且将当前分支切换到 test 分支git checkout -b test除开用于分支切换，checkout 还可以用于恢复未添加到本地工作区，但是被修改过的文件。**# 将 index.js 恢复到当前 commit 的内容git checkout index.jsgit merge合并分支: git merge [<options>] [<commit>…]# 合并远程仓库的 master 分支到当前分支git merge origin/mastergit rebase变基，是一种常用且有风险的操作，会改变提交历史，谨慎使用！git rebase while(存在冲突) { git status 找到当前冲突文件，编辑解决冲突 git add -u git rebase –continue if( git rebase –abort ) break; }git cherry-pick魔法级的命令，cherry-pick 可以提取 N 个的提交记录，合入稳定版本的分支上。 git cherry-pick [<options>] <commit-ish>…# 挑选 371c2 单个提交记录，合入当前分支git cherry-pick 371c2# 挑选出 371c2 到 971209 的所有提交记录，并合入当前分支git cherry-pick 371c2…971209git push推送到远程仓库，同步本地仓库的提交历史到远程仓库git push [<options>] [<repository> [<refspec>…]]# 提交本地仓库当前分支到远程仓库的 master 分支git push origin master# 提交本地仓库 dev 分支到远程的 master 分支git push origin master:dev# 提交单个 taggit push origin publish/1.0.0# 提交所有 taggit push origin –tagsgit pull拉取远程分支，同步远程仓库的提交历史到本地仓库git pull [<options>] [<repository> [<refspec>…]]# 通常来说，默认的 pull 行为等同于 git fetch + git merge# 下面这行命令等同于 git fetch origin master && git merge origin/mastergit pull origin master# 也可以通过变基的方式来拉取代码，这样分支模型不容易受到影响# 下面这行命令等同于 git fetch origin master && git rebase origin/mastergit pull –rebase origin mastergit tag1、创建 taggit tag -a v1.1.0 -m ““2、查看 taggit tag3、推送到远程git push origin –tags4、删除本地 taggit tag -d v1.0.05、删除远程 taggit push origin :refs/tags/v1.0.0.git 仓库元数据每一个 git 的代码仓库目录下，都会有一个 .git 的文件夹，其中包含的重要文件包含以下：文件/文件夹含义 config*配置文件 description描述，仅供 Git Web 程序使用 HEAD当前被检出的分支 index暂存区信息 hooks/客户端或服务端的钩子脚本（hook scripts） info/全局性排除（global exclude）文件，不希望被记录在 .gitignore 文件中的忽略模式（ignored patterns） objects/所有数据内容 refs/数据（分支）的提交对象的指针 进阶技巧修改 commit 历史使用 git rebase 进行历史修改，假定修改最近 3 条历史，操作步骤如下：1、git rebase -i HEAD~3运行此命令会提供一个提交列表，如下所示，其中 commit 记录是时间逆序排列的；pick f7f3f6d changed my name a bitpick 310154e updated README formatting and added blamepick a5f4a0d added cat-file# Rebase 710f0f8..a5f4a0d onto 710f0f8## Commands:# p, pick = use commit# e, edit = use commit, but stop for amending# s, squash = use commit, but meld into previous commit## If you remove a line here THAT COMMIT WILL BE LOST.# However, if you remove everything, the rebase will be aborted.#2、编辑上述列表文件，在需要更改的 commit 前，将 pick 修改为 edit ，如果需要压缩，可设置为 squash 保存退出，进入到 rebase 流程；3、通过 git commit –amend –author 对历史记录依次修改和持续进行 rebase；添加指定文件git ls-files src/ | grep ‘.css$’ | xargs git add删除所有 commit 中的某些文件# 删除文件git filter-branch –force –index-filter ‘git rm –cached –ignore-unmatch -r build’ –prune-empty –tag-name-filter cat – –all# 触发 GCgit reflog expire –expire=now –all && git gc –prune=now –aggressive附录githug, 一个专门为 git 学习路径设计的游戏awesome-git-addons, git 命令行工具扩展的合集git-tips, 常用使用场景和技巧集合lazygit, 懒人专用的 git 命令行程序其他用途issue 评论gitment, github issue 社会化评论插件gittalk, github issue 社会化评论插件，感觉稍微好看一点点 ...

linux环境配置1 安装Javayum install java-1.8.0-openjdk.x86_642 安装mavenyum install maven3 安装gityum install git4 安装tomcat下载最新的tomcat包，放到/root目录下，运行tar zxvf tomcat-*.tgz5 安装运行Jenkins点击这里下载Jenkins最新的war包，并放到/root/apache-tomcat-7.0.86/webapps/目录下。6 运行命令 cd apache-tomcat-7.0.86/webapps/ 进入war包所在目录，运行命令nohup java -jar jenkins.war –httpPort=8080 & 启动Jenkins。8080为默认端口，如果和其他服务冲突可改变为其他端口7 浏览器访问 服务器地址:端口号（例如192.168.0.100:8080）即可访问JenkinsJenkins配置1 安装必需的插件Deploy to container Plugin; GitLab Plugin；Maven Integration2 配置jenkins工具环境配置jdk配置Git配置Maven3 新建任务，选择构建maven项目4 source Code Management选择Git需要先点击add添加一个账号，打开这个页面填写你在gitlab的账号密码即可选择刚添加的账号，下面的分支记得改成自己需要的5 勾选一下构建快照6 Build这个pom文件不用修改，下面的语句可添加也可不添加7 配置到这一步已经可以自动打包了，我们构建看一下第一次运行会下载很多jar包，等待下载完成即可，打包成功后如下图所示报错1 [ERROR] Failed to execute goal on project : Could not resolve dependencies for project 🫙1.0-SNAPSHOT: The following artifacts could not be resolved: com.alibaba:dubbo🫙2.8.4, com.cloopen:sms-rest-sdk🫙2.6.3, com.taobao.pamirs.schedule:tbschedule🫙3.3.3.2: Could not find artifact com.alibaba:dubbo🫙2.8.4 in central (http://jcenter.bintray.com)缺少对应的jar包，可以直接从其他测试环境下复制过来 ...

前情概要初识 git 时,我们就已经接触过 git 的基本配置,使用 git config 命令配置用户名和邮箱:# 配置当前项目(local)的用户名(snowdreams1006)git config –local user.name “snowdreams1006”# 配置当前项目(local)的邮箱(snowdreams1006@163.com)git config –local user.email “snowdreams1006@163.com"快速回忆一下配置的相关语法:# 查看默认全部配置: local&gt;global&gt;systemgit config –list# 查看当前项目配置,等同于 .git/config 文件git config –local –list# 查看当前用户配置,等同于 ~/.gitconfig 文件 或 ~/.config/git/config 文件git config –global –list# 查看当前系统配置,等同于 /etc/gitconfig 文件git config –system –listman git-config 查看帮助文档,git 的配置文件是普通文本,也可以直接编辑.高频配置总体来说,git 的配置项基本分为两类: 客户端和服务端.其中大部分属于客户端配置, 除非使用自己搭建私服,否则没机会手动配置服务端(第三方服务器基本都支持可视化配置,比如禁止强制推送等配置).alias 别名熟悉 linux 操作的小伙伴对 ll 这个命令可能再熟悉不过了,是 ls -l 的缩写,称之为别名.git 也支持别名,有个别名我们可以将常用的命令都缩短,大大降低出概率,提高工作效率.# git checkout 缩写成 git cogit config –global alias.co checkout# git commit 缩写成 git cigit config –global alias.ci commit# git branch 缩写成 git brgit config –global alias.br branch如此一来,以后再也不用担心打错字了,简化命令,懒人至上!core.editor 编辑器默认情况下,git 使用的是 $VISUAL 或 $EDITOR 配置的文本编辑器,如果没有设置,则调用 vi 编辑器创建和编辑文本信息.查看当前编辑器配置项:# 查看编辑器配置项: 若没配置过,则无内容输出,已配置过的话,会输出相应编辑器信息git config core.editor假设使用 sublime 作为默认编辑器,那么便可如下设置:# Mac 系统如下设置: 设置成自己的 Sublime 的安装路径git config –local core.editor “’/Applications/Sublime Text.app/Contents/SharedSupport/bin/subl’ -n -w”# Windows 系统如下设置: 设置成自己的 Sublime 的安装路径git config –local core.editor “‘F:\Sublime Text 3 sublime text.exe’ -n -w"此时再次查看编辑器配置项应该会输出刚才配置信息,接下来我们验证下编辑器的效果:查看提交历史,已经提交成功(之前备注信息是在命令行中直接输入的,而现在是在编辑器中编辑)$ git log –pretty=oneline –abbrev-commit43fa8aa (HEAD -> master) validate sublime successfully00e16d7 ok2400f11 git config –local core.editor “’/Applications/Sublime Text.app/Contents/SharedSupport/bin/subl’ -n -w"0d60cb8 ok8fe5aba (origin/master, origin/HEAD) Merge branch ‘master’ of github.com:snowdreams1006/git-demo$ 如果只是输入简单备注,根本用不到编辑器,若提交备注有格式化要求时再手动输入就显得力不从心了!core.template 提交模板如果你需要格式化提交备注,那么这种情况下模板文件最好不过了,和自定义的编辑器一起搭配,这样就能约束自己和他人按照既定格式规范填写提交备注,方便以后统一管理.查看当前提交模板配置:git config commit.template假设你在当前项目下创建 commit-template.txt 模板文件,内容如下:# This is commit template# snowdreams1006 # git-demo将编辑好的模板文件设置成提交默认信息,需要如下设置:git config –local commit.template commiit-template.txt此时再次运行 git config commit.template 查看已配置提交模板,现在看一下实际效果:查看提交历史,当然也提交成功啦,可根据实际需求定制适合自己的提交模板.$ git log –abbrev-commitcommit a2ca3f0 (HEAD -> master)Author: snowdreams1006 <snowdreams1006@163.com>Date: Wed Mar 27 16:22:18 2019 +0800 ok myself yescommit 43fa8aaAuthor: snowdreams1006 <snowdreams1006@163.com>Date: Wed Mar 27 14:58:36 2019 +0800 validate sublime successfullycommit 00e16d7Author: snowdreams1006 <snowdreams1006@163.com>Date: Wed Mar 27 14:56:20 2019 +0800 okcommit 2400f11git 还支持其他配置,暂时不一一介绍了,详情请参考在线帮助文档: man git-config ...

“春风得意马蹄疾,一日看尽长安花”,对于项目也是如此,最值得期待的恐怕就要数新版本发布的时刻了吧?每当发布新版本时要么是版本号命名(比如v0.0.1)或者代号命名(比如Chelsea),不管怎么说这种里程碑阶段总是要留下些许纪念意义.既然想要纪念这种特殊的历史时刻,自然是希望它能够固定下来,不要发生随意移动,产生不可预期后果.这种需求其实和我们前面说的分支概念很相似,均是源于特殊的版本号,逐渐收集起一系列版本,最终形成一条相对独立的历史线,但分支并不是实现里程碑概念的最佳选择,为什么?分支适合多人协作开发时互不影响,适当时机主动合并他人工作成果这种模式,而这种模式是由不同的功能模块进行驱动的,正所谓"天下大势分久必合,合久必分",当功能模块开发完毕后自然也就没有分支存在的必要性,更何况分支在收集版本的过程中会一直移动,并没有特殊的固定版本,显然分支不是最佳选择!但是,分支确定一定程度上和里程碑概念很相似,源于特定版本,自主命名,收集版本等,那么何必重头再来,为何不复用已有概念呢?实际上,git 中的标签(tag) 就是实现里程碑概念的方式,它可以永久性指向特定的提交并将命名,然后就可以将其理解成分支一样引用了!但标签(tag)不是分支(branch),标签是一个点的话,分支就是若干点连接而成的线,标签是静态的,分支是动态的,标签是只读的,分只是可读可写的.创建标签 git tag <tag># 方式一: 默认 HEAD 指向的版本git tag v0.0.1# 方式二: 指定 commit_id 表示的版本git tag v0.0.2 f971647# 方式三: 指定 commit_id 表示的版本,同时创建标签说明信息git tag -a v0.0.3 -m “v0.0.3” f971647列出标签 git taggit tag 显示标签 git show <tag>git show v0.0.1删除标签 git tag -d <tag>git tag -d v0.0.1推送标签 git push origin <tag>git push origin v0.0.1推送全部标签 git push origin –tagsgit push origin –tags删除远程标签 git tag -d <tag> git push origin :refs/tags/<tag># 删除本地标签 git tag -d v0.0.1# 推送删除标签(删除也是推送)git push origin :refs/tags/v0.0.1 ...

介绍为了找工作，花了七八天完成了自己的线上简历，结果发现并没有人来看这东西。说实话，这个是自己的第一个前后端项目，自我感觉还好，结果根本没人在意，一定是我做得太差，那就得好好改这个项目，增加功能。新增的下载简历效果图：广告：Github 地址三个月工作经验找前端工作规范化在开始动工之前，需要考虑自己做什么了，没有接触大公司的规范的开发流程，那也得自己编一个出来。如果有了解如何进行规范化开发的，希望能够在下方评论处给予我一些参考链接 创建 Issue想一下目前要做的事情，提上对应的 Issue，再加上对应的标签 TODO 、Feature；为这个功能找到处理者；将其添加到对应的 看板修改看板将所有的需求添加至 To do，再将要立即处理的移至 In progress创建分支准备采用 Github Flow 的工作流，首先创建一个分支，在克隆到本地git branch -av# 创建本地分支并建立关联git checkout -b feature/download_pdf origin/feature/download_pdf 功能开发安装依赖选取的是想法1，利用 canvas 来实现，安装相关的依赖npm i html2canvas -Snpm i jspdf -S注册功能这个功能将会被注册为全局的插件进行调用，按照习惯，将其放入 plugins 文件夹下，引入依赖，注册一套走起：// 创建插件 pdf.js// 引入依赖import Vue from “vue”;import html2canvas from “html2canvas”;import jspdf from “jspdf”;const PDF = {};// eslint-disable-next-line no-unused-varsPDF.install = function(Vue, options) { Vue.prototype.$pdf = function() { // eslint-disable-next-line no-console console.log(“hello pdf”); };};Vue.use(PDF);export default PDF;// 在 main.js 中注册插件import “./plugins/pdf”;// 在对应的地方触发方法this.$pdf(); // hello world转为 Canvas首先需将 HTML 转为 Canvas，看一下 html2canvas 是怎么处理的：很简单的语法，获取 DOM 就可以了。增加 ref 属性<share-page v-if="!shareLoading" ref=“pdfPage”></share-page>将 DOM 传递到 触发事件中<script>export default { methods: { download() { this.$pdf(this.$refs.pdfPage.$el); } } }</script>测试 DOM 结果Vue.prototype.$pdf = function(dom) { // eslint-disable-next-line no-console console.log(dom); // 得到期望结果};使用 html2canvasVue.prototype.$pdf = function(dom) { html2canvas(dom).then(canvas => { dom.appendChild(canvas); });};前往页面查看，可以得到一个完美效果的 Canvas打印为 PDF接下来是处理成 pdf，看一下官网它是怎么处理的：看起来很简单，提供一张图片（base64），然后就可以生成了。我们知道 canvas 是可以转为 图片（base64） 的，示例中给的图片格式是 jpeg，所以 canvas 也处理为 jpeg ：html2canvas(dom).then(canvas => { const jpeg = canvas.toDataURL(“image/jpeg”); const doc = new JsPDF(); doc.setFontSize(40); doc.text(35, 25, “简历”); doc.addImage(jpeg, “JPEG”, 15, 40, 180, 160); doc.save(“简历”);});好了，测试一下结果吧：简历是生成了，但是未免有些不对劲，看一下 文档 重新搞吧：html2canvas(dom).then(canvas => { const [AWidth, AHeight] = [595.28, 841.89]; // a4 const { width: CWidth, height: CHeight } = canvas; const PWidth = AWidth; const PHeight = (AWidth / CWidth) * CHeight; const jpeg = canvas.toDataURL(“image/jpeg”, 1.0); const doc = new JsPDF("", “pt”, “a4”); doc.addImage(jpeg, “JPEG”, 0, 0, PWidth, PHeight); doc.save(“简历”);});一顿操作发现简历长度超过 a4 纸的高度了，那就再给它增加一页，此处 参考：Vue.prototype.$pdf = function(dom, user) {html2canvas(dom).then(canvas => { const [AWidth, AHeight] = [595.28, 841.89]; // a4 let position = 0; let { width: CWidth, height: CHeight } = canvas; const PWidth = AWidth; const PHeight = (AWidth / CWidth) * CHeight; const jpeg = canvas.toDataURL(“image/jpeg”, 1.0); const doc = new JsPDF("", “pt”, “a4”); if (CHeight < PHeight) { doc.addImage(jpeg, “JPEG”, 0, 0, PWidth, PHeight); } else { while (CHeight > 0) { doc.addImage(jpeg, “JPEG”, 0, position, PWidth, PHeight); CHeight -= PHeight; position -= AHeight; if (CHeight > 0) { doc.addPage(); } } } doc.save(user);});好了，大功告成，成功结果在介绍中展示了。最后，提交，review，合并分支，发布代码。Bug仅能算作勉强完成，分割时会导致连续的内容分开，这个感觉会耗时很久……参考文档html2canvasjspdftoDataURL ...

在本文中，我们将讨论那些作为开发人员、数据科学家或产品经理应该知道的各种各样的Git命令。并且将使用Git查看、删除和整理。此外，我们还将介绍如何使用Bash别名和Git编辑器配置转义Vim和节省时间的方法。如果你不熟悉基本的git命令，那么在阅读本文之前，请查看我之前关于git工作流的文章。下面是需要了解的10个命令和它们的一些常见标志。每个命令都链接到该命令的Atlassian Bitbucket指南。查看信息首先，让我们来查看变化。git diff——查看所有本地文件更改。可以附加文件名，以仅显示一个文件的更改。git log——查看所有提交历史记录。也可以用于具有git log -p my_file的文件。输入q退出。git blame my_file——查看谁更改了my_file中的内容和时间。git reflog——显示本地存储库HEAD的更改日志。有助于找到遗失的文件。用git查看信息并不是很混乱。相比之下，Git提供了大量的选项来删除、撤消提交和文件更改。撤消信息git reset、git checkout和git revert用于撤消对存储库所做更改的影响。这些命令可能很难理解。git reset和git checkout可用于提交和单个文件。git revert仅用于提交级别。如果你只是处理尚未合并到协作远程工作中的本地提交，则可以使用这些命令中的任何一个。如果你正在协作工作，并且需要撤销在远程分支中的提交，那么就使用git revert。这些命令中的每一个都可以采用多种选择。 以下是常见用途：git reset –hard HEAD——丢弃自最近提交以来的阶段性和非阶段性更改。指定一个不同的提交，而不是HEAD来丢弃自提交以来的更改。——hard指定阶段性和非阶段性的更改。确保你不会放弃协作者所依赖的远程分支的提交!git checkout my_commit——放弃my_commit之后非阶段性的更改。HEAD通常用于my_commit，以放弃自最近一次提交以来对本地工作目录的更改。checkout最适合用于本地撤销。它不会打乱协作者所依赖的远程分支的提交历史记录!如果你将checkout与分支一起使用，而不是使用提交，则HEAD将切换到指定的分支，并更新工作目录以匹配。这是checkout命令的更常见用法。git revert my_commit——撤消my_commit中更改的效果。当撤消更改时，revert会进行新的提交。revert对于协作项目是安全的，因为它不会覆盖其他用户的分支所可能依赖的历史记录。有时你只想删除本地目录中的未跟踪文件。例如，你可能运行了一些代码，这些代码创建了许多你在repo中不需要的不同类型的文件。那么，你可以在一瞬间把它们清洗干净!git clean -n——删除本地工作目录中的未跟踪文件-n标志用于没有删除任何内容的干运行。使用-f标志来实际删除文件。使用-d标志删除未跟踪的目录。默认情况下，.gitignore未跟踪的文件不会被删除，但是可以更改此行为。现在你已经了解了在Git中撤消操作的工具，那么让我们来看看另外两个命令。整理信息git commit –amend——将阶段性的更改添加到最近的提交。如果没有执行暂存，此命令只允许你编辑最近的提交消息。只有在提交未集成到远程主分支时才使用此命令!git push my_remote –tags——将所有本地标记发送到远程repo。适合于版本控制更改。如果你正在使用python并对构建的包进行更改，bump2version将自动为你创建标记。一旦你推送了标记，就可以在发布中使用它们。这是我制作第一个OSS python包的指南。跟着我，确保你不会错过版本控制的部分！救命，我被困在Vim里出不来了!使用Git，你可能有时会发现自己陷入了Vim编辑器会话。例如，假设你尝试在没有提交消息的情况下提交，Vim将自动打开。如果你不了解Vim，这有点难缠——看看这个在Stack Overflow中超过4,000投票的回答，来了解如何摆脱它。以下是使用保存文件逃避Vim的四步计划：1.按i进入插入模式。2.在第一行输入提交消息。3.按下退出键-——Esc。4.输入:x。别忘了冒号。恭喜，你自由了！改变默认编辑器为了完全避免Vim，可以在Git中更改默认编辑器。这里是一些带有通用编辑器命令的文档。下面是修改我使用的编辑器Atom默认值的命令:假设你已经安装了Atom，现在可以解决其中的Git问题。太棒了！为Git命令创建快捷方式通过在.bash_profile中添加以下别名，为Git命令添加快捷方式。你可以根据自己的喜好调整Git命令的快捷方式。如果你没有.bash_profile，可以使用以下命令在macOS上创建一个：然后打开它：有关.bash_profile的更多信息，请点击这里。现在，当你在终端中输入gs时，它与输入git status相同。请注意，你可以在快捷方式之后在终端中输入其他标志。你也可以制作Git别名，但是那些要求你在快捷命令之前键入git。这就多此一举了。包装在本文中，你已经看到了一些关键的Git命令，并配置了环境以节省时间。现在你已经有了Git和GitHub的基础。准备好下一步了吗?查看这个Bitbucket Git教程，来了解更多。探索Git分支的交互式指南。分支可能不好理解，但绝对值得一看。去玩，去学习，向别人解释这些不同之处。我希望这篇介绍Git和GitHub的文章对你有用。如果可以，请在你最喜欢的社交媒体上分享，这样其他人也能找到它。我写的是如何有效地使用Python、Docker以及其他编程和数据科学工具。如果你对此感兴趣，请在这里阅读更多。本文作者：【方向】阅读原文本文为云栖社区原创内容，未经允许不得转载。

基于Gitee+Hexo搭建个人博客说到个人博客，我更倾心于GitHub Page方式的个人静态博客，虽然每次需要自己基于Markdown文档生成HTML页面，但是这种方式一是免费，二是可以完全自定义博客且木有广告链接，想用起来极为干净舒适！奈何由于国外的GitHub Page访问总是莫名龟速且不稳定，幸好我们有了国内对应的第一个开源代码托管平台码云：码云（https://gitee.com/），因而可以在国内搭建访问与SEO检索都优于GitHub的个人网站。由于自己刚接触个人网站不久，而且上周才勉强搭建起自己的个人小站。虽然网上有很多详细的教程，但是大多教程彼此借鉴严重，很多步骤只是标准化的回答，导致自己在实际搭建时遇到了不少看似不大，却很严重的“大坑”。作为记录整理，趁热打铁来梳理一下安装过程中遇到的“坑”，也希望可以为其他选择使用Gitee+Hexo搭建个人博客的亲们提供帮助。一、环境配置由于我们选择在Windows 10平台上使用Gitee+Hexo来搭建个人博客，且网站/博客本质上是一个资源目录，其中包含了显示的页面文本与调用的样式（CSS等）文件，因此我们需要首先在本地建立一个存储个人网站的目录，如命名为MyWebDir。接下来，我们就需要安装两个重要的环境，一个是提供版本克隆与下载跟踪的Git，一个是由文本文件生成HTML文件的Hexo框架，其中：node.js下载可以从其官方界面开始https://nodejs.org/zh-cn/Git下载则可以从其官方界面开始https://git-scm.com/上述安装下载后按照指示安装即可，安装成功在MyWeb中单击空白右键，应能弹出启动Git Bash Here的选项。二、Hexo的安装与基本命令接下来我们可以安装生成网站的关键——Hexo架构了，其主要信息和安装命令、主题等都可以从其官网轻松得到：https://hexo.io/zh-cn/为了安装Hexo，只需要在MyWeb目录中单击右键启动Git Bash Here，然后输入命令：npm install hexo-cli -g网上有很多其他的命令，建议一切以官网命令为依据，由于时间版本原因，很有可能未来的命令发生改变而失效。然后等待几分钟（取决于你的网速），完成后需要首先进行初始化在本地生成Hexo相关目录：hexo init然后就可以使用Hexo三连了，即我们最常用的三个主要命令（依旧在上述Git Bash命令端口中）：hexo clean # 清空已有hexo网站文件hexo generate(or g) # 依据网页文本与新的CSS样式生成新网站文件hexo server(or s) # 启动本地服务器，可以在localhost:4000查看网站修改效果依次运行上述三个命令，就可以在浏览器打开localhost:4000端口，查看对应网站界面效果，一般默认的是一个landscape主题，后期当提交新文章或者新的样式修改时，往往都是先从本地查看结果无误后再部署到Gitee Page。三、主题下载与安装Hexo官网上提供了丰富的主题可选，你只需要打开对应的界面（https://hexo.io/themes/）选择喜欢的，然后点击名称跳转到GitHub仓库选择下载或者克隆对应的zip文件到本地，并且解压到网站目录下的themes目录即可。下图中则是我网站中的主题文件，请注意网站的路径：然后接下来，你需要修改两个配置文件：你的网站根目录下的_config.yml文件，即网站配置文件；你选择的主题的自带配置文件_config.yml，即主题样式配置文件；网站配置文件会配置你网站的URL地址、博客名称以及与Gitee上传的方式等基本信息；而主题样式配置文件则会定义实际页面显示的美观效果、多媒体（声音视频等）以及评论等附加功能。四、网站配置文件修改关于网站配置文件修改很简单，但是并不容易，因为一不小心就会出现域名带来的访问错误，在开始修改网站配置文件前，我建议大家先去Gitee上注册登录新建一个仓库用来保存你未来展示的个人博客页面、样式等资源，关于名称，很多网上教程都说可以自定义，然后在配置文件中正确指定即可，然而这里自己遇到了第一个坑：坑一：新建仓库与Gitee不同名导致无法正确解析网站配置文件采用文本样式打开后，可以找到下面一段代码：# URL## If your site is put in a subdirectory, set url as ‘http://yoursite.com/child' and root as ‘/child/‘url: http://muqianzhi.gitee.io/root: /permalink: :year/:month/:day/:title/permalink_defaults:上述说明中提到可以自定义名称，只需要在root字段修改即可，然而这里有两个容易出问题的地方：你的URL并不是你所在仓库的地址，而应该是你启动仓库的Gitee Page服务后分配给你的网站静态域名，以我个人为例，仓库地址为：https://gitee.com/MuQianzhi/M…（我新建的网站名称与Gitee账号同名），而网站URL应为“服务–Gitee Page”启动/更新后显示的网站地址：https://muqianzhi.gitee.io你的网站目录当然可以和账户不同名，但是那样就需要按照文档说明修改root字段，自己当初定义的名称不同，结果导致域名莫名无法解析，总是无法正确访问网页，因此干脆像GitHub Page一样强制要求使用账号同名新建网站仓库，这样还获得了以账号名为特征的独有域名，一举两得！跳过了上面的坑，接下来需要制定网站采用的主题样式，这里也需要注意：主题文件解压缩后不要重命名，直接将主题文件名称复制后设置为网站主题，即# Extensions## Plugins: https://hexo.io/plugins/## Themes: https://hexo.io/themes/# theme: landscapetheme: hexo-theme-landscape然后需要再修改一次网站部署方式，即如何上传到Gitee上供大家访问呢？自己也遇到了第二个坑：坑二：Git部署目录不是仓库地址！修改代码：# Deployment## Docs: https://hexo.io/docs/deployment.htmldeploy: type: git repository: https://gitee.com/MuQianzhi/MuQianzhi.git branch: master注意上面的repository地址并不是仓库的地址，而是你下载/克隆项目时弹出的那个地址，如果使用git就选择SSH，如果选择HTTPS那么相应的type字段也要修改为https完成上述修改后，一般而言可以启动本地服务器（你还记得上面的hexo s么？），然后从localhost:4000访问查看即可。跳过了上面两个坑，后面就比较简单了，你需要仔细阅读主题文件下的README.md文件以根据主题特点实现自定制网站。在此之前，你还需要在网站的Git Bash中运行一次安装所有主题依赖插件包的命令：npm install五、Hexo博客中插入图片一般而言Markdown都提供插入外链图片的方式，然而由于各种网络传输问题，容易导致由此生成的静态网页中的图片无法成功加载，因此本文推荐一种适用于Hexo 3.0以上版本的简单插入图片的方式。首先修改网站配置文件中的代码：post_asset_folder: true然后在网站目录下运行Git Bash Here，执行命令hexo new ‘your article name’运行成功之后就会在网站下的E:MuQianzhi Blogsource_posts中分别生成对应的Markdown文件与同名空目录；你的博客文章直接在生成的.md文件中编辑，而引用的图片则以Markdown标准形式的形式进行，这里的图片路径需要注意要采用相对路径，即(注意需要将‘’转变为’/’)/your article name/picture’s name.png/jpg然后运行hexo 三连查看本地图片是否成功，之后运行hexo d部署到Gitee即可六、Gitee端的更新其实这也算一个小坑吧，一般而言理解一旦运行了hexo deploy(or d)应该就已经将新的网站文件（主要是网站目录下的public目录）上传到了Gitee，然而事实上上步之后直接访问网站URL会发现页面没有改变，原因在于：你、没有、更新！是的，对于免费Gitee用户而言，你会需要手动更新一下Gitee Page，然后才可以将修改真的“部署”到可访问的网站上。以上。七、末尾上述过程记录了一般采用Gitee+Hexo搭建个人博客的过程，除了跳过几个“坑”之外，还需要认真阅读主题目录下的README.md文件，以进一步修改页面的索引、标签、图片风格等具体样式。好了，到此为止，你已经有了一个初步的个人博客，剩下的是根据需要添加不同插件或者调整风格了。祝愿大家都能有一个属于自己的个人博客，感兴趣的朋友可以随时联系我，也可以访问我的个人网站 https://muqianzhi.gitee.io/ ...

Q: 如何快捷的对一个文件重命名?git mv [文件名] [新文件名]Q: 如何快捷的删除文件?git rm [文件名]Q: 如何修改最近一次Commit的Message?git commit –amendQ: 如何修改历史Commit的Message?git rebase -i [要修改Commit的父加密串] 例如：我的变更中发现c928292中的Message书写错误Q：如何合并某几次连续或非连续的Commit?git rebase -i [要修改Commit的父加密串] 例如：我需要将最近2次对index.html的修改进行合并这里主要是对rebase的操作，无论是修改commit的Message，还是合并连续和非连续的Commit，都是可以使用rebase命令来进行操作的，其中的不同在于要在对话框中执行的命令，具体的命令可以通过对话框中的信息可以查看Q：如何比较工作区和暂存区之间的差异?git diff – [路径1] [路径2] [路径3….]Q：如何比较工作区和本地仓库之间的差异?git diff HEAD – [路径1] [路径2] [路径3….]Q：如何比较暂存区和本地仓库之间的差异?git diff –cached HEAD – [路径1] [路径2] [路径3….]Q: 如何查看某次提交某个文件的内容?git cat-file -p [某次Commit的加密串]例如：我想查看合并后index.htm的文件内容任何一次commit信息中都会包含一个树装结构来存储此次Commit中文件的状态，其中blob类型就是具体的文件Q：如何使暂存区与本地仓库保持一致?git reset HEAD 此操作会将提交到暂存区的改变撤销到工作区Q：如何撤销工作区所做的改变?git checkout – [路径1] [路径2] [路径3….]Q: 如何让工作区，暂存区和本地仓库保持一致?git reset –hard HEADQ：如何将代码强制回退到某次Commit?git reset –hard [具体的commit的加密串]Q：当临时插新任务的时候，我们该怎么做?git stash#记录会以栈的方式进行存储当我们处理完新任务后，继续以前的开发需要执行以下命令git stash pop 或 git stash apply#二者的主要区别就是：后者仍然会保留存储的记录，以便多次使用Q：如何备份本地仓库?git clone [当前库所在的路径] [目标备份库所在的路径]

前言：一般写完代码之后，还要将各类参数注解写入API文档，方便后续进行对接和测试，这个过程通常都很麻烦，如果有工具可以读取代码注释直接生成API文档的话，那会十分方便。此前一直都是在使用eolinker的，但自从去年他们家“注释生成文档”的功能下线后，我就一直活在水深火热当中——真的不想写文档啊，真的好累啊。然而这两天上线后，突然发现这个功能重新上线了！必须给大家安利一波！官网地址：https://www.eolinker.com根据官方的解释，这个功能简单来说就是读取 gitlab（以前应该还能读本地代码） 的 php 代码（截至发文增加支持读取java，更方便了）注释生成 API 文档。下面是官方的操作介绍：1.先在EOLINKER新建项目，随后进入项目概况页，可以在概况页中找到“扫描代码注解生成文档”模块。2.在同步之前我们打开设置看下需要填写什么信息。总共是10个选项，我们来分别看下需要怎么填写：1.代码仓库类型，现在默认只有gitlab，在官方群问了他们的PM，后面应该还会支持github。2.代码仓库地址，gitlab有线上版本和用户自己搭建私有云版本，线上版本可以填写https://gitlab.com，如果是自己部署的gitlab写域名或者IP端口。3.项目ID，gitlab中新建项目后会有一个project ID，填入即可。4.访问私钥，通过gitlab的Access Tokens功能可获取，后面会详细介绍如何获取。5.需要扫描的分支，默认为master。我们也可以新建一个分支。6.需要扫描的API目录路径，建立一个目录作为API目录。7.需要扫描的数据结构目录路径，建立一个目录作为数据结构目录。8.目标语言，目前默认只有PHP，比较可惜只有一个语言，不过我跟他们客服聊天，说是后面更新的语言支持会增加java。9.注解格式，默认为Swagger 2.0，代码注释编写的格式可以按照下面的形式来写，或者参考官方文档http://zircote.com/swagger-ph…比如model的比如controller的10.数据同步方式，目前可选增量更新、全量更新、仅添加新的API三种形式。以上就是需要填写的全部信息。要正确填写这些信息，接下来我们就要转到gitlab进行设置。由于官方没有介绍过Gitlab，那还是由我先介绍下比较合适：gitLab 是一个用于仓库管理系统的开源项目，使用git作为代码管理工具，并在此基础上搭建起来的web服务。gitlab跟github有点类似，都是基于web的git仓库，关于注册gitlab新建账号如何操作的部分我就不多说了，但如果你已经有github账号的话，是可以用github账号登录gitLab的。1.首先要新建项目，这里我新建了一个名为demo code的project。2.新建后已经有一个master的分支，然后在分支下分别建立两个新的目录：我命名为controllers和models，一个作为API目录路径，一个作为数据结构目录路径。3.将写好的php代码上传至分别的目录。可以直接用命令行或者直接将文件上传。4.成功上传代码后，跟着就是获取密钥。在gitlab中，生成密钥需要用到Access Tokens功能。先进入设置页面，通过左边菜单中的Access Tokens功能，填写对应的项目名称，再根据需要，勾选开放的权限，看不懂也可以按照我下面的截图进行勾选，点击绿框后就可以获取个人的密钥了。如下图：5.进行到这一步，我们已经把所有的信息都拿到了，再回到EOLINKER将信息填入，请看下图，注意数据同步方式我选择的是增量更新。那我为什么会选择增量更新呢？而三种数据同步更新区别是什么呢？增量更新：判断已有API的详细信息，添加新的API信息。用注解的数据替换掉现有的数据。部分注解没有的数据，比如mock、参数值可能性、详细文档等等，均会保留。全量更新：在添加新的API的基础上，全量替换现有API内的信息，以注解的为准，不保留注解没有的数据。仅添加新的API：判断接口名称是否已经存在，不存在则插入。听起来很绕，我们来举个例子。Gitlab上的接口只有参数，而导入EOLINKER后会有mock、详细文档等数据。假如现在你的gitlab仓库有ABCD四个接口数据，在EOLINKER有A一个接口数据。下面举个例子介绍下三种数据同步更新的区别， GitLab中的接口只有参数，而导入 EOLINKER 后会有 mock、详细文档等数据。假如现在你的 GitLab 仓库有 ABCD 四个接口，在 EOLINKER 有 A 一个接口。采用“增量更新”后，EOLINKER 上将新增 BCD 三个接口；如果仓库A接口的数据有所更新，那么在保持原有本地A接口的 mock、详细文档数据的同时，本地亦将新增相应更新的数据；采用“全量更新”后，EOLINKER 上将有 ABCD 四个接口；此时本地A 接口所有数据都不保留，而会与仓库中A接口的数据保持一致；采用“仅添加新的 API”后，EOLINKER将以接口名称来判断是否需要添加新的API，因此EOLINKER上将新增 BCD 三个接口；即便 GitLab 上的参数已经改变，但本地原有的A接口数据不变；因此，无论是什么情况都推荐采用增量更新。不过即便你还是误操作了，EOLINKER都会自动生成API历史版本，方便我们回滚文档，操作失误也不怕了。1.根据官方的说明，在设置完成点击立即同步后，文档即会开始进行同步，而同步生成文档所需的时间，则根据代码注释的数据量来决定。2.API文档和对应的分组都被自动生成了，如下图。3.那我们就可以直接编辑修改文档了，实在是方便了很多。补充一句：按照他们的更新速度，目前也已经支持读取gitlab上java代码了，操作步骤跟读取php的步骤类似，这里就不展开说了，还不知道请回头再看一遍文章hhh。总结如果可以通过扫描代码注释自动生成API文档，写完代码注解后就不用再一条一条的写接口文档，现在又有一个理由可以不再使用swagger了。新增的这个功能可以减轻大部分不必要的工作量，虽然现在只能支持gitlab上的php代码和java代码，但后续肯定还会继续支持更多的平台和编程语言代码，持续使用起来将会更加方便和快捷，希望eolinker能够给我们带来更多的惊喜。官网地址：https://www.eolinker.com

本地仓库和远程仓库在本质上没有太大区别,只不过一个是本地电脑,一个是远程电脑.远程仓库不一定非得是 github 那种专门的"中央服务器",甚至局域网的另外一台电脑也可以充当"中央服务器"的角色,因为它存在的最初目的只是方便大家交换彼此的提交记录而已!所以本地仓库和远程仓库的基本行为应该是一致的,约定俗成的规定是远程仓库一般不直接参与日常开发工作,主要作为项目托管中心.某些自动化持续集成环境中也可能会直接操作远程仓库,这时远程仓库就真的和本地仓库没什么区别了!个人开发常用命令个人开发看重的是效率,同时兼顾下版本控制的话算是是锦上添花,git 的本地仓库是本地备份,而远程仓库则是网盘备份.git init : 初始化本地项目将本地项目初始化 git 项目,直观表现是在该项目同级目录下多了 .git 隐藏目录,其存储着 git 版本库相关信息.此后当前项目便具备了本地管理的能力,可以与 git 进行交互.git clone : 克隆远程项目同 git init 一样的作用,也是创建本地仓库,只不过 git init 是直接将本地项目作为本地仓库,而git clone 是将远程项目克隆到本地并作为本地仓库.由此可见,git clone 比 git init 多了一层远程仓库的概念.git add : 添加文件将工作区的提交记录添加到暂存区,暂存区是工作区和版本库交互的桥梁,暂存区积累到一定量的提交记录时可以批量提交到版本库,这一点暂存区有点像缓存.git commit : 提交文件将暂存区的版本提交到版本库,从而形成工作区->暂存区->版本库的基本链路,本地工作区的版本控制流程大致如此.git push : 推送文件如果是使用 git clone 命令克隆的本地项目,当工作到一定程度时可能需要将这部分工作成果推送到远程仓库,这时候使用 git push 命令完成本地版本的推送流程.如果是使用 git init 命令初始化的本地项目,可能没有远程仓库,自然也就不需要推送.如果后来创建了远程仓库,那么你自然是想要将本地仓库推送到远程仓库的,因此你需要准确告诉 git 你要推送到哪个远程仓库.使用 git remote add origin git@github.com:username/repos.git 命令添加远程仓库信息,这样就建立了本地仓库和远程仓库的关联,以后就可以正常推送到远程仓库了.团队开发常用命令团队开发注重的不仅是个人效率还有团队的整体进度,随着企业级开发的日趋复杂化,不再是一个人能够独立完成的,更何况时间也不允许慢慢完成,大多数公司采用的是人力换时间的方式,团队并行开发来缩短整个项目周期,这种复杂需求下正是 git 大展拳脚的好机会.项目整体采用并行开发模式,拆解成不同的功能模块,每个人负责各自模块,模块之间相对独立但也不排除存在交集的可能性.对于每一个个体开发者来说,既需要版本控制又需要团队交流.这时候分支的作用就凸显出来了.根据项目的业务特点将其拆解成不同的功能模块,这些功能模块分别代表不同的分支,而这些功能模块又组成了完整的项目,这就是主干和分支的关系.初始时项目是一个整体,中间拆解成不同功能模块,最后再合并成一个整—“分久必分合久必分”.git branch <branch> : 创建分支每一个独立的功能模块被定义成一个单独分支,创建分支的过程其实是拆解项目的过程,创建本地分支后就在分支上开发特有功能,不再关心其他功能分支.git checkout <branch> : 切换分支模块拆解完成并创建了相应的分支后,需要切换到既定分支上才能开展自己的工作.git merge <branch> : 合并分支没有绝对的独立,项目再怎么拆分也是整体的一部分,肯定需要和其他功能模块发生关系,某些情况下需要其他分支的工作成果合并到自己的本地仓库中,这样才能完成一次小规模的组装.可以预期的是,当这种组装足够多的时候,最终便会演变成项目的终极形态,形成一个整体.git fetch : 抓取远程分支合并目标分支首先需要能够获取到目标分支的提交记录,既然每个功能模块都是不同的项目成员负责开发的,也就不在我们电脑上,所以我们先要将目标分支下载到我们本地电脑,然后才能合并该分支到本地分支.git pull : 拉取远程分支"先下载目标分支再合并到本地分支,从而小规模组成更复杂更强大的功能",每一次的组装过程都需要两步操作者显然不符合懒人思维啊,git pull 就是这两步操作的简化命令,先下载再合并就是这么简单!本地和远程仓库的碰撞不论是个人开发还是团队开发,我们几乎习惯惯站在主动方的角度来思考问题,有没有想过当远程仓库接收到我们的git push 或 git pull 请求时,远程仓库发什么了什么改变,这种改变对本地仓库又有什么影响?远程仓库(远程电脑上的本地仓库)只是众多分布式电脑上本地仓库中的一员,说它特殊也很特殊,充当着"中央服务器"作用,其余人统一从这里下载或推送;说它普通也很普通,和本地电脑上的本地仓库没有什么不同,因为它随时可被任意电脑上的本地仓库所取代!揭开远程仓库的神秘面纱后,现在我们只需要将其视为普通的本地仓库一样对待即可,然而我们本地电脑上已经有了本地仓库,故而需要将远程仓库做一下简单标识区分(origin)称之为远程分支.先说说 git push 命令做了什么?对于本地来说,git 将本地仓库的指定分支推送到远程仓库的相应分支,同时更新了本地仓库的远程分支.对于远程来说,git 接收到本地仓库的推送请求时应该在相应分支上合并本地分支,同时更新远程仓库的相应分支.只要本地的指定分支成功推送到远程的相应分支时,对于本地来说,不论是指定分支还是远程分支(origin/master)都应该是最新状态,因为已经与服务器同步了.而远程接收到此次推送请求时,应该尝试合并此次推送请求,再更新自己的相应分支,远程合并完成后再通知本地此次推送结果,如此一来,三端同步,皆大欢喜!再讲讲 git pull 命令发生了什么?对于远程来说,接收到本地的拉取请求时,因为没有新版本需要处理,所以无需任何操作.对于本地来说,当远程仓库的相应分支下载到本地时应该更新远程分支状态,再尝试合并到本地的相应分支.git pull 命令或者说是 git fetch 命令是本地和远程通信的方式,所以 origin/master 会自动更新!小结本地仓库和远程仓库本质上没有太大区别, git fetch 是本地仓库和远程仓库之间的通信途径,本地仓库中的远程分支(origin/master)保存着它们之间最后一次的通信状态. ...

摘要：也许你在别的地方听说过Git。也许有人告诉过你，Git只适合软件开发人员。如果你是数据科学家，那么Git其实对你很重要。本文作者希望能够通过经验分享让你了解Git的重要性，以及如何在你的数据科学工作中使用它。什么是Git？Git是一个分布式版本控制系统，用于在软件开发期间跟踪源代码的更改。看看维基百科给出的这个定义，好像Git专门是为软件开发人员而设计的。实际上，Git是当今世界上使用最广泛的现代版本控制系统，它是以分布式的协作方式为项目（开源或商业）做出了伟大的贡献。除了分布式版本控制系统之外，Git的还考虑了性能、安全性和灵活性。现在你已经了解了Git是什么，但是你脑海中的问题可能是，“如果我是做数据科学项目的人，它与我的工作有什么关系？”以前我也一样不能理解Git的重要性，直到我开始在现实工作环境中，我才发现它时如此重要！为什么是Git？我们来谈谈为什么？一年前，我决定学习Git。我在Github上分享并发布了我的代码，这是我在CERN的论文项目。虽然很难理解Git中常用的术语（git-add、commit、push、pull等），但我知道这在数据科学领域很重要，这使我的数据科学工作比以往任何时候都更加充实。所以我保持学习状态，并坚持“committing”。当我加入我目前的公司时，我在Git方面的经验就派上了用场，因为Git是跨不同团队进行代码开发和协作的主要方式。更重要的是，当你的组织遵循敏捷软件开发框架时，Git尤其有用，在该框架中，Git的分布式版本控制使整个开发工作流更加高效、快速且易于适应变化。那么什么是版本控制呢？版本控制是一个系统记录一个文件或一组文件随时间的变化，以便你以后可以调用特定的版本。比如说，你是一个数据科学家，与一个团队合作，在这个团队中你和另一个数据科学家在构建机器学习模型的时候，对同一个特征进行工作。如果你对该特征做了一些更改并上传到远程存储库，并且这些更改与主分支合并，那么你的项目现在变成了1.1版本。另一位数据科学家也对版本1.1的相同功能进行了一些更改，新的更改现在与主分支合并。模型就变成1.2版本。在任何时候，如果你的团队发现版本1.2在发布期间有一些错误，他们随时可以调用以前的版本1.1，这就是版本控制的美妙之处。作为数据科学家如何使用Git？我们已经讨论过什么是Git及其重要性。现在的问题归结为：作为数据科学家如何使用Git？作为数据科学家，你不需要成为一个Git领域的专家。关键是要理解Git技术的工作流程以及如何在日常工作中使用Git。准确地说，我在这里使用的是Git Feature Branch Workflow，它通常被开源和商业项目使用。如果你想更多地了解这里使用的术语，点击这里进行了解。Git Feature Branch WorkflowFeature Branch Workflow像一个中央存储库，master分支代表正式的项目历史记录。开发人员每次开始处理一个新特性时，都会创建一个新的分支，而不是直接提交到他们的本地主分支上。新的分支可以（也应该）推送到中央存储库。在这种情况下，可以在不修改master分支的情况下与其他开发人员共享一个该分支。在开始执行任何操作之前，请键入git remote -v以确保工作区指向要使用的远程存储库。1、从主分支开始，创建一个新分支git checkout mastergit pullgit checkout -b branch-name如果总是维护和更新主分支，则切换到本地主分支，并将最新的提交和代码提取到本地主分支。假设你希望创建一个本地分支，向代码中添加一个新功能，并稍后上传到远程存储库。一旦你将最新的代码更新到本地master分支，我们就创建并checkout出一个名为branch-name的新分支，所有的更改都将在此本地分支上进行。这意味着你本地的master分支不会受到任何影响。2、更新、添加、提交并将更改推送到远程存储库git statusgit add <your-files>git commit -m ‘your message’git push -u origin branch-name上面我们做了很多操作，让我们详细了解它。一旦发生了一些更新，就将新的操作add到本地分支，并且希望将该操作上传到远程分支，以便合并到远程主分支。git status将输出你对文件的所有更改（跟踪或未跟踪）。在使用git commit-m“your message”提交消息更改之前，你将使用git add <your files>决定要暂存哪些文件。在此阶段，你的更改仅显示在本地分支中。为了使你的更改显示在BitBucket上的远程分支中，你需要使用git push -u origin branch-name命令进行提交。此命令将该分支推送到中央存储库，并且-u表示将其添加为远程跟踪分支。在设置了跟踪分支之后，可以在没有任何参数的情况下调用git push，以自动将新的功能分支推送到BitBucket上的中央存储库。3、创建pull请求现在你已经成功地添加了一个新功能并推送到远程分支。你为自己的贡献感到骄傲，你希望在将远程分支与远程主分支合并之前得到团队成员的反馈。在该分支合并到主分支之前，让其他团队成员有机会对其进行审查。你可以在BitBucket上创建pull请求。现在，你的团队成员已经查看了你的代码，并决定在代码可以合并到主代码库-master分支之前，需要你进行一些其他更改。git statusgit add <your-files>git commit -m ‘your message’git push现在，你可以按照与之前相同的步骤进行更改、提交并最终将更新推送到中央存储库。一旦使用了git push，你的更新将自动显示在pull请求中。如果其他人已将目标更改为你所接触的同一代码，则会发生合并冲突，这在工作中很常见。你可以在这里看到如何解决合并冲突。一旦一切顺利完成，这些功能将会合并到master分支中。当我第一次开始学习Git时，我感到非常沮丧，因为我仍然没有真正理解工作流。这也是写这篇文章的主要原因之一，它真正分解并在更高层次的理解上向你解释工作流程。因为我相信，对工作流程中发生的事情有一个清晰的了解将使学习过程更加有效。本文作者：【方向】阅读原文本文为云栖社区原创内容，未经允许不得转载。

一、GitLab 安装1.1 准备工作1.1.1 关闭防火墙关闭防火墙命令：iptables -F查看防火墙命令：iptables -L1.1.2 关闭SELinuxsed -i ’s/SELINUX=enforcing/SELINUX=disabled/g’ /etc/selinux/configsetenforce 01.1.3 关闭NetworkManagersystemctl disable NetworkManager1.1.4 安装GetLab依赖包yum install -y curl policycoreutils policycoreutils-python openssh-server openssh-clients postfix 然后执行：systemctl restart postfix如果出现以下错误：Job for postfix.service failed because the control process exited with error code. See “systemctl status postfix.service” and “journalctl -xe” for details.修改 vim /etc/postfix/main.cf 以下内容 inet_protocols = ipv4 inet_interfaces = all 执行命令：systemctl enable postfix 检查是否启动： ps -ef | grep postfix1.1.5 启动sshd查看是sshd 是否启动: ps -ef | grep sshd如果未启动执行以下命令。执行命令：systemctl enable sshd执行命令：systemctl start sshd1.2 GitLab 下载1.2.1下载地址wget https://mirrors.tuna.tsinghua.edu.cn/gitlab-ce/yum/el7/gitlab-ce-11.5.3-ce.0.el7.x86_64.rpm1.2.2 解压rpm -ivh gitlab-ce-11.5.3-ce.0.el7.x86_64.rpm二、GitLab 配置2.1 配置文件路径vim /etc/gitlab/gitlab.rb 文件2.2 配置域名地址填写域名地址2.3 修改Git库SSH链接默认端口号2.4 邮件服务器配置 本示例参数配置为阿里云企业邮箱的配置2.5 修改Git库HTTP链接默认端口号2.5.1 文件路径vim /opt/gitlab/embedded/service/gitlab-rails/config/gitlab.yml 2.5.2 修改内容修改完重启： gitlab-ctl restart注意：GitLab启动后才可执行此操作修改端口，不然提前修改会被配置文件覆盖！！！三、GitLab命令3.1 GitLab 启动配置文件配好后，先加载配置，第一次加载会比较慢。加载配置命令：gitlab-ctl reconfigure当加载完配置，启动GitLab。启动Gitlab命令：gitlab-ctl start 第一次打开Gitlab 网站会让你设置root账号密码。3.2 GitLab常用命令加载配置文件命令：gitlab-ctl reconfigure启动GitLab命令：gitlab-ctl start重启GitLab命令：gitlab-ctl restart停止GitLab命令：gitlab-ctl stop查看GitLab服务状态：gitlab-ctl status查看GitLab版本号：head -1 /opt/gitlab/version-manifest.txt3.3 GitLab 日志查看日志命令：gitlab-ctl tail四、GitLab账户配置SSH密钥4.1 本地密钥生成密钥生成命令：ssh-keygen -t rsa -C “your.email@example.com” -b 4096说明：-b 4096： b是bit的缩写 4096是密钥的长度，最小768位 ，默认2048位4.2 查看本地密钥id_rsa 是私钥，id_rsa.pub 是公钥，Linux 和Windonws文件路径分别为：Linux：Windonws：4.3 配置密钥返回GitLab项目库，复制git库SSH链接。使用git克隆命令,用ssh下载项目。五、GitLab 汉化5.1 下载最新的汉化包git clone https://gitlab.com/xhang/gitlab.git如果要下载指定版本的汉化包，需要加上版本号。例：下载11.0.6，命令如下：git clone https://gitlab.com/xhang/gitlab.git -b v11.0.6-zh在汉化之前要先停止GitLab ，命令 ：gitlab-ctl stop 。5.2 汉化文件覆盖cp -r -f ./gitlab/* /opt/gitlab/embedded/service/gitlab-rails/ 这里有个坑，复制覆盖的时候你要按N多个Y，用其他的方法也比较麻烦，在cp前边加个反斜杠就搞定了\cp -r -f ./gitlab/* /opt/gitlab/embedded/service/gitlab-rails/ 复制完成后重新加载配置，命令：gitlab-ctl reconfigure ，并启动GitLab ，命令：gitlab-ctl start 。 ...

回滚1、查看提交记录$ git log –oneline如下图：2、选择需要回退到的版本$ git reset 0223e0a –hard // 0223e0a:版本号， –hard // 会将当前未提交的代码抹掉，强制转到指定版本3、提交$ git push -f

说明年前我需要写公司的年度工作总结，所以把项目里的提交日志拉出来查看，其中有几类提交是无效的也是没有意义的，整理起来十分蛋疼，所以记录下来。示例只有操作类型fixadd上面这两个可以知道是修复功能和添加功能，但是需要看代码才能知道修复的是什么，添加的是什么。提交说明使用外文进行说明fix refund英文不好的人可能看到英文得需要想几秒，甚至需要翻译。无详细说明严重BUG修复退货退款时间记录虽然知道是修复严重 BUG，但是 BUG 是什么功能，为什么是严重 BUG 并不知道。而第二种虽然没多大毛病，但改成 “补充遗漏退货退款完成时间” 会更好些。多个功能混在一起提交修改xxx添加xxx去除xxx不建议这样子提交，但是后面回顾代码的时候区分不出每个项对应的内容。不要怕提交条数多，如果需要审阅代码就知道分开提交的好处了。无意义的说明修复 xxx 文件提交记录里会记录当次提交的所有文件，没有说明的意义。使用 GitHub issues 的方式提交fix issues #894这种提交是模仿 GitHub 上的提交方式，它会自动关联上指定的 issues，对直接在 GitHub 上审阅代码时很好用。但是对于完全独立的代码仓库来说，会不知道具体的问题是什么。可以保留这个方式写在说明第二行即可。gogs 也有类似的功能。但对于禅道，这种没有关联的来说，完全没有必要记录上去。总结对提交进行分类统一提交格式过段时间回来查看提交记录还能看明白提交说明，那就代表说明表述上没有问题feat: xxx 功能详细说明：fix: xxx 功能的 xxx 问题详细说明：关联issues：#123del: xxx 功能[的 xxx 方法]详细说明：adjust: xxx 功能[的 xxx]详细说明：[] 为可选项

分支就是一条独立的时间线,既有分支,必有主干,正如一棵树谈到树枝,必有树干一样的道理.我们先前对git 的全部操作默认都是在主干上进行的,这个主干也是一种特殊的分支,名为 master 分支.无论是穿越历史还是撤销更改,我们都或多或少接触过时间线,git 管理的版本串在一起就组成了这个时间线,其中master 分支是当前分支,HEAD 指向master ,因此HEAD 相当于指向了最新的版本.基于分支上的操作,每一次 commit 都会提交一个新版本,并且新的 commit 指向原来的 commit,这来最新的 commit 就可以往前找,直到找到最初的commit.这就是 git 的时间线.当我们打算开辟新的时间线时,git 在当前 HEAD 指向的 master 分支的 commit 处新建一个 dev 分支.如果主角没有主动进入时间线的话,那么仍然处于 master 分支,进入的方法就是 HEAD指向新建的 dev 分支.不考虑孙悟空的分身特效,主角不能同时处于不同的时空下,git 也是如何,HEAD 只能指向某一个 commit ,既然刚刚已经指向了 dev 分支,所以原来的 master 分支就没有 HEAD 了,因为相当于master 分支静止了.当主角在 dev 分支独自闯荡干出一番事业时,决定回到故乡 master 分支,并将出门在外所学的本领带回家乡,建设美好家园.master 分支因为合并了 dev 分支,所以一下子增添了很多内容,家乡焕然一新!主角这次携带 dev 分支归来,HEAD 分支自然又回到了 master 分支上,年轻的心向往外面的世间,相信不久后还会有同样的故事发生…下面详解分支相关命令创建分支创建 dev 分支,列出分支已验证是否创建成功# 创建分支$git branch dev# 列出分支$ git branch dev* master$ * master 前面的 * 标记表明当前仍然处于 master 分支切换分支切换到新分支以便在分支上开展工作# 切换分支$ git checkout devSwitched to branch ‘dev’# 列出分支$ git branch* dev master$现在,我们在 dev 分支上奋笔疾书,先后提交两个版本后完成分支开发工作:# 查看当前文件列表$ lsLICENSE README.md test.txt# 查看目标文件内容$ cat test.txtadd test.txtsee https://snowdreams1006.github.io/git/usage/remote-repository.html# 第一个版本: learn git branch$ echo “learn git branch” >> test.txt$ git add test.txt$ git commit -m “learn git branch”[dev 9c30e50] learn git branch 1 file changed, 1 insertion(+)# 第二个版本: see https://snowdreams1006.github.io/git/usage/branch-overview.html$ echo “see https://snowdreams1006.github.io/git/usage/branch-overview.html" >> test.txt$ git add test.txtsunpodeMacBook-Pro:git-demo sunpo$ git statusOn branch devChanges to be committed: (use “git reset HEAD <file>…” to unstage) modified: test.txt$ git commit -m “see https://snowdreams1006.github.io/git/usage/branch-overview.html"[dev 413a4d1] see https://snowdreams1006.github.io/git/usage/branch-overview.html 1 file changed, 1 insertion(+)此时,再从 dev 分支切换回 master 分支,合并dev分支前看一下当前文件内容:# 切换回 master 分支$ git checkout masterSwitched to branch ‘master’Your branch is up to date with ‘origin/master’.sunpodeMacBook-Pro:git-demo sunpo$ git statusOn branch masterYour branch is up to date with ‘origin/master’.nothing to commit, working tree clean# 查看当前文件列表$ lsLICENSE README.md test.txt# 查看文件内容: 无 dev 分支更改$ cat test.txtadd test.txtsee https://snowdreams1006.github.io/git/usage/remote-repository.html$ 合并分支切换回 master 分支并没有我们在 dev 分支的更改,因为两条时间线是独立的,现在合并 dev 分支,再看一下当前文件内容:# 合并 dev 分支$ git merge devUpdating b3d8193..413a4d1Fast-forward test.txt | 2 ++ 1 file changed, 2 insertions(+)# 查看文件内容: 已经存在 dev 分支的更改!$ cat test.txtadd test.txtsee https://snowdreams1006.github.io/git/usage/remote-repository.htmllearn git branchsee https://snowdreams1006.github.io/git/删除分支合并分支后,dev 分支的历史使命已经完成,应该及时清空不必要分支.# 删除 dev 分支$ git branch -d devDeleted branch dev (was 413a4d1).# 列出当前分支: 只剩下 master 分支$ git branch* master$ 以上场景包括了分支的常用操作,创建分支(git branch <name>),切换分支(git checkout <name>),删除分支(git branch -d <name>)一系列操作十分流畅,因此 git 鼓励我们大量使用分支!小结列出分支 git branch创建分支 git branch <name>切换分支 git checkout <name>创建并切换分支 git checkout -b <name>合并指定分支到当前分支 git merge <name>删除分支 git branch -d <name> ...

背景什么是分支?简单地说,分支就是两个相对独立的时间线,正常情况下,独立的时间线永远不会有交集,彼此不知道对方的存在,只有特定情况下,两条时间线才会相遇,因为相遇,所以相知,因为相知,所以改变!正如分支对于科幻电影来说是一个很好的卖点,关于分支的话题完全可以开启新的题材,对于这点相信不少科幻迷都深有体会,不必赘述.回归正题,分支对于版本控制系统又意味着什么呢?实际工作中,我们大多作为一个团队一起合作开发项目,如果是独立开发者,只有一个人的话,其实用不到分支的概念,甚至远程仓库也用不到.所以下述情况针对的都是团队开发情况.作为团队中的一员不论是项目领导还是项目成员,都需要了解并掌握分支的一般概念和常用操作.如果你刚好是实际开发的程序猿,上级领导分派一个新功能,预期两个星期内才能完成,其他同事也是如此,每个人都有自己的任务.接收任务就要开始干活,第一天工作开了一个头,还留下一大堆的 TODO 标记,此时你照例运行 git add ,git commit 等命令,学会上节的git push origin master 你知道了本地仓库和远程仓库的概念,你想将你的工作成果分享给其他人就要推送到远程仓库,这样其他人才能可见,等一等,别急!首先明确的是,这个完整功能至少需要2个星期才能基本完成啊,你现在刚刚起了个头还没完成呢!你要是真的推送到远程仓库了,那其他人是不是有理由认为你这部分功能已完成?那你可能会反驳说,我可以在工作群吼一声,说这个功能还没完成,大家别着急使用哈!这样确实可以,很长一段时间内其他人必须无视你的代码,只有等你的功能基本可用时,等你再吼一声,别人才会去使用你的代码.粗略一看,好像并没有什么问题?!实际上这种情况是存在很大风险的,因为未完成未经过测试的代码可能会产生大量意外 bug,严重的话,甚至影响整个系统,到时候由于你的未完成代码导致别人项目都无法运行,那别人还怎么工作,这个责任是谁负责?所以,为了不给其他人造成麻烦,最好不要把未完成工作直接暴露到别人面前,那长时间提交又可能会造成丢失更改的风险,此时此景,平行时间线应用而生!从接手新功能的时间点开始,创建一条新的时间线,于是新功能的开发完全在新的时间线上进行,至于其他人是否开启新的时间线那就不是我们能控制得了,我们能做到的就是不给其他人制造麻烦,如果其他人给我们制造麻烦的话,那我们就去上级领导那告他一状,哈哈!等功能开发差不多时,你再想办法切换到原来的时间线上并将开发时间线的更改顺便都带过来,这样一来,别人虽然看不到你的开发时间线,但是看到了你离开的这段时间原来做了这么多的更改啊!现在用git的专业术语再解释一遍上述场景:接手新功能的时刻开始,创建一个开发分支(既可以是本地分支也可以是远程分支),以后新功能的开发全部在开发分支上完成,处于开发分支上你可以照常运行 git add ,git commit 等命令,不用担心丢失更改.等工作一段时间后,终于完成了新功能,是时候让新功能展示给其他同事了.此时再切换到原来的主干分支,在主干分支上合并开发分支,现在主干分支上已经有新功能了,这样一来,其他同事突然发现你已经偷偷地完成了新功能的开发!不仅 git 有分支概念,其他版本控制系统比如 svn 也有分支概念,基本概念和常用操作类似,只不过 git 更强大,创建分支,切换分支,合并分支等功能十分强大,效率太高!(svn 创建分支,切换分支等操作简直慢到可以喝一杯茶了,分支管理都快成摆设了!)建议开发新功能时尽量创建自己的分支,不要给其他人造成麻烦分配任务时要求项目成员创建各自分支,等时机成熟时再合并到主干分支

远程仓库如果说本地仓库已经足够个人进行版本控制了,那么远程仓库则使多人合作开发成为可能.如果你只是打算自己使用git,你的工作内容不需要发布给其他人看,那就用不到远程仓库的概念.git 是分布式版本控制系统,分布式意味着同一个git 仓库 可以部署在不同的机器上,正如"鸡生蛋蛋生鸡"问题一样,不论如何,先要有一个原始仓库,然后才能分布到其他机器上去.充当原始仓库的机器要有一个特点那就是24h 开机且大家都能访问到,这个概念类似于"中央服务器".这样一来大家都可以从"中央服务器"下载最新代码,克隆到本地,本地发生更改后再推送给"中央服务器".如此一来,大家交流方便很多,轻松实现文件内容的共享.这种"中央服务器"比较有名的是国外的网站 github,当然国内也有不少类似服务.像这种"中央服务器"也可以自己搭建,现阶段搭建的话简直就是"杀鸡焉用牛刀"!背景关于如何注册配置相关请参考 github 教程为了和上述教程保持一致,项目名git-demo,先看一下当前工作区状态:# 查看文件列表$ lsLICENSE README.md test.txt# 查看文件内容$ cat test.txtadd test.txt现在测试一下本地更改能否推送到远程仓库,先在本地文件 test.txt 随便写点东西,然后添加(git add),提交(git commit),最后推送到远程仓库(git push origin master).# 写入新的内容并提交到本地仓库$ echo “see https://snowdreams1006.github.io/git/usage/remote-repository.html" >> test.txt$ git add test.txt$ git commit -m “see https://snowdreams1006.github.io/git/usage/remote-repository.html"[master b3d8193] see https://snowdreams1006.github.io/git/usage/remote-repository.html 1 file changed, 1 insertion(+)# 推送到远程仓库$ git push origin masterCounting objects: 3, done.Delta compression using up to 4 threads.Compressing objects: 100% (3/3), done.Writing objects: 100% (3/3), 359 bytes | 359.00 KiB/s, done.Total 3 (delta 1), reused 0 (delta 0)remote: Resolving deltas: 100% (1/1), completed with 1 local object.To github.com:snowdreams1006/git-demo.git 8e62564..b3d8193 master -> master$ 命令行没有报错证明我们已经成功推送到 github,现在登录 github 看一下有没有刚才我们提交的新内容.现在本地版本库和远程版本库已经能够正常建立关联了,此刻起将不再是独自一人在战斗!小结创建已有本地仓库和远程仓库的关联# 添加远程仓库关联git remote add origin git@github.com:username/repos.git# 首次推送 master 分支的全部内容git push -u origin master# 后续推送 master 分支的最新更改git push origin master从已有远程仓库克隆到本地仓库# 克隆远程仓库到本地仓库git clone git@github.com:username/repos.git# 推送 master 分支的最新更改git push origin master ...

撤销更改相信你已经了解了 git 的基本概念,也清楚了工作区,暂存区和版本库的关系,现在让我们用所学的知识继解决实际问题吧!背景正常看得见的目录是我们最为熟悉的工作区,在工作中不可能总是100%的精力,难免会犯错,尤其是下午犯困,晚上加班更是如此.下面列举了常见的一些场景场景一: 工作区出现意外更改且尚未添加到暂存区北京时间现在是晚上10点钟,你正在赶制一份工作报告,尽管心中一万个不愿意,还是不得不做.开始模拟意外更改前,先查看一下 test.txt 文件相关信息:# 列出当前目录的文件$ lsfile1.txt file2.txt file3.txt newFile.txt test.txt# 查看 test.txt 文件内容$ cat test.txtgit testgit initgit diffunderstand how git control versionhow git workgit tracks changes of files# 查看 test.txt 文件状态$ git statusOn branch masterChanges 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: test.txtUntracked files: (use “git add <file>…” to include in what will be committed) .DS_Storeno changes added to commit (use “git add” and/or “git commit -a”)# 查看 test.txt 文件差异$ git diff diff –git a/test.txt b/test.txtindex d31bdd2..56c76b7 100644— a/test.txt+++ b/test.txt@@ -3,4 +3,4 @@ git init git diff understand how git control version how git work-git tracks changes+git tracks changes of files$ 还记得在上一节中我们讲解 git 版本控制的到底是什么,为了证明 git 管理的是更改而不是文件本身,我们特意在第二次更改时没有添加到暂存区,现在我们先把这个遗留问题解决掉.# 工作区更改添加到暂存区$ git add test.txt# 暂存区内容提交到版本没哭$ git commit -m “git tracks changes of files”[master b7bda05] git tracks changes of files 1 file changed, 1 insertion(+), 1 deletion(-)# 查看文件状态$ git statusOn branch masterUntracked files: (use “git add <file>…” to include in what will be committed) .DS_Storenothing added to commit but untracked files present (use “git add” to track)$ 现在正在加班加点干活,一不小心将心中的不满表露出来了,于是有了下面的内容:# 意外更改正是这么犯傻的一句话$ echo “My stupid boss still prefers svn” >> test.txt# 当前文件内容$ cat test.txtgit testgit initgit diffunderstand how git control versionhow git workgit tracks changes of filesMy stupid boss still prefers svn$ 虽然强打精神,可还是很困,于是打算喝杯咖啡提提神,猛然发现 stupid boss 可能会让你丢掉这个月的奖金!暗自庆幸,咖啡果然是个好东西,既然发现了问题,那就事不宜迟赶紧修复,因为不适宜的话正是 stupid boss ,所以你完全可以手动删除,但是假如你说了一大堆不合适的话,或者复制粘贴时弄错了,这就不是删除一两行那么简单了!既然手动解决比较麻烦,那git 有没有什么好方法来解决这类问题呢?在寻求git 帮助前,首先再看一下当前文件状态(git status).正所谓"知己知彼方能百战百胜",还是看一眼吧!# 查看文件状态$ git statusOn branch masterChanges 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: test.txtUntracked files: (use “git add <file>…” to include in what will be committed) .DS_Storeno changes added to commit (use “git add” and/or “git commit -a”)$ git 不负众望,果然给了我们希望,(use “git checkout – <file>…” to discard changes in working directory) 这句话的告诉我们可以丢弃工作区的更改!脑海中在快速回忆一下工作区,暂存区,版本库三者之间的关系,其实git checkout – <file> 命令的意思是用暂存区的内容替换掉工作区内容,因此也就是丢弃掉工作区的更改了.事不宜迟,运行 git checkout – <file> 命令试试看吧:# 丢弃工作区的更改$ git checkout – test.txt# 查看文件内容: My stupid boss still prefers svn 终于不见了$ cat test.txtgit testgit initgit diffunderstand how git control versionhow git workgit tracks changes of files# 查看文件状态$ git statusOn branch masterUntracked files: (use “git add <file>…” to include in what will be committed) .DS_Storenothing added to commit but untracked files present (use “git add” to track)$ 一顿操作猛如虎,撤销掉意外更改,回到上一次版本控制状态,世界如此美好…注意: git checkout – <file> 中的 – 至关重要,没有它就是切换分支了!场景二: 工作区出现意外更改且已经添加到暂存区,但尚未提交到版本库时间一分一秒过去了,转眼间已经11点了,假设你不但写了一些胡话,还添加到暂存区了(git add).可想而知,这次意外比场景一要糟糕.# 模拟正常提交(不然岂不是从场景一到场景二你什么都没做,那还能叫做赶制工作报告吗?!)$ echo “someone prefers svn,but i don’t care it” >> test.txt$ cat test.txtgit testgit initgit diffunderstand how git control versionhow git workgit tracks changes of filessomeone prefers svn,but i don’t care it$ git add test.txt$ git commit -m “normal commit”[master ab1cbd2] normal commit 1 file changed, 1 insertion(+)# 意外更改的前夕 $ cat test.txtgit testgit initgit diffunderstand how git control versionhow git workgit tracks changes of filessomeone prefers svn,but i don’t care it# 意外更改内容: my teammate is stupid too.$ echo “my teammate is stupid too.” >> test.txt$ cat test.txtgit testgit initgit diffunderstand how git control versionhow git workgit tracks changes of filessomeone prefers svn,but i don’t care itmy teammate is stupid too.# 意外操作: 将意外更改内容提交到暂存区$ git add test.txt 不过庆幸的是,在提交到版本库(git commit)之前及时发现问题,还是看一下现在的文件状态(git status)吧!# 查看文件状态: 救命稻草 (use “git reset HEAD <file>…” to unstage)$ git statusOn branch masterChanges to be committed: (use “git reset HEAD <file>…” to unstage) modified: test.txtUntracked files: (use “git add <file>…” to include in what will be committed) .DS_Store$ git 同样告诉我们,可以使用 git reset HEAD <file> 命令撤销暂存区更改.其实 git reset HEAD <file> 命令是用版本库的内容替换掉暂存区的内容,也就是说原来暂存区的内容已被丢弃了!所以说这个命令并不会影响工作区内容,不如我们现在再看一眼工作区内容,方便执行 git reset HEAD <file> 命令后证实我们的结论.# 查看文件内容: my teammate is stupid too.$ cat test.txtgit testgit initgit diffunderstand how git control versionhow git workgit tracks changes of filessomeone prefers svn,but i don’t care itmy teammate is stupid too.$ 迫不及待执行 git reset HEAD <file> 命令,先睹为快!# 救命稻草: 版本库内容替换掉暂存区内容$ git reset HEAD test.txtUnstaged changes after reset:M test.txt# 效果: 目标文件已修改但未添加到暂存区$ git statusOn branch masterChanges 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: test.txtUntracked files: (use “git add <file>…” to include in what will be committed) .DS_Storeno changes added to commit (use “git add” and/or “git commit -a”)# 目标文件内容: 仍然保持不变$ cat test.txtgit testgit initgit diffunderstand how git control versionhow git workgit tracks changes of filessomeone prefers svn,but i don’t care itmy teammate is stupid too.$ 现在场景二已经退化成场景一了,目标文件发生意外更改但还没添加到暂存区,如何撤销工作区更改,请参考场景一方法.提示: git checkout – test.txt场景三: 工作区出现意外更改不仅已添加到暂存区,还已提交到版本库,但尚未推送到远程仓库时间不紧不慢地已经到凌晨了,困意越来越浓,洋洋洒洒写下几千字的工作报告,总算是写完了,添加到暂存区(git add),提交到版本库(git commit)一气呵成,等等,好像有什么不对劲,难免会犯糊涂,这不又发生意外了!# 衔接场景二$ cat test.txtgit testgit initgit diffunderstand how git control versionhow git workgit tracks changes of filessomeone prefers svn,but i don’t care it# 正常提交一$ echo “i love working,work makes me happy” >> test.txt$ git add test.txt$ git commit -m “encourage myself”[master a44cf7a] encourage myself 1 file changed, 1 insertion(+)# 正常提交二$ echo “fix 110 bugs,so happy” >> test.txt$ git add test.txt$ git commit -m “fix bugs”[master c66399d] fix bugs 1 file changed, 1 insertion(+)sunpodeMacBook-Pro:demo sunpo$ git statusOn branch masterUntracked files: (use “git add <file>…” to include in what will be committed) .DS_Storenothing added to commit but untracked files present (use “git add” to track)# 意外更改: hate to work overtime$ echo “hate to work overtime” >> test.txt$ git add test.txt$ git commit -m “test.txt”[master c965724] test.txt 1 file changed, 1 insertion(+) $ 天妒英才,加班加点做事情,本想赢得老板的赏识,没想到最后一句话"hate to work overtime"让所有的努力都付之一炬,怎么办?死马当活马医,还是照例看看git status 能提供什么建议吧!$ git statusOn branch masterUntracked files: (use “git add <file>…” to include in what will be committed) .DS_Storenothing added to commit but untracked files present (use “git add” to track)$ 没有提供任何意见能帮助我们撤销意外更改,先别慌,容我深思三秒钟…既然意外更改已经提交到版本库,那么应该用什么内容替换版本库内容呢?有了,既然最新版本库不可用,那上一个版本库内容可用的啊,完全可以用上一个版本库内容替换最新版本库内容,真乃"天生我材必有用"!# 当前文件内容: 闯祸的"hate to work overtime"$ cat test.txtgit testgit initgit diffunderstand how git control versionhow git workgit tracks changes of filessomeone prefers svn,but i don’t care iti love working,work makes me happyfix 110 bugs,so happyhate to work overtime# 版本回退: 回到过去假装什么都没发生过$ git reset –hard HEAD^HEAD is now at c66399d fix bugssunpodeMacBook-Pro:demo sunpo$ git statusOn branch masterUntracked files: (use “git add <file>…” to include in what will be committed) .DS_Storenothing added to commit but untracked files present (use “git add” to track)# 岁月静好,一切似乎都没发生过$ cat test.txtgit testgit initgit diffunderstand how git control versionhow git workgit tracks changes of filessomeone prefers svn,but i don’t care iti love working,work makes me happyfix 110 bugs,so happy# 当前文件状态$ git statusOn branch masterUntracked files: (use “git add <file>…” to include in what will be committed) .DS_Storenothing added to commit but untracked files present (use “git add” to track)$ 详情请参考回到过去,时空穿越之旅就是这么方便哈!提示: git reset –hard HEAD^场景四: 工作区出现意外更改不仅已添加到暂存区,还提交到版本库,还已推送到远程仓库场景一到场景三都是本地仓库,所有的文件更改只能本机访问,小伙伴也好,上级领导也罢都无法查看到你本地更改,但是一旦你推送到远程仓库了,那么其他人就能查看你的更改了!正常的提交更改还好,怕就怕这种"stupid boss"被领导看到就不好了,那应该怎么办?暂时还是自求多福吧!小结丢弃工作区更改: git checkout – <file>丢弃暂存区更改: git reset HEAD <file>丢弃本地版本库更改: git reset –hard HEAD^丢弃远程版本库更改: 自求多福 ...

版本控制我们知道 git 是分布式版本控制系统,所以称被控制对象是版本本身没错,但是从git 命令中发现,并没有版本这个名词,有的只是commit,所以前几节我一直称其为提交.为了避免后续教程引发歧义,特意说明,无论是版本也好,提交也罢,都是中文翻译而已,不必太过较真,直接原汁原味称commit也可以啊!假设你已掌握暂存区的相关概念,简单来说,暂存区就是更改文件的缓存集合,等待一次性全部提交到版本库,正因如此,方便我们批量操作相关性文件,打包提交到版本库,这正是暂存区的独特魅力.我们反复在说 git 是分布式版本控制系统,分布式的概念已经粗略讲过多次了,下面我们讲一下版本控制,谈谈 git 的版本控制和其他系统的版本控制有什么不同,为什么 git 这么优秀,如此流行?git 跟踪并管理的是更改,而非文件本身.正如linux 一切皆文件,java 一切皆对象一样,git 一切皆更改.新增文件是一个更改,新增文件内容是一个更改,修改文件内容是一个更改,删除文件内容也是一个更改,换言之,git 管理的正是这一个个的更改,并不是文件本身.下面我们用事实说话,证明 git 管理的是更改而不是文件本身:第一步,追加 git tracks changes 到 test.txt 文件# 查看 test.txt 文件内容$ cat test.txtgit testgit initgit diffunderstand how git control versionhow git work# 追加 git tracks changes 文件内容到 test.txt 文件$ echo “git tracks changes” >> test.txt# 再次查看 test.txt 文件内容$ cat test.txtgit testgit initgit diffunderstand how git control versionhow git workgit tracks changes$ 第二步,添加test.txt 文件到暂存区并查看文件状态$ git add test.txt$ git statusOn branch masterChanges to be committed: (use “git reset HEAD <file>…” to unstage) modified: test.txtUntracked files: (use “git add <file>…” to include in what will be committed) .DS_Store$ 对于上述内容应该不必再解释了吧,无外乎说test.txt 文件已修改(modified),即将被提交(to be committed).但是,此时偏偏不提交,继续修改 test.txt 文件:(这种情况实际工作中也有可能出现,比如你正在研发某功能,本以为已经开发完毕,满心欢喜添加到暂存区,然后意外发现一个小bug,分分钟就修复了,时间间隔很短以至于你根本不记得还需要再次添加到暂存区.)第三步,继续修改文件内容,忘记再次添加到暂存区# 编辑 test.txt 文件,将 git tracks changes 更改为 git tracks changes of filesvim test.txt# 查看 test.txt 文件内容$ cat test.txtgit testgit initgit diffunderstand how git control versionhow git workgit tracks changes of files$ 第四步,正常提交暂存区的全部更改到版本库$ git commit -m “git tracks changes”[master 2daa74a] git tracks changes 1 file changed, 1 insertion(+)此次提交后,我们再看一下文件状态:$ git statusOn branch masterChanges 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: test.txtUntracked files: (use “git add <file>…” to include in what will be committed) .DS_Storeno changes added to commit (use “git add” and/or “git commit -a”)$发现有什么不同吗?以往提交后再次查看文件状态,工作区都是干净的,这次居然提示我们 test.txt 文件已经修改但未添加到暂存区?!等一下,我们先回忆一下我们的操作流程:第一次修改(git tracks changes) -> git add -> 第二次修改(git tracks changes of files) -> git commit这样就很好理解了,git 管理的是更改而不是文件本身,如果是文件本身的话,应该将文件的内容全部提交才对,所以管理的是更改.第一次修改过后使用 git add 命令将工作区的第一次修改内容放到暂存区准备提交,但是此时工作区发生了第二次修改,注意,这次修改并没有放到暂存区,所以下一步的git commit 命令提交的暂存区内容中自然也就没有第二次修改的内容了!所以git commit 完毕后运行git status命令才会发现此时工作区和暂存区还存在版本差异,即此时工作区不是干净的!这一次的实验很好理解,工作区的修改需要主动告诉暂存区,暂存区的全部更改再提交到版本库.所以版本库的提交取决于暂存区,而暂存区又取决工作区是否主动将更改添加进去了吗!理论再多不如亲身体验,让我们直接比较一下工作区和版本库的差异吧!# 比较 test.txt 文件在工作区和版本库的差异$ git diff HEAD – test.txtdiff –git a/test.txt b/test.txtindex d31bdd2..56c76b7 100644— a/test.txt+++ b/test.txt@@ -3,4 +3,4 @@ git init git diff understand how git control version how git work-git tracks changes+git tracks changes of files$ 由此可见,工作区比版本库多了git tracks changes of files,少了git tracks changes,所以说第二次修改内容 git tracks changes of files 并没有被提交.现在我们再解释一下-git tracks changes 和 +git tracks changes of files 的问题:首先查看工作区 test.txt 文件内容$ cat test.txtgit testgit initgit diffunderstand how git control versionhow git workgit tracks changes of files$ 根据上述分析,我们知道第一次的修改git tracks changes 已被提交到版本库,第二次的修改git tracks changes of files 没有被提交而是继续留在工作区.因此,可以推断出目前版本库的文件应该是这样的:git testgit initgit diffunderstand how git control versionhow git workgit tracks changes既然如何,工作区和版本库相比岂不刚好是少了一个git tracks changes,多了git tracks changes of files,其余文件内容完全相同!透过现象看本质,已经分析了现象也解释了产生现象的原因,是时候分析一下本质了.抛出问题:因为git tracks changes of fiels 和 git tracks changes 被视为不同的更改,所以才会造成上述现象.如果git tracks changes of fiels 被认为是git tracks changes + of fiels 两者叠加产生的更改,还会产生上述现象吗?答案是否定的,如果两个更改可以叠加的话,按照版本控制的思路,第二次的修改即便没有提交也只是 of fiels 没有加入到版本库而已,如此一来,工作区和版本库的差异将不再是少了一个git tracks changes,多了git tracks changes of files,而仅仅是多了of files!由此可见,git 版本控制系统其实是全量更新的思维模式,并不是差量更新模式.小结工作区的更改需要git add 添加到暂存区,git commit 将暂存区的全部更改提交到版本库.工作区,暂存区,版本库三者既相关独立又密切关联,三者是传递性依赖的关系.git 版本控制的是文件的更改,而不是文件本身,是全量更新模式,而不是差量更新模式. ...

删除文件回忆一下文件的常见操作,新增文件,修改文件,删除文件等,新增和修改文件都单独讨论过,现在我们来研究一下如何删除文件.你可能会说删除文件还不简单啊,直接 rm -rf <file> 即可,但是这仅仅是本地文件被删除了,对于 git 来说,文件并没有被删除.还记得我们开篇介绍git 时就说过,一切操作皆版本 ,对于新增是一个版本,修改也是一个版本,就连删除都是一个版本.下面让我们看一下 git 中如何删除文件吧!背景# 查看当前文件列表$ lsfile1.txt file2.txt file3.txt newFile.txt test.txt# 新建待删除文件$ touch delete.txt# 再次查看当前文件列表,确保新建文件成功$ lsdelete.txt file2.txt newFile.txtfile1.txt file3.txt test.txt# 查看当前文件状态: 新文件 delete.txt 还没被跟踪$ git statusOn branch masterUntracked files: (use “git add <file>…” to include in what will be committed) .DS_Store delete.txtnothing added to commit but untracked files present (use “git add” to track)# 添加新文件 delete.txt$ git add delete.txt# 查看文件状态: 已添加到暂存区,待提交到版本库$ git statusOn branch masterChanges to be committed: (use “git reset HEAD <file>…” to unstage) new file: delete.txtUntracked files: (use “git add <file>…” to include in what will be committed) .DS_Store# 提交新文件 delete.txt$ git commit -m “add delete.txt”[master 7df386a] add delete.txt 1 file changed, 0 insertions(+), 0 deletions(-) create mode 100644 delete.txt# 再次查看文件状态: 已经没有新文件 delete.txt 的更改信息$ git statusOn branch masterUntracked files: (use “git add <file>…” to include in what will be committed) .DS_Storenothing added to commit but untracked files present (use “git add” to track)$ 以上操作,我们简单创建 delete.txt 文件,添加(git add)并提交(git commit) 该文件,完成准备工作后,开始删除文件!# 删除前文件列表$ lsdelete.txt file2.txt newFile.txtfile1.txt file3.txt test.txt# 删除刚刚创建的文件 delete.txt$ rm delete.txt# 删除后文件列表$ lsfile1.txt file2.txt file3.txt newFile.txt test.txt# 当前文件状态: delete.txt 文件已被删除,且未添加到暂存区$ git statusOn branch masterChanges not staged for commit: (use “git add/rm <file>…” to update what will be committed) (use “git checkout – <file>…” to discard changes in working directory) deleted: delete.txtUntracked files: (use “git add <file>…” to include in what will be committed) .DS_Storeno changes added to commit (use “git add” and/or “git commit -a”)$ 本地删除 delete.txt 文件后,再次查看文件状态 git status 发现 git 给了我们两条建议,其中一条 git checkout – <file> 我们很熟悉,就是丢弃工作区的更改,此时此景下如果丢弃删除操作,相当于撤销删除,难怪说删除也是一个版本呢!现在我们重点来看第一条建议 git add/rm <file> ,rm 是 remove 单词的缩写,即删除文件.# 删除文件$ git rm delete.txtrm ‘delete.txt’# 查看文件状态: delete.txt 文件待提交$ git statusOn branch masterChanges to be committed: (use “git reset HEAD <file>…” to unstage) deleted: delete.txtUntracked files: (use “git add <file>…” to include in what will be committed) .DS_Store# 提交文件$ git commit -m “remove delete.txt”[master 6298070] remove delete.txt 1 file changed, 0 insertions(+), 0 deletions(-) delete mode 100644 delete.txt# 再次查看文件状态$ git statusOn branch masterUntracked files: (use “git add <file>…” to include in what will be committed) .DS_Storenothing added to commit but untracked files present (use “git add” to track)$ 删除文件和添加文件类似,都是一次commit ,本地文件的任何更改都要添加到暂存区,然后提交到版本库.小结删除文件和新增文件类似逻辑,git rm 删除文件后,依然需要 git commit 提交版本. ...

回到过去背景现在你已经掌握git的基本操作了,文件发生更改首先使用 git add 添加更改,然后 git commit 提交全部更改,当本地文件再次发生更改时,仍然需要git add 和 git commit 两步操作,中途如何想查看文件是否发生更改,使用git status 查看版本库状态,git diff 命令帮助我们查看更改详情.像这样重复的操作其实每次都会产生一个快照,用于保存文件状态,只不过这个快照不是完整的文件,被称为提交或者版本commit .一旦发生意外,假如文件修改乱了或者误删了文件,我们可以从最近的一个 commit 中进行恢复,然后继续工作,这就是git 管理的好处之一.每一次重大更新或者你认为比较重要的时刻,我们总会留作纪念,添加些什么特殊标记来区分平时的提交,还记得我们每次提交都会添加备注吗?git commit -m <remark> 这条命令现在就可以大显身手了,我们现在要做的就是找到我们提交的历史记录,而历史记录中有我们提交的详情,这样即使过了一个月或者更长时间,我们也能清楚知道当时的情景!查看提交历史记录 git log,接下来我们赶紧试一下吧$ git logcommit 36f234a60d858871f040cb0d7ca3e78251df82f7 (HEAD -> master)Author: snowdreams1006 <snowdreams1006@163.com>Date: Thu Mar 7 22:19:00 2019 +0800 add understand how git control versioncommit 2006f72ffe2ce2278b5974313b8598847cf445e4Author: snowdreams1006 <snowdreams1006@163.com>Date: Tue Mar 5 13:27:46 2019 +0800 add 3 files.commit eaa4850070354ae987dc5108a9fd57fda9d64730Author: snowdreams1006 <snowdreams1006@163.com>Date: Tue Mar 5 12:18:57 2019 +0800 add git initcommit 6ad8956bc09a6a62c731711eabe796690aa6471cAuthor: snowdreams1006 <snowdreams1006@163.com>Date: Tue Mar 5 12:17:51 2019 +0800 add test.txtgit log 命令默认显示最近到最远的提交历史,这一点也很好理解,毕竟我们是在命令行操作,输入git log 完毕后自然先要定位到命令处,看到最新提交记录方便我们确认是否符合我们预期,还有一点就是如果提交历史过多,从头开始到最新提交记录岂不是眼花缭乱,简直不敢想象啊!下面以最新的一次提交 commit 为例,简单解释一下输出内容:# 提交唯一标示id: 36f234a60d858871f040cb0d7ca3e78251df82f7commit 36f234a60d858871f040cb0d7ca3e78251df82f7 (HEAD -> master)# 作者: snowdreams1006 邮箱: <snowdreams1006@163.com>Author: snowdreams1006 <snowdreams1006@163.com># 日期: Thu Mar 7 22:19:00 2019 +0800Date: Thu Mar 7 22:19:00 2019 +0800# 提交备注: add understand how git control version add understand how git control version默认输出内容有点多,不仅有提交 id ,提交备注还有作者时间之类的,由于每个 commit 都如此,这样一来,满屏都展示不下,那能不能简化些呢?一行显示提交日志 –pretty=oneline ,即git log –pretty=oneline$ git log –pretty=oneline36f234a60d858871f040cb0d7ca3e78251df82f7 (HEAD -> master) add understand how git control version2006f72ffe2ce2278b5974313b8598847cf445e4 add 3 files.eaa4850070354ae987dc5108a9fd57fda9d64730 add git init6ad8956bc09a6a62c731711eabe796690aa6471c add test.txt$ 相比无参数git log,是不是简短了一些呢? 和之前日志相比少了作者和时间等信息,仍然保留提交 id 和提交备注.因为提交 commit 是 git 的基础,当然不能省略,而提交备注能够帮助我们理解commit 的含义,毕竟提交备注使我们自定义的内容,这也是我们为什么提交时要写提交备注的原因!现在我们已经了解到版本库存放了我们的提交,接下来让我们验证一下是否能够回到过去吧!回到上一个提交,上一个提交自然是相对当前提交而言,只有知道当前提交才能知道上一个提交以及上一个提交的上一个提交.提交id 36f234a60d858871f040cb0d7ca3e78251df82f7,那么上一个提交HEAD^,上上一个提交是HEAD^^.如果此时我想回到往上数100个版本,那么是不是可以这么写?HEAD^^^^…^^^ 其中^ 有100个,如果需要手动打出100个^的话,那么绝对是疯了!既然有这种相对定位方式,自然也有绝对定位方式,用绝对定位方式解决就是这样: HEAD100$ git logcommit 36f234a60d858871f040cb0d7ca3e78251df82f7 (HEAD -> master)Author: snowdreams1006 <snowdreams1006@163.com>Date: Thu Mar 7 22:19:00 2019 +0800 add understand how git control version回到上一个版本 git reset –hard HEAD^ 在操作之前我们先看一下当前文件 test.txt 的内容:$ cat test.txtgit testgit initgit diffunderstand how git control version现在让我们开始回到过去,运行 git reset –hard HEAD^ 命令:$ git reset –hard HEAD^HEAD is now at 2006f72 add 3 files.$ 现在让我们再看一下,test.txt 的内容有没有被还原:$ cat test.txtgit testgit init果然被还原了!这就是git的神奇之处,说明我们已经能够回到过去了!现在我们先用git log 查看下提交历史:$ git logcommit 2006f72ffe2ce2278b5974313b8598847cf445e4 (HEAD -> master)Author: snowdreams1006 <snowdreams1006@163.com>Date: Tue Mar 5 13:27:46 2019 +0800 add 3 files.commit eaa4850070354ae987dc5108a9fd57fda9d64730Author: snowdreams1006 <snowdreams1006@163.com>Date: Tue Mar 5 12:18:57 2019 +0800 add git initcommit 6ad8956bc09a6a62c731711eabe796690aa6471cAuthor: snowdreams1006 <snowdreams1006@163.com>Date: Tue Mar 5 12:17:51 2019 +0800 add test.txt$ 和上次相比,少了一条提交记录:commit 36f234a60d858871f040cb0d7ca3e78251df82f7 (HEAD -> master)Author: snowdreams1006 <snowdreams1006@163.com>Date: Thu Mar 7 22:19:00 2019 +0800 add understand how git control version这样是正常的,毕竟你已经处于 过去 了,当然看不到 未来 的提交记录.正如影视穿越剧那样,主人公意外穿越过去,总是想要回到未来,怎么办,没有法器没有未来的确切目标怎么行?!git 的穿越剧也需要这样一种法器,能准确告诉时光机把我们带到具体的那个时间点,当然这个时间点不一定是未来时刻,过去时刻也行,反正就是一个准确的坐标.聪明的你肯定已经猜测到这个任务是由commit 担任的,所有我们现在要找到未来的时间点,也就是commit id,就是那一长串 hash 字符串.只要当前命令行窗口还没有关闭,慢慢往上翻,总是能找到当初我们的穿越点commit的,即36f234a60d858871f040cb0d7ca3e78251df82f7回到当初提交 git reset –hard <commit> 万事俱备只欠东风,已经成功定位到未来坐标,等待穿越到未来!$ git reset –hard 36f234a60d858871f040cb0d7ca3e78251df82f7HEAD is now at 36f234a add understand how git control version$ 现在我们再次查看 test.txt 内容:$ cat test.txtgit testgit initgit diffunderstand how git control versi果然成功穿越回到未来!上述穿越回到未来的场景是我们知道目标 commit ,也就是在当前命令行窗口没有关闭的情况下,手动查找穿越点 commit.那如果命令行窗口已关闭或者没办法通过查阅历史命令来定位穿越点 commit 情况下怎么办呢?这种情况下也是有补救措施的,git 提供了命令历史 git reflog,记录了我们操作的命令历史.翻阅历史命令 git reflog $ git reflog36f234a (HEAD -> master) HEAD@{0}: reset: moving to 36f234a60d858871f040cb0d7ca3e78251df82f72006f72 HEAD@{1}: reset: moving to HEAD^36f234a (HEAD -> master) HEAD@{2}: commit: add understand how git control version2006f72 HEAD@{3}: commit: add 3 files.eaa4850 HEAD@{4}: commit: add git init6ad8956 HEAD@{5}: commit (initial): add test.txt确实记录了我们操作的关键命令,从上述输出结果可以看出,穿越点 commit 正是36f234a60d858871f040cb0d7ca3e78251df82f7,剩下的事情应该不必多说了吧!小结HEAD 是当前提交的指针,指向的提交就是当前提交,上一个提交是 HEAD^,上上个提交是 HEAD^^,前100个提交是HEAD100.git log 查看提交历史,git log –pretty=oneline 简短化输出提交历史.git reflog 查看命令历史,以便我们重拾关键步骤信息.git reset –hard <commit> 穿越到指定提交,比如上一个提交就是 git reset –hard HEAD^ . ...

基本概念了解工作区,暂存区和版本库的区别和联系有助于我们更好理解 git 的工作流程,了解命令的操作意图.git 和其他版本控制系统如 svn 的不同之处就是有暂存区的概念.基本概念工作区 | Working Directory正常情况下能看到的目录(不包括隐藏文件),也就是用户主动创建的目录暂存区 | Stage工作区下的隐藏.git目录下的.index文件,因此也称为索引.版本库 | Repository工作区下的隐藏目录.git目录通过前几节我们知道,将文件纳入版本控制,需要分两步操作:第一步 git add 添加文件,实际上是将文件更改添加到暂存区.第二步 git commit 提交更改,实际上是将暂存区所有内容提交到当前分支.我们使用 git init 命令初始化创建 git 仓库时,git 会自动创建唯一一个 master 分支,默认所有操作是在 master 分支上进行的,所以 git commit 就是徃 master 分支上提交更改的.通俗地讲,文件更改可以多次添加到暂存区,即允许多次执行 git add 命令,然后一次性提交暂存区的全部更改到版本库,即只需要执行一次 git commit 命令即可.说说个人理解 git 为何分成三部分进行版本控制操作,二部分行不行?答案是肯定的,没有暂存区概念的 svn 同样可以进行版本控制,所以 git 增加暂存区必然是有存在的意外也就是所谓的好处的.第一,暂存区的概念允许将本地文件的更改添加进来,也就是说本地文件的更改只有添加到暂存区才能进行下一步的提交更改,所以说那些更改添加到暂存区是由开发者本人决定的,这其实有了一定灵活性,并不是所有的更改都需要被记录!第二,暂存区作为中间过程,暂存区的内容是打算提交更改的内容,也就是说暂存区可以视为一种临时缓存,用来记录预提交更改.实际工作中,新功能的开发并不是一蹴而就的,是由一系列的更改一起组成的,如果将这些更改分散开来单独提交,那势必会产生很多commit,如果等待全部工作完成再提交的话,解决了过多commit的问题,但是又遇到新问题就是你可能很长时间才能提交一次更改,失去了版本控制的意义.综上所述,暂存区的出现一种很好的解决方案,它允许将相关性代码添加在一起,方便后续提交更改时提交的都是相关性代码!第三,作为分布式版本控制系统,不像集中式控制系统那样,对网络强相关,失去网络的 svn 是没办法再进行版本控制的,但失去网络的 git 仍然可以进行版本控制,只不过不能远程操作了而已,不过这部分也是无可厚非的,正所谓"巧妇难为无米之炊",你总不能要求断网下继续访问百度吧!好了,我们继续回到 git 常用操作上,看一下工作区,暂存区和版本库三者如何协同工作的.首先,先修改test.txt文件.# 查看 test.txt 文件内容$ cat test.txtgit testgit initgit diffunderstand how git control version# 追加 how git work 到 test.txt 文件$ echo “how git work” >> test.txt# 再次查看 test.txt 文件内容$ cat test.txtgit testgit initgit diffunderstand how git control versionhow git work$ 紧接着新建newFile.txt 并随便输入内容:# 查看当前文件夹下全部文件$ ls .file1.txt file2.txt file3.txt test.txt# 创建新文件 newFile.txt$ touch newFile.txt# 再次查看当前文件夹下全部文件$ lsfile1.txt file2.txt file3.txt newFile.txt test.txt# 输入 add newFile.txt 文件内容 到 newFile.txt 文件$ echo “add newFile.txt” > newFile.txt# 查看 newFile.txt 文件内容$ cat newFile.txtadd newFile.txt$ 现在运行git status 命令查看当前文件状态:$ git statusOn branch masterChanges 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: test.txtUntracked files: (use “git add <file>…” to include in what will be committed) .DS_Store newFile.txtno changes added to commit (use “git add” and/or “git commit -a”)$ 从输出结果中得知,test.txt 文件已修改(modified),还没添加到暂存区,而newFile.txt 文件还没被跟踪(Untracked).现在我们使用git add 命令将 test.txt 和 newFile.txt 都添加到暂存区,再用 git status 查看文件状态:# 添加 test.txt 文件git add test.txt# 添加 newFile.txt 文件git add newFile.txt# 查看文件状态git statusOn branch masterChanges to be committed: (use “git reset HEAD <file>…” to unstage) new file: newFile.txt modified: test.txtUntracked files: (use “git add <file>…” to include in what will be committed) .DS_Store$ 现在输出结果和上次就不一样了,显示的是即将被提交文件,其中 newFile.txt 是新文件(new file),test.txt 是修改文件(modified).所以,git add 命令作用是将需要提交的更改文件临时放到暂存区中,然后执行git commit 命令就可以一次性将暂存区的所有内容提交到当前分支.$ git commit -m “understand how stage works”[master a5cd3fb] understand how stage works 2 files changed, 2 insertions(+) create mode 100644 newFile.txt$ git statusOn branch masterUntracked files: (use “git add <file>…” to include in what will be committed) .DS_Storenothing added to commit but untracked files present (use “git add” to track)$ 暂存区的所有内容提交到版本库,所以运行git status 时,工作区是干净的,即此时暂存区没有内容了!.DS_Store 是 mac 电脑自动生成的文件,可以暂不理会,等到后面的.gitignore 文件时再处理.图解下图展示了工作区,暂存区,版本库之间的关系:图中左侧是工作区,右侧是版本库,版本库中标记index 的区域是暂存区,标记 master 的是 master 分支所代表的目录树.HEAD 是指向 master 分支的指针,标记 objects 的区域是 git 的对象库,真实路径位于.git/objects目录下,用于表示创建的对象和内容.意图说明git add 添加文件工作区的修改或者新增的文件执行git add 命令后,暂存区(index)的目录树会自动更新,同时引发这次变化的文件内容会被记录下来,即生成对象库(objects)中的新对象,而对象的 id会被记录到暂存区的文件索引(index)中.git commit 提交文件暂存区的目录树写入到对象库(objects),master 分支的目录树自动更新.git reset HEAD 撤销文件暂存区的目录树被重写,被master 分支的目录树所替换,但是工作区不受影响.git rm –cached <file> 删除缓存文件删除暂存区文件,工作区不受影响.git checkout . 检出文件暂存区的文件替换工作区文件,注意:当前尚未添加到暂存区的改动会全部丢失!git checkout HEAD . 检出文件HEAD 指针指向的 master 分支中的文件替换暂存区以及工作区文件,注意:不仅清除工作区未提交的改动,连暂存区未提交的改动也会被清除!小结以上就是常用命令的背后意图,主要是工作区,暂存区和版本库之间文件同步策略的关系.git add 是工作区更新到暂存区git commit 是暂存区更新到版本库git reset HEAD 是版本库更新到暂存区git checkout – <file> 是暂存区更新到工作区git checkout HEAD <file> 是版本库同时更新暂存区和工作区git rm –cached 清空暂存区 ...

版本管理背景在上一节中我们已经成功创建版本库并且已经添加test.txt等文件,这一节我们继续讲解如何进行版本控制.首先我们先查看test.txt 文件有什么内容吧!# 查看文件内容$ cat test.txtgit testgit initgit diff $接下来模拟正常工作,接着输入一下内容:# 追加新内容到 test.txt 文件echo “understand how git control version” >> test.txt# 查看当前文件内容$ cat test.txtgit testgit initgit diffunderstand how git control version$ 紧接着运行 git status 看一下输出结果:# 查看文件状态$ git statusOn branch masterChanges to be committed: (use “git reset HEAD <file>…” to unstage) modified: test.txtChanges 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: test.txt$ 从上述 git status 命令输出的结果可以看出,test.txt 已经被修改但还没提交,但是具体发生了什么变化却没能告诉我们,如果能够告诉我们具体修改细节那就好了!运行git diff命令可以实现上述需求$ git diffdiff –git a/test.txt b/test.txtindex 729112f..989ce33 100644— a/test.txt+++ b/test.txt@@ -1,3 +1,4 @@ git test git init git diff+understand how git control version$ git diff 命令即查看差异(difference),从输出结果可以看出我们在最后一行新增了understand how git control version 文字.通过git status 知道文件发生了改动,git diff 让我们看到了改动的细节,现在我们提交到版本库就放心多了,还记得上节课如何添加版本库的命令吗?分两步操作: git add <file> 和 git commit -m <remark> 第一步: git add <file>$ git add test.txt$ 等一下,在执行 git commit 命令之前,我们再运行 git status 命令查看一下当前仓库状态:$ git statusOn branch masterChanges to be committed: (use “git reset HEAD <file>…” to unstage) modified: test.txt$ 此时 git status 命令告诉我们 test.txt 文件已被修改等待提交,好了,那么接着第二步的commit吧!第二步: git commit -m <remark># 提交到版本库并添加备注$ git commit -m “add understand how git control version”[master 36f234a] add understand how git control version 1 file changed, 2 insertions(+)$ 提交后,我们此时再次运行git status 命令查看当前仓库状态:$ git statusOn branch masternothing to commit, working tree clean$ 输出结果显示没有需要提价的改动,工作目录是干净的.小结查看工作区状态 git status比较修改差异 git diff ...

本地仓库背景创建工作目录平时工作时我们习惯对文档分门别类进行管理,.doc .txt 等文本类型的文件习惯存在 doc文件下,开发java js 等源代码文件存在在 src 目录下,这一点很好理解,那么讲解 git的项目我们也要创建一个文件夹,姑且新建一个demo的文件夹吧!# 在工作空间创建指定目录mkdir demo# 切换至工作目录cd demo创建本地仓库既然已经创建了工作文件夹,那么我们自然是希望该文件下的所有文件都能被 git 管理,也就是说在当前文件下的创建新文件,修改原文件内容或者删除文件等操作都能纳入版本控制中,不然为什么要用git 呢?下面这个命令就是告诉git 这个 demo 目录要纳入版本控制了.# 初始化本地仓库git init 一旦运行git init 命令,细心的读者可能会发现在原来的 demo 目录下多了.git隐藏文件,正因如此,原来被我们称为工作目录的 demo 才能纳入版本控制,我们将.git目录称之为版本库.由于当前项目 demo 只在我们自己电脑上,其他人无法访问,所以我们称这种形式的版本库为本地仓库.添加文件到版本库首先明确的是,所有的版本控制系统只能追踪文本文件的改动,文本文件就是平常熟悉的.txt .html .js .css .java .xml等等文件,非文本文件的其他格式有哪些?例如二进制文件,像我们平时听音乐的.mp3,看视频的.mp4,浏览图片的.png等这些都是二进制文件,需要专门的软件才能正常打开,不信的话,你用记事本看看能不能打开视频?了解文本文件和二进制文件的区别,那是不是说二进制文件没法进行版本控制了,刚才你不是还说demo 目录下的所有文件吗?这不是自相矛盾吗!非也非也,git 当然也能够管理二进制文件,对于文本文件的追踪,可以细粒度到哪个文件在哪一行发生了哪些变化,而二进制文件只能粗粒度知道哪个文件变化了,并不知道具体变化.不幸的是,Microsoft 的Word格式是二进制格式,因此,版本控制系统是没法跟踪Word文件的改动的,前面我们举的例子只是为了演示,如果要真正使用版本控制系统,就要以纯文本方式编写文件.因为文本是有编码的,比如中文有常用的GBK编码,日文有Shift_JIS编码,如果没有历史遗留问题,强烈建议使用标准的UTF-8编码,所有语言使用同一种编码,既没有冲突,又被所有平台所支持.言归正传,现在我们在demo 目录下创建一个test.txt 演示文件,内容如下git test# 创建新文件touch test.txt# 编辑新文件,输入 git testecho “git test” > test.txt接下来我们还需要两步操作才能将test.txt纳入git管理:第一步,使用git add <file> 命令将文件添加到本地仓库:# 添加到本地仓库: 第一步指定要添加的文件git add test.txt第二步,使用git commit -m <message> 命令将文件提交到本地仓库:# 添加到本地仓库: 第二步指定添加文件备注git commit -m “add test.txt"经过上述两步操作,test.txt 文件已经纳入到版本控制中了,这里你可能会有疑问了为什么需要add commit两步呢?因为commit 可以一次性提交很多文件,所以你可以多次add不同的文件,比如:# 创建三个文件file1.txt file2.txt file3.txttouch file1.txt file2.txt file3.txt# 添加一个文件file1.txtgit add file1.txt# 添加两个文件file2.txt file3.txtgit add file2.txt file3.txt# 一次性提交全部文件git commit -m “add 3 files.“小结初始化本地仓库 git init 添加文件到本地仓库分两步 git add <file> 和 git commit -m <message>实际工作中,大致以下流程# 在工作空间创建指定目录mkdir demo# 切换至工作目录cd demo# 初始化本地仓库git init # 创建新文件touch test.txt# 编辑新文件,输入 git testecho “git test” > test.txt# 添加到本地仓库: 第一步指定要添加的文件git add test.txt# 添加到本地仓库: 第二步指定添加文件备注git commit -m “add test.txt”…# 继续编辑目标文件,追加 git initecho “git init” >> test.txt# 将目标文件添加到本地仓库git add test.txt# 添加本次新增文件的备注git commit -m “add git init” ...

实战 gitgit 是一款分布式版本控制系统,可以简单概括: 不要把鸡蛋放在一个篮子里,你的一举一动都在监视中.实战场景你作为某项目的其中一员或者负责人,和小伙伴们一起开发,大家既有着各自分工互不干扰,也有着相互合作,最终每个人的劳动成果汇聚成最后的项目,愉快完成项目!要求理解 git 的工作流程,懂得实际工作中如何交流合作掌握 git 常用操作,工具为我所有,进而提高工作效率独当一面,最好能够独自解决使用git 过程中遇到的问题主动分享经验,能够教会别人如何使用 git 更上一层楼推荐最好的教程在官网 git 官网在线练习常用操作 Learning Git Branching廖雪峰的官方网站 git教程

安装 gitgit 目前支持 Linux/Unix、Solaris、Mac和 Windows 平台上运行,根据自身环境选择安装.Linux 系统linux 系统安装软件大致有两种途径,一种是利用安装包管理工具安装,另一种采用源码包安装方式.安装前先确认下是否之前已安装过,在命令行窗口输入git –version ,如果打印出版本号则表示已安装,否则参考一下内容进行安装.查看 git 版本git –versionDebian/Ubuntu# 安装 git 依赖apt-get install libcurl4-gnutls-dev libexpat1-dev gettext \ libz-dev libssl-dev# 安装 gitapt-get install git# 查看 git 版本git –versionCentos/RedHat# 安装 git 依赖yum install curl-devel expat-devel gettext-devel \ openssl-devel zlib-devel# 安装 gityum -y install git# 查看 git 版本git –versiongit-core 和 git 历史渊源:以前有个软件也叫GIT(GNU Interactive Tools),所以git只能叫git-core了,后来由于git名气实在太大以至于GNU Interactive Tools改名成gnuit,而git-core正式改为git.源码安装先从git 官网下载指定版本源码,然后解压,依次输入：./config,make, sudo make install 这几个命令安装到指定目录即可.Debian/Ubuntu# 安装 git 相关依赖apt-get install libcurl4-gnutls-dev libexpat1-dev gettext \ libz-dev libssl-dev# 下载指定版本源码包wget https://github.com/git/git/archive/v2.21.0.tar.gz# 解压tar -zxf v2.21.0.tar.gz# 切换到 git目录cd git-2.21.0# 安装make prefix=/usr/local all# 安装sudo make prefix=/usr/local install Centos/RedHat# 安装 git 相关依赖yum install curl-devel expat-devel gettext-devel \ openssl-devel zlib-devel# 解压tar -zxf v2.21.0.tar.gz# 切换到 git目录cd git-2.21.0# 安装make prefix=/usr/local all# 安装sudo make prefix=/usr/local install Windows 系统直接从git 官网下载安装程序,然后按默认选项安装即可.安装完成后,在开始菜单里找到Git->Git Bash,弹出命令行窗口,则说明安装成功！Mac 系统一般有两种安装方式,一种是利用 mac 的homebrew管理工具安装git,具体安装方法参考homebrew官方文档另一种方法安装xcode默认集成git,首先从 App Store下载 xcode ,下载完成后运行Xcode，选择菜单Xcode->Preferences，在弹出窗口中找到Downloads，选择Command Line Tools，点Install就可以完成安装了原文请访问 https://snowdreams1006.github.io/git/base/install.html ...

配置 git安装完成后,还需要最后一步配置就可以愉快使用了,在命令行输入：git config –global user.name “your username"git config –global user.email “example@example.com"因为Git是分布式版本控制系统,所以每个机器都必须自报家门:你的名字和Email地址.配置文件git 提供git config工具,专门用来配置相应的工作环境变量,支持三种不同的位置./etc/gitconfig 配置文件 (优先级最低)系统中对所有用户都生效的配置,效果等同于git config –system~/.gitconfig 配置文件 (优先级其次)系统中仅仅对当前登录用户生效的配置,效果等同于git config –global$(pwd)/.git/config 配置文件 (优先级最高)仅仅对当前项目生效,效果等同于git config每一级别的配置都会自动覆盖上级相同配置,当前项目配置优先于其余配置查看配置如果要查看已有的配置信息,可以输入 git config –list 命令,如果看到重复变量名,表示来自不同配置文件(比如/etc/gitconfig 和 ~/.gitconfig),实际上git会采用最后一个!# 查看已有配置信息git config –list# 查看当前用户配置信息cat ~/.gitconfig# 查看系统级别配置信息cat /etc/gitconfig也可以直接查看某项环境变量值,比如# 查看用户名称变量git config user.name原文请访问 https://snowdreams1006.github.io/git/base/config.html

git 入门教程git 是分布式版本控制系统,是文本文档管理的利器,是帮助你管理文件动态的好帮手.如果你曾经手动管理过文档,一定有这样的经历,比如你正在编辑文档,想删除某段落,又担心不久后可能会恢复,此时你可能会先备份然后再删除,或者想要修改某段落,几经修改后发现还是最初的比较好,这是就哭笑不得了…从最初的新建文档,经过反反复复的修改,最终定稿文档的过程极其繁琐冗长,这就是手动式管理文档的痛点.如果有这么一种工具,能帮我自动记录每次文档的改动,想要查看文档变更详情只需要打开软件就能一目了然告诉我发生了哪些改变?岂不美哉!版本文件用户说明时间1README.mdsnowdreams1006初始化简介文档2019-03-01 08:002README.mdsnowdreams1006增加特点说明2019-03-01 10:003README.mdsnowdreams1006增加要求说明2019-03-01 12:00事实上,还真有这样的软件,专业术语称为版本控制系统,而git就是最先进的分布式版本控制系统;特点:文件的变更从此有迹可循,再也不怕丢失文件;有网无网均可工作,数据交换不需再相互拷贝;人人平等的开放环境,有机会贡献自己的智慧;原文请访问 https://snowdreams1006.github.io/git/

初识 gitgit 是一个开源的分布式版本控制系统,用于敏捷高效地处理任何或小或大的项目.背景我们都知道,Linus 在1991年创建了开源的linux系统,随着不断发展壮大,目前已发展成为最大的服务器系统软件.Linus 虽然创建了 linux,但 linux 的发展壮大是靠全世界热心的志愿者参与贡献的,这么多人在世界各地为linux系统编写代码,那么linux的代码是如何管理呢?事实上,在2002年以前,世界各地的志愿者直接将源代码通过 diff 的方式发送给Linus,然后由Linus本人通过手动方式合并代码!…Linus花了两周时间自己用 C语言 写了一个分布式版本控制系统，这就是Git！一个月之内，Linux系统的源码已经由Git管理了！牛是怎么定义的呢？大家可以体会一下.分布式 和 集中式先说集中式版本控制系统,版本库是集中存放在专门的中央服务器中,而平时使用过程中需要时刻处于联网状态才能和中央服务器保持联系.日常工作流程是这样的,上班前先从中央服务器拉取最新工作内容,本地修改完毕后推送到中央服务器,第二天上班再拉取最新内容,修改后再推送给中央服务器…集中式版本控制系统的特点就是必须要有一个专门的中央服务器,工作中必须联网才能进行版本控制,试想一下如果正在在外地出差或者没有网络条件下,还怎么进行版本控制,岂不是又重新回到原始时代了吗?那再说说分布式版本控制系统,版本库是存放在各自使用者的电脑的,不需要专门的中央服务器,每个人电脑中就是一份完整的版本库,因此不需要联网也能工作,工作流程和其他的版本控制系统大致相同.由此可见,集中式的版本控制系统依赖于中央服务器,要求使用者一直保持通信,而分布式的版本控制系统并不依赖中央服务器,不必强制联网.万一出现意外,集中式版本控制系统中充当中央服务器的电脑宕机了,那么所有人就没法工作了,再也不能享受版本控制带来的便利了!同样的情况发生在分布式版本控制系统身上会如何呢?一台电脑宕机没关系,所有人的电脑不可能同时都宕机吧,因为每个人电脑中都是一份完整的版本控制,那么找到其中一个人的版本手动复制到宕机电脑中瞬间不久恢复运行了么?所以说分布式比集中式更安全!可能会有疑问了,既然分布式版本控制系统中每个人都拥有完整的版本库,那么两个人到底如何交流以谁的版本为准呢?一个版本,两个版本还好,假设有100个版本库呢?实际上,这并不重要,假设有100个人在合作开发一个项目,而你作为项目负责人,你可能并不关心100人的全部工作细节,在乎的只是最终成果,而这些成果是由10个项目组长提交维护的,所以你关心的只是10个版本,假设没有集中式的中央服务器角色,那么你需要手动合并10个版本库,最终完成项目.这样看起来中央服务器确实还是有存在的必要,为了方便不同版本库之间进行交流,通常分布式版本控制系统也有一台充当中央服务器角色的电脑,需要理解的是,此时中央服务器的作用仅仅是方便大家交换各自的修改而已,没有它,大家还是可以照常工作的,只是彼此间交换修改不太方便而已!不论是分布式还是集中式,存在即合理,如何取舍有着各自应用场景,分别代表民主和专制.git 和 svngit 是分布式版本控制系统的代表,除此之外还有BitKeeper,Mercurial,Bazaar 等分布式控制系统,每种分布式控制系统均有自身特点,毋容置疑的是git是最简单最流行!svn 是集中式版本控制系统的代表,是目前使用最广泛的集中式版本控制系统,cvs ClearCase等均属于集中式.不论是分布式还是集中式,不论是免费还是收费,不一昧追求最好的,只需要最适合自己的即可.git 是分布式控制系统,svn 是集中式版本控制系统git 将内容按元数据方式存储,svn 是按文件方式存储git 的内容完整性优于svn,因为 git 内容存储基于sha-1哈希算法,确保内容的完整性.小结git 是Linus为了帮助管理 Linux 内核开发而开发的一个开放源码的版本控制软件.原文请访问 https://snowdreams1006.github.io/git/base/about.html

开发前准备了解产品和设计参加需求、交互、视觉会议，了解产品设计和项目成员。了解产品面向的设备和平台。了解产品对兼容性的要求以及是否采用响应式设计等。提出疑问和见解按需求结合现有技术，提出疑问和见解。提出可能存在的问题（技术实现，性能问题等），协商解决方案（如优雅降级、渐进增强）并达成共识。提出当下已掌握新技术可能在项目中的应用场景，协助产品创新。不要采用未掌握的技术创新。预算人力和时间根据项目工期要求及工作量，预算人力和时间。挑选前端成员组成前端小组，拟定技术选型。确定功能开发优先级，预算开发周期和阶段性产出。提醒需求方在项目管理平台（禅道）中创建项目并加入项目成员，提醒项目负责人创建git仓库并设置成员权限。开发过程职责任务确定前端小组长，负责对整个页面开发工作做统筹规划、分配协调等管理工作和主开发职责对交互原型和视觉设计有疑问，上报小组长，由小组长对外（需求方和设计师）交流。确认交互原型或视觉效果已经定稿，再开始开发工作。如果采取并行模式（视觉设计和页面开发同时进行），则以交互原型定稿为准（当视觉效果定稿后，页面工程师再补充细节），开始分配。按页面类型分配，同一类型页面分配给同一个人。每个人都要了解页面公共元素（多个页面中相同或相似部分），一个公共元素只分配到一个人，每人完成自身页面的同时完成“提取剥离”。在项目管理平台中细分开发任务，填写任务详情和时间，如果任务间存在关系，则设置好关联或从属关系。页面开发由小组长创建前端目录，包含“页面开发”目录（如:js、css、html、images）及“提取剥离”目录（如：demo）。由小组长创建公共样式以及js库版本（如：reset.css、resize.js）参考 Nec工程师规范未完待续

1 首先在windows下安装git（这个教程网上非常多，我就附个链接吧 )git安装2 本地打开git bash3 使用ssh-keygen命令生成自己的公钥和私钥。首先输入ssh-keygen，这里会提示你输入私钥保存的位置，直接回车使用默认位置即可，后面会两次提示输入密码 直接回车这里标红的两个文件 id_rsa和id_rsa.pub分别是私钥和公钥4 查看生成的秘钥 此时打开C:UsersAdministrator.ssh 文件夹（.ssh文件夹默认是隐藏的，要查看需要设置显示隐藏文件,或直接输入路径）。这是存放秘钥的文件夹。其中id_rsa是私钥文件，id_rsa.pub是公钥文件。5进入https://github.com，如果没有先注册账号，登录github。进入你的项目，依次点击setting->deploy keys->add deploy key6 添加公钥（公钥就是第三步中生成的id_rsa.pub文件） 填写表单 (titile可以随意填写,key就是将id_rsa.pub中的内容复制粘贴即可。) 勾选 allow write acssess, 点击add key.7本地拉取项目 git clone git@githb.com/xxxxx.git(你的git仓库地址，就是左侧code选项卡中，如下图标红的位置)注意 如果在拉取的过程中报错 Permission denied (publickey) 可以参考https://www.cnblogs.com/eooox…

1.在本地仓库的目录下调用命令行删除根目录下的.git文件夹，输入find . -name “.git” | xargs rm -Rf这样本地仓库就清除了，像下面这样，master不见了。2.手动删除掉残留的.git文件3.在命令行中输入rm -rf + github仓库地址，例rm -rf https://github.com/NeroSolomon/VLearning.git4.在github的对应的库中到setting删除库。

开发过程中，你肯定会遇到这样的场景：场景一：糟了，我刚把不想要的代码，commit到本地仓库中了，但是还没有做push操作！场景二：彻底完了，刚线上更新的代码出现问题了，需要还原这次提交的代码！场景三：刚才我发现之前的某次提交太愚蠢了，现在想要干掉它！撤销上述场景一，在未进行git push前的所有操作，都是在“本地仓库”中执行的。我们暂且将“本地仓库”的代码还原操作叫做“撤销”！情况一：文件被修改了，但未执行git add操作(working tree内撤销)git checkout fileNamegit checkout .情况二：同时对多个文件执行了git add操作，但本次只想提交其中一部分文件$ git add *$ git status# 取消暂存$ git reset HEAD <filename>情况三：文件执行了git add操作，但想撤销对其的修改（index内回滚）# 取消暂存git reset HEAD fileName# 撤销修改git checkout fileName情况四：修改的文件已被git commit，但想再次修改不再产生新的Commit# 修改最后一次提交 $ git add sample.txt$ git commit –amend -m"说明"情况五：已在本地进行了多次git commit操作，现在想撤销到其中某次Commitgit reset [–hard|soft|mixed|merge|keep] [commit|HEAD]具体参数和使用说明，请查看：Git Pro深入浅出（二）中的重置揭秘部分回滚上述场景二，已进行git push，即已推送到“远程仓库”中。我们将已被提交到“远程仓库”的代码还原操作叫做“回滚”！注意：对远程仓库做回滚操作是有风险的，需提前做好备份和通知其他团队成员！如果你每次更新线上，都会打tag，那恭喜你，你可以很快的处理上述场景二的情况git checkout <tag>如果你回到当前HEAD指向git checkout <branch_name>情况一：撤销指定文件到指定版本# 查看指定文件的历史版本git log <filename># 回滚到指定commitIDgit checkout <commitID> <filename>情况二：删除最后一次远程提交方式一：使用revertgit revert HEADgit push origin master方式二：使用resetgit reset –hard HEAD^git push origin master -f二者区别：revert是放弃指定提交的修改，但是会生成一次新的提交，需要填写提交注释，以前的历史记录都在；reset是指将HEAD指针指到指定提交，历史记录中不会出现放弃的提交记录。情况三：回滚某次提交# 找到要回滚的commitIDgit loggit revert commitID删除某次提交git log –oneline -n5git rebase -i “commit id”^注意：需要注意最后的^号，意思是commit id的前一次提交git rebase -i “5b3ba7a”^在编辑框中删除相关commit，如pick 5b3ba7a test2，然后保存退出（如果遇到冲突需要先解决冲突）！git push origin master -f通过上述操作，如果你想对历史多个commit进行处理或者，可以选择git rebase -i，只需删除对应的记录就好。rebase还可对 commit 消息进行编辑，以及合并多个commit。git撤销、回滚操作 ...

git 放弃本地commit，强制使用远程commitgit fetch –allgit reset –hard origin/mastergit 放弃本地暂存文件git reset HEAD .git 放弃本地修改（未暂存）git checkout – .git 放弃未跟踪文件交互模式git clean -igit 删除远程分支git push origin -d branch_namegit 删除本地分支git branch -d branch_namegit 拉取远程分支git checkout -b 本地分支名x origin/远程分支名xgit 版本回退（谨慎使用）git reset –soft commit # 回退到某个 commit 并保留目前的版本到暂存区git reset commit # 回退到某个 commit 并保留目前的版本到工作目录git reset –hard commit # 回退到某个 commit 并丢弃暂存区和工作目录git push -f -u origin master # 将回退的版本强制提交到远程服务器

本文首发地址hilsion的博客 今天遇到一个在使用git上的一个误区。具体的问题现象是： 我commit后再pull而不能在本地合并的情况，结果导致我的commit直接把同事的修改覆盖了。因为相对于我此次的commit的A版本是同事的提交的B版本的上一个C版本，我直接是对C版本进行的修改，就是因为我没有先把同事的B版本先pull下来在本地产生一个最新的版本的合并。 我一直都是先commit后再pull，这样能“避免”冲突，事实上这样肯定不行，这样会导致你的commit不是基于最新的版本来进行的，而是上一个版本，这其中有其他的提交而在服务器上产生了最新的版本。而这样避免冲突的方式是错误的，更像是躲开了冲突。正确的操作是先pull下来，再添加，然后冲突解决，然后提交推送. 下面有一个简单的图示：

一、安装和使用Cocopods网上已有很多教程，参考示例：CocoaPods安装教程二、组件库支持Cocopods方式引入1.创建远程代码仓库创建远程代码仓库（并不是podspec文件的仓库），此仓库放的是源代码。可以在GitHub上创建仓库。2.创建远程podspec仓库如果要发布到Cocopods的官方spec仓库（公开的），那么就不需要创建。当然私有库是需要创建的，在这一步两者不一样。公开库参考示例：发布开源库到Cocopods官方仓库3.创建本地代码工程可以使用pod命令创建，得到一个工程模板，并且可以根据需要配置工程，如下：命令创建工程模板pod lib create <组件库名>工程配置选择选择平台What platform do you want to use?? [ iOS / macOS ] iOS选择语言What language do you want to use?? [ Swift / ObjC ] ObjC是否自动生成一个用来做demo测试的模板库,建议Yes，后面方便测试 Would you like to include a demo application with your library? [ Yes / No ] Yes是否集成测试框架Which testing frameworks will you use? [ Specta / Kiwi / None ] NoneUI 测试Would you like to do view based testing? [ Yes / No ] No指定类前缀What is your class prefix? WT4.编写podspec文件如果用第三步的命令创建工程模板，那么在Podspec Metadata目录下已经自动生成了。如果是已有的工程或者库文件目录，也可以利用Pod命令自己制作.podspec文件，命令如下：pod spec cretae <组件库名>参考链接：podspec文件的具体说明5.验证cocoaPods索引文件命令如下：pod lib lint （从本地验证你的pod能否通过验证） pod spec lint （从本地和远程验证你的pod能否通过验证） pod lib lint –verbose （加–verbose可以显示详细的检测过程，出错时会显示详细的错误信息） pod lib lint –allow-warnings (允许警告，用来解决由于代码中存在警告导致不能通过校验的问题) pod lib lint –help （查看所有可选参数，可选参数可以加多个）6.本地测试库是否可用新建工程，切换到工程目录，执行命令pod init修改podfile文件, 并添加上本地库路径pod ‘库名’, :path => ‘/Users/xxx/Documents/库名’拉取pod代码：成功后可看到我们的库并没有在pods里面，而是在Development Pods里面，可用先检测代码有没有问题。7.提交工程代码提交工程代码到远程代码仓库，可以利用git或者svn进行代码版本管理，提交代码到GitHub等8.提交podspec文件开源库提交podspec文件到Cocopods官方仓库， 当然需要现在ocopods官方仓库中注册账号，命令如下：pod trunk me （检查是否注册trunk） pod trunk register <邮箱> <注册名字> –verbose （注册命令）注册完成之后会给你的邮箱发个邮件,进入邮箱邮件里面有个链接,需要点击确认一下.之后开始提交，切换到有.podspec文件的组件工程根目录执行命令pod trunk push <组件库名>.podspec pod trunk push <组件库名>.podspec –allow-warnings私有库提交podspec文件到远程podspec仓库，和Cocopods官方库不同的是，私有仓库需要先添加到本地仓库，再push到远程仓库，因为Cocopods默认已经添加到了本地仓库（默认为master），Mac系统可以查看文件目录(/.cocoapods/repos)， 私有库命令如下：添加到本地仓库, git@git.xxxx.git为远端podspec库的地址，成功之后目录（/.cocoapods/repos）除了master之外，新增了一个文件夹（<组件库名>）pod repo add <组件库名> git@git.xxxx.git查看是否添加成功pod repo listpush到远程podspec仓库pod repo push <podspec远端仓库名> <组件库名>.podspec9. 检查仓库是否发布成功pod搜索一下：pod search <组件库名>如果报错，搜索不到，建议更新下pod：pod update之后仍然搜索不到，那么进入CocoaPods缓存目录，删除缓存索引文件search_index.json：cd ~/Library/Caches/CocoaPods ls rm -f search_index.json10. pod库文件引入如果是开源库（公有的），修改podfile文件：pod ‘组件库名’如果是私有仓库，建议在podfile文件开头添加source源：source ‘https://github.com/CocoaPods/Specs.git' #官方仓库地址source ‘http://xxx/组件库.git’ #私有podspecs仓库地址最后执行命令进行安装：pod install三、Cocopods打包静态库 ...

标签（空格分隔）： git初始化配置git config –list 查看配置git config –global user.name 用户名git config –global user.email 邮箱~/Desktop ~表示向前系统的路径查看git历史记录git log 显示提交的历史记录git log –oneline 显示简短的历史记录git reflog 查看所有历史版本对比文件git diff 工作区和暂存区git diff –cached暂存区和历史区 也就是仓库里面git diff master 工作区和历史区版本回滚git checkout 文件名或者点 从暂存区将工作区覆盖掉,此时文件还没添加到暂存区，类似ctrl+z的效果git reset HEAD 文件名或者点 删除本次暂存区的提交 （文件被添加到暂存区了，想撤销）git reset –hard HEAD^ 回退到上一个版本git reset –hard commitID 回退到某个版本分支git checkout -b dev 创建并切换到dev分支git checkout dev 切换到dev分支git merge dev 将dev分支的提交合并到当前分支git revertgit revert 328392删除本地分支git branch -d 分支名称删除远程分支git push origin –delete 分支名称

git下载地址：https://git-scm.com/downloads安装完成，随便找一个文件夹，点击右键会有Git GUI Here和Git Bash Here就代表安装成功，一般只用Git Bash Here。git上传github项目，操作指令:$ git init$ git add .$ git status(查看上传项目的状态）$ git commit -m “命名这次的项目（或记录这次修改项目名称）"$ git remote add origin +github上面的该仓库的https/ssh$ git push -u origin master其实这次命令也不用记，当你在github中新建仓库后，就能看见(如下图)：看着这个操作，就会很顺溜的上传到仓库了，当你上传完后，刷新一下就能看到了。github项目的预览效果：第一种方法：首先：一定要记住这个站：http://htmlpreview.github.io/ ；其次是打开项目里面的index.html或者其他html页面，添加到上面网页中的【preview】框中，点击preview就可以预览了。第二种方法：在当前项目打开的html页面的链接前面添加【http://htmlpreview.github.io/?】哈哈哈，当然咱们用git不仅仅是在github中存咱们自己的项目，大部分还是为了公司的需求，还是要懂一点git操作指令地。git操作指令：git init(运行git)git add .(添加当前项目)git status(查看上传项目的状态)git diff(查看修改的内容） git config –list(检查已有的配置信息)git fetch(将远程仓库的分支及分支最新版本代码拉取到本地)git pull origin (拉取代码到本地，解决拉取代码发生的冲突)git push(推送提交本地仓库代码文件到远程仓库)git clone [url链接] (克隆下载远程仓库项目工程到本地工作区)git切换账号：git config user.name(查看用户名) git config user.email(查看邮箱地址） git config –global user.name “×××"(修改用户名)git config –global user.email “×××”(次改邮箱地址) ssh-keygen -t rsa -C “email@email.com”(本地创建ssh key) ssh -T git@github.com(验证是否成功)git cat ~/.ssh/id_rsa.pub(查看公钥地址)以上都是我自己的记录，也就是为了自己省事，以后方便自己查看指令（没有办法，自己不爱去死记这些东西）(′◉❥◉｀)

在学习了廖雪峰老师的git教程后把常用的命令总结了出来注：在使用这些命令前请安装好Git软件，地址：https://git-scm.com/downloads1、在建好的目录下来初始化一个git项目git init2、添加文件2.1、添加所有文件git add .2.2、添加指定文件git add 文件名eg: git add readme.md3、提交到仓库git commit -m “说明"eg: git commit -m “Update"4、查看仓库状态4.1、如果你修改了某个文件，我们可以通过以下命令来查看状态git status4.2、如果想知道某个文件具体修改了哪些内容，用以下命令git diff 文件名eg: git diff readme.md注：在确认修改无误后需要再次对修改的文件做git add 和 git commit命令来提交到仓库。5、显示从最近到最远的提交日志git log6、版本回退在Git中，用HEAD表示当前版本，也就是最新的提交，上一个版本就是HEAD^，上上一个版本就是HEAD^^，当然往上100个版本写100个^比较容易数不过来，所以写成HEAD~100。git reset –hard HEAD^7、不想回退版本找到回退之前的版本的commit版本值（sha1值），来进行反悔操作。git reset –hard commit值eg: git reset –hard f8dad 注: 这个值只需要取前五位即可。8、查看回退记录前面的反悔操作是建立在你还没关闭git bash窗口看得到回退前那个最新版本的commit id值，如果我们关闭了窗口后想反悔怎么办，使用以下命令来查看git relog

本文由云+社区发表作者：工程师小熊摘要：上一集我们一起入门学习了git的基本概念和git常用的操作，包括提交和同步代码、使用分支、出现代码冲突的解决办法、紧急保存现场和恢复现场的操作。学会以后已经足够我们使用Git参加协作开发了，但是在开发的过程中难免会出错，本文主要介绍版本控制的过程中出错了的场景，以及Git开发的一些技巧，让我们用的更流畅。上集回顾：Git的基本概念一个人使用Git时的代码版本控制–（提交、拉代码、分支操作）多人合作时的代码版本控制–（合并冲突、暂存代码）本文核心：后悔药-各种后悔操作（撤消commit,回滚，回退远程仓库等）哎呀，提交的时候漏了文件tag操作git忽略不想提交的文件后悔药撤消当前commit如果你发现刚刚的操作一不小心commit了，所幸你还没有推送到远程仓库，你可以用reset命令来撤消你的这次提交。reset命令的作用：重置HEAD(当前分支的版本顶端）到另外一个commit。我们的撤消当前提交的时候往往不希望我们此次提交的代码发生任何丢失，只是撤消掉commit的操作，以便我们继续修改文件。如果我们是想直接不要了这次commit的全部内容的任何修改我们将在下一小节讨论。来，我们先说一句蠢话来diss老板$ touch to_boss.txt$ echo ‘my boss is a bad guy!’ > to_boss.txt$ git add to_boss.txt$ git statusOn branch masterYour branch is up to date with ‘origin/master’.Changes to be committed: (use “git reset HEAD <file>…” to unstage) new file: to_boss.txt$ git commit -m “[+]骂了我的boss”[master 3d113a7] [+]骂了我的boss 1 file changed, 1 insertion(+) create mode 100644 to_boss.txt创建to_boss.txt文件，并向其写入了my boss is a bad guy!add然后status查看新文件已经加入跟踪commit提交了这次的修改好了，刚刚我们“不小心”diss了我们的老板，要是被发现就完了，所幸还没有push，要快点撤消这些提交，再换成一些好话才行。我们使用以下命令：$ git reset –soft head^$ git statusOn branch masterYour branch is behind ‘origin/master’ by 1 commit, and can be fast-forwarded. (use “git pull” to update your local branch)Changes to be committed: (use “git reset HEAD <file>…” to unstage) new file: to_boss.txt$ cat to_boss.txtmy boss is a bad guy!$ echo ‘my boss is a good boy!‘my boss is a good boy!$ echo ‘my boss is a good boy!’ > to_boss.txt$ cat to_boss.txtmy boss is a good boy!$ git add to_boss.txt$ git statusOn branch masterYour branch is behind ‘origin/master’ by 1 commit, and can be fast-forwarded. (use “git pull” to update your local branch)Changes to be committed: (use “git reset HEAD <file>…” to unstage) new file: to_boss.txt $ git commit -m “[]夸了我的boss”[master 8be46aa] []夸了我的boss 1 file changed, 1 insertion(+) create mode 100644 to_boss.txtgit reset –soft head^撤消了本次提交，将工作区恢复到了提交前但是已经add的状态将to_boss.txt的内容改成了my boss is a good boy!add然后commit提交好了，有惊无险，这就是撤消commit的操作。另一种情况是如果你想撤消commit的时候支持舍弃这次全部的修改就把git reset –soft head^改成git reset –hard head^，这样你本地修改就彻底丢掉了(慎用)，如果真用了想找回来怎么办？见救命的后悔药。当然了，你只要开心不加soft或hard参数也是安全的(相当于使用了–mixed参数)，只不过是撤消以后你的本次修改就会回到add之前的状态，你可以重新检视然后再做修改和commit。回退远程仓库要是我们做的更过分一点，直接把这次commit直接给push怎么办？要是被发现就全完了,我们来看看github上的远程仓库。upload successful完了，真的提交了（我刚刚push的）让我们冷静下来，用撤消当前commit的方法先撤消本地的commit,这次我们来试试用hard参数来撤消$ git reset –hard head^HEAD is now at 3f22a06 [+]add file time.txt$ git statusOn branch masterYour branch is behind ‘origin/master’ by 1 commit, and can be fast-forwarded. (use “git pull” to update your local branch)nothing to commit, working tree clean$ git push origin master –forceTotal 0 (delta 0), reused 0 (delta 0)To github.com:pzqu/git_test.git + 3d113a7…3f22a06 master -> master (forced update)使用git reset –hard head^回滚到上一个commit使用git status查看现在的工作区情况，提示Your branch is behind ‘origin/master’ by 1 commit,代表成功表了上一次的提示状态，nothing to commit, working tree clean代表这次的修改全没了，清理的算是一个彻底。如果还想找回来怎么办，我们还真是有办法让你找回来的，见救命的后悔药。git push origin master –force 命令强制提交到远程仓库(注意，如果是在团队合作的情况下，不到迫不得已不要给命令加–force参数) 让我们看看githubupload successful真的撤消了远程仓库，长舒一口气。暂存区（Stage）到工作区（Working Directory）如果我们刚刚执行了git reset –soft或者add等的操作，把一些东西加到了我们的暂存区，比如日志文件,我们就要把他们从暂存区拿出来。$ git statusOn branch masterYour branch is up to date with ‘origin/master’.Changes to be committed: (use “git reset HEAD <file>…” to unstage) new file: mysql.log $ git reset – mysql.log$ git statusOn branch masterYour branch is up to date with ‘origin/master’.Untracked files: (use “git add <file>…” to include in what will be committed) mysql.lognothing added to commit but untracked files present (use “git add” to track)status查看暂存区，里面有一个mysql.log被放进去了git reset – mysql.log把mysql.log取出来status可以看到真的取出来了 然后如果不要想这个文件的话再rm掉就好啦,但是如果这些文件每次自动生成都要用这种方式取出暂存区真的好累，我们可以用 git忽略不想提交的文件回滚文件到某个提交当我们想要把某个文件任意的回滚到某次提交上，而不改变其他文件的状态我们要怎么做呢？我们有两种情况，一种是，只是想在工作区有修改的文件，直接丢弃掉他现在的修改；第二种是想把这个文件回滚到以前的某一次提交。我们先来说第一种：取消文件在工作区的修改$ cat time.txt10:41$ echo 18:51 > time.txt$ git statusOn branch masterYour branch is up to date with ‘origin/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: time.txtno changes added to commit (use “git add” and/or “git commit -a”)$ cat time.txt18:51$ git checkout – time.txt$ cat time.txt10:41更新time.txt的内容，可以status看到他发生了变化git checkout – time.txt , 取消这次在工作区的修改，如果他已经被add加到了暂存区，那么这个命令就没有用了，他的意思是取消本次在工作区的修改，去上一次保存的地方。如果没有add就回到和版本库一样的状态；如果已经加到了暂存区，又做了修改，那么就回加到暂存区后的状态将文件回滚到任意的版本我们这里说的把文件回滚到以前的某个版本的状态，完整的含义是保持其他文件的内容不变，改变这个文件到以前的某个版本，然后修改到自己满意的样子和做下一次的提交。核心命令git checkout [<options>] [<branch>] – <file>…我们还是用time.txt这个文件来做试验,先搞三个版本出来，在这里我已经搞好了，来看看：版本1，time.txt内容00:50commit 35b66ed8e3ae2c63cc4ebf323831e3b917d2b1d4 (HEAD -> master, origin/master, origin/HEAD)Author: pzqu <pzqu@example.com>Date: Sun Dec 23 00:51:54 2018 +0800 []update time to 00:50版本2，time.txt内容18:51commit 856a74084bbf9b678467b2615b6c1f6bd686ecffAuthor: pzqu <pzqu@example.com>Date: Sat Dec 22 19:39:19 2018 +0800 []update time to 18:51版本3，time.txt内容10:41commit 3f22a0639f8d79bd4e329442f181342465dbf0b6Author: pzqu <pzqu@example.com>Date: Tue Dec 18 10:42:29 2018 +0800 [+]add file time.txt现在的是版本1，我们把版本3检出试试。$ git checkout 3f22a0639f8d – time.txt$ cat time.txt10:41$ git statusOn branch masterYour branch is up to date with ‘origin/master’.Changes to be committed: (use “git reset HEAD <file>…” to unstage) modified: time.txt使用checkout+commit id+– filename的组合，横跨版本2把历史版本3的time.txt搞出来了查看状态,time.txt被改变了我们来把time.txt恢复到版本1，同样的方法，因为版本1是上一次提交我们可以省略掉版本号$ git checkout – time.txt$ cat time.txt00:50看到了吧！只要用git checkout commit_id – filename的组合，想搞出哪个文件历史版本就搞出哪个。到了这里，你可能会很懵比,reset和checkout命令真的好像啊！都可以用来做撤消checkout语义上是把什么东西取出来，所以此命令用于从历史提交（或者暂存区域）中拷贝文件到工作目录，也可用于切换分支。reset语义上是重新设置，所以此命令把当前分支指向另一个位置，并且有选择的变动工作目录和索引。也用来在从历史仓库中复制文件到索引，而不动工作目录。还想不通可以给我发邮件：pzqu@qq.com救命的后悔药来到这里我已经很清楚的你的现况了，你的代码丢了现在一定非常的着急，不要慌，总是有办法找回他们的。但是前提是要保证你的项目根目录下.git文件夹是完整的，要是手动删除了里面的一些东西那就真完了。还要保证一点，你的代码以前是有过git追踪的，最少add过找回你丢失的历史记录Git提供了一个命令git reflog用来记录你的每一次命令，贴个图吧直观点：upload successful有没有发现，git reflog里的全部都是和改变目录树有关的，比如commit rebase reset merge，也就是说一定要有改变目录树的操作才恢复的回来像add这种操作就不能恢复了吗？那肯定不是，只是要用更麻烦点的方式来恢复git log是一样的，也可以看到所有分支的历史提交，不一样的是看不到已经被删除的 commit 记录和 reset rebase merge 的操作 我们可以看到git reflog前面的就是commit id，现在我们就可以用之前介绍过的方法来回滚版本了，撤消当前commit$ git reset –hard 856a740HEAD is now at 856a740 []update time to 18:51$ git log -1commit 856a74084bbf9b678467b2615b6c1f6bd686ecff (HEAD -> master)Author: pzqu <pzqu@example.com>Date: Sat Dec 22 19:39:19 2018 +0800 []update time to 18:51 $ git reset –hard 35b66edHEAD is now at 35b66ed []update time to 00:50$ git log -2commit 35b66ed8e3ae2c63cc4ebf323831e3b917d2b1d4 (HEAD -> master, origin/master, origin/HEAD)Author: pzqu <pzqu@example.com>Date: Sun Dec 23 00:51:54 2018 +0800 []update time to 00:50commit 856a74084bbf9b678467b2615b6c1f6bd686ecffAuthor: pzqu <pzqu@example.com>Date: Sat Dec 22 19:39:19 2018 +0800 []update time to 18:51根据git reflog返回的结果，用git reset –hard commit_id回退到856a740这个版本git log -1看近一行的日志，可以看到目前就在这了再根据git reflog的结果，用git reset –hard 35b66ed跑到这次提交git log -2看到两次提交的日志，我们就这么再穿梭过来了，就是这么爽 但是我们如果只是想把此提交给找回来，恢复他，那还是不要用reset的方式，可以用cherry-pick或者merge来做合并找回忘记提交的历史记录你之前没有commit过的文件，被删除掉了，或者被reset –hard的时候搞没了,这种情况可以说是相当的难搞了，所幸你以前做过add的操作把他放到过暂存区，那我们来试试找回来,先来创建一个灾难现场$ echo ‘my lose message’ > lose_file.txt$ git add lose_file.txt$ git statusOn branch masterYour branch is up to date with ‘origin/master’.Changes to be committed: (use “git reset HEAD <file>…” to unstage) new file: lose_file.txt$ git reset –hard 35b66ed8HEAD is now at 35b66ed []update time to 00:50$ git statusOn branch masterYour branch is up to date with ‘origin/master’.nothing to commit, working tree clean$ lsREADME.md need_stash.txt share_file.txt time.txt创建一个叫lose_file.txt的文件并写入内容my lose message，并把他加到暂存区用git reset –hard 35b66ed8用丢弃一切修改的方式来使现在的工作区恢复到35b66ed8版本，因为还没提交所以也就是恢复到当前的（head）版本。我们用status和ls再看，这个叫lose_file.txt的文件真的没了，完蛋了,第一反应用刚刚学到的命令git reflow会发现根本就不好使核心命令：git fsck –lost-found,他会通过一些神奇的方式把历史操作过的文件以某种算法算出来加到.git/lost-found文件夹里$ git fsck –lost-foundChecking object directories: 100% (256/256), done.Checking objects: 100% (3/3), done.dangling blob 7f5965523d2b9e850b39eb46e8e0f7c5755f6719dangling commit fdbb19cf4c5177003ea6610afd35cda117a41109dangling commit 8be46aa83f0fe90317b0c6b9c201ad994f8caeafdangling blob 11400c1d56142615deba941a7577d18f830f4d85dangling tree 3bd4c055afedc51df0326def49cf85af15994323dangling commit 3d113a773771c09b7c3bf34b9e974a697e04210adangling commit bfdc065df8adc44c8b69fa6826e75c5991e6cad0dangling tree c96ff73cb25b57ac49666a3e1e45e0abb8913296dangling blob d6d03143986adf15c806df227389947cf46bc6dedangling commit 7aa21bc382cdebe6371278d1af1041028b8a2b09这里涉及到git的一些低层的知识，我们可以看到这里有blob、commit、tree类型的数据，还有tag等类型的。他们是什么含义呢？upload successfulblob组件并不会对文件信息进行存储，而是对文件的内容进行记录commit组件在每次提交之后都会生成，当我们进行commit之后，首先会创建一个commit组件，之后把所有的文件信息创建一个tree组件,所以哪个blob代表什么文件都可以在tree 里找到 我们来看看怎么恢复刚刚不见了的lose_file.txt文件，在上面执行完git fsck –lost-found命令，返回的第一行blob我们看看他的内容git show 7f5965523d2b9e850b39eb46e8e0f7c5755f6719my lose messagegit show 7f5965523d2b9e850b39eb46e8e0f7c5755f6719 > lose_file.txt$ lsREADME.md lose_file.txt need_stash.txt share_file.txt time.txt看到没有，就是我们丢失的文件内容，这样就找回来了！ 我们再来看看commit tree的内容$ git cat-file -p fdbb19cf4c5177003ea6610afd35cda117a41109 tree 673f696143eb74ac5e82a46ca61438b2b2d3bbf4 parent e278392ccbf4361f27dc338c854c8a03daab8c49 parent 7b54a8ae74be7192586568c6e36dc5a813ff47cf author pzqu <pzqu@example.com> 1544951197 +0800 committer pzqu <pzqu@example.com> 1544951197 +0800 Merge branch ‘master’ of github.com:pzqu/git_test $ git ls-tree 3bd4c055afedc51df0326def49cf85af15994323 100644 blob c44be63b27a3ef835a0386a62ed168c91e680e87 share_file.txt用git cat-file -p可以看到commit的内容，可以选择把这个commit合并到我们的分支里，还是reset merge rebase cherry-pick这些命令来合commitgit ls-tree列出tree下面的文件名和id的记录信息，然后就可以根据这些来恢复文件了后记：如果你发现执行git fsck –lost-found的输出找不到你想要的，那么在执行完git fsck –lost-found后会出现一堆文件 在 .git/lost-found 文件夹里,我们不管他。可以用以下命令来输出近期修改的文件$ find .git/objects -type f | xargs ls -lt | sed 3q-r–r–r– 1 pzqu staff 32 12 23 12:19 .git/objects/7f/5965523d2b9e850b39eb46e8e0f7c5755f6719-r–r–r– 1 pzqu staff 15 12 23 01:51 .git/objects/e6/9de29bb2d1d6434b8b29ae775ad8c2e48c5391-r–r–r– 1 pzqu staff 162 12 23 00:51 .git/objects/35/b66ed8e3ae2c63cc4ebf323831e3b917d2b1d4$ git cat-file -t 7f5965523d2b9e850b39eb46e8e0f7c5755f6719blob$ git cat-file -p 7f5965523d2b9e850b39eb46e8e0f7c5755f6719my lose message$ git cat-file -t b2484b5ab58c5cb6ecd92dacc09b41b78e9b0001tree$ git cat-file -p b2484b5ab58c5cb6ecd92dacc09b41b78e9b0001100644 blob f9894f4195f4854cfc3e3c55960200adebbc3ac5 README.md100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 need_stash.txt100644 blob 83f50ec84c00f5935da8089bac192171cfda8621 share_file.txt100644 blob f0664bd6a49e268d3db47c508b08d865bc25f7bb time.txt这里用find .git/objects -type f | xargs ls -lt | sed 3q返回了近3个修改的文件,想要更多就改3q这个数值，比如你想输出100个就用100qgit cat-file -t 7f5965523d2b9e850b39eb46e8e0f7c5755f6719 就能看见文件类型 把最后一个/去掉 复制从objects/ 后面的所有东西放在-t后面git cat-file -p id就能看见文件内容，是不是很爽漏提交有时候会碰到我们已经commit但是有修改忘记了提交，想把他们放在刚刚的commit里面，这种时候怎么做呢？$ git log –name-status –pretty=oneline -135b66ed8e3ae2c63cc4ebf323831e3b917d2b1d4 (HEAD -> master, origin/master, origin/HEAD) []update time to 00:50M time.txt$ git statusOn branch masterYour branch is up to date with ‘origin/master’.Changes to be committed: (use “git reset HEAD <file>…” to unstage) new file: lose_file.txt new file: test_amend.txt $ git commit –amend –no-edit[master 31cc277] []update time to 00:50 Date: Sun Dec 23 00:51:54 2018 +0800 3 files changed, 2 insertions(+), 1 deletion(-) create mode 100644 lose_file.txt create mode 100644 test_amend.txt $ git log –name-status –pretty=oneline -131cc2774f0668b5b7c049a404284b19e9b40dc5d (HEAD -> master) []update time to 00:50A lose_file.txtA test_amend.txtM time.txt查看文件提交日志只有time.txtstage里还有新的修改在使用git commit –amend –no-edit合并到上一个提交里，如果不加–no-edit参数的话，会提示你来修改commit提示信息(这个命令也可以用在重复编辑commit message)。查看日志，合并提交成功！tag标签创建一个tag标签是一个类似于快照的东西，常常用于测试和发布版本。所以我们常常把tag名以版本号来命名，比如：v1.0beat1这样我们怎么创建标签呢？首先先切换到想打标签的分支，然后直接打就可以了。$ git branch dev/pzqu master release_v1.0$ git tag -a release_v1.0 -m “release v1.0”$ git tag release_v1.1$ git tagrelease_v1.0release_v1.1$ git push –tagsCounting objects: 2, done.Writing objects: 100% (2/2), 158 bytes | 158.00 KiB/s, done.Total 2 (delta 0), reused 0 (delta 0)To github.com:pzqu/git_test.git * [new tag] release_v1.0 -> release_v1.0 * [new tag] release_v1.1 -> release_v1.1切换到想打tag的分支创建名为release_v1.0带有信息release v1.0的tag创建的不带有tag的提交信息的release_v1.1git tag查看tag推送本地全部tag也可以推送单个tag$ git push origin release_v1.1Total 0 (delta 0), reused 0 (delta 0)To github.com:pzqu/git_test.git * [new tag] release_v1.1 -> release_v1.1我们来删除tag$ git tag -d release_v1.0Deleted tag ‘release_v1.0’ (was eb5d177)$ git push origin :refs/tags/release_v1.0To github.com:pzqu/git_test.git - [deleted] release_v1.0$ git tagrelease_v1.1本地删除名为release_v1.0的tag远程删除名为release_v1.0的tag对历史提交打tag先看看当前的log31cc277 (HEAD -> release_v1.0, tag: release_v1.1, origin/release_v1.0, master) []update time to 00:50856a740 []update time to 18:513f22a06 [+]add file time.txt4558a25 (origin/dev/pzqu, dev/pzqu) []test stashd9e018e []merge master to dev/pzqu比方说要对[]update time to 18:51这次提交打标签，它对应的commit id是856a740，敲入命令：$ git tag v.9 856a740$ git log –pretty=oneline –abbrev-commit31cc277 (HEAD -> release_v1.0, tag: release_v1.1, origin/release_v1.0, master) []update time to 00:50856a740 (tag: v0.9) []update time to 18:51成功打上git忽略不想提交的文件我们有两种情况，一种是我们根本就不想这些文件出现在git库里比如日志文件；另一种是git远程仓库里有这些文件，就像通用的配置文件，我们必须要在本地修改配置来适应运行环境，这种情况下我们不想每次提交的时候都去跟踪这些文件。忽略自动生成的垃圾文件、中间文件、敏感信息文件忽略文件的原则是：忽略操作系统自动生成的文件，比如缩略图等；忽略编译生成的中间文件、可执行文件等，也就是如果一个文件是通过另一个文件自动生成的，那自动生成的文件就没必要放进版本库，比如Java编译产生的.class文件；忽略你自己的带有敏感信息的配置文件，比如存放口令的配置文件。我们要怎么做呢？在Git工作区的根目录下创建一个特殊的.gitignore文件，然后把要忽略的文件名填进去，Git就会自动忽略这些文件。$ echo “.log” > .gitignore$ touch test.log$ touch test2.log$ ls -a . .git README.md need_stash.txt test.log test_amend.txt .. .gitignore lose_file.txt share_file.txt test2.log time.txt$ git status On branch release_v1.0 nothing to commit, working tree clean 创建并写入忽略规则*.log忽略全部以.log为后缀的文件 创建了test.log和test2.log * status查看，真是工作区是clean，新创建的文件没有被跟踪忽略远程存在，本地不想与远程同步的文件添加跟踪忽略核心命令：git update-index —assume-unchanged 文件名upload successful创建time.txt文件并写入10:41,提交到远程仓库使用命令git update-index —assume-unchanged加time.txt加到忽略名单里修改time.txt的内容为10:43status查看确实没有被跟踪 看远程仓库upload successful取消跟踪忽略核心命令：git update-index —no-assume-unchanged 文件名upload successfulpull同步远程仓库，真的没有更新刚刚被添加跟踪忽略的文件git update-index —no-assume-unchanged取消跟踪忽略status查看，出现文件的跟踪查看跟踪记录如果忘记了哪些文件被自己本地跟踪upload successful使用命令git update-index —assume-unchanged加time.txt加到忽略名单里使用git ls-files -v| grep ‘^h\ ‘命令可以看到小写h代表本地不跟踪的文件小结学完本文章，你将学会撤消commit,回滚暂存区，回滚工作区、回退远程仓库两种方法找回不小心丢失的文件提交的时候漏了文件，修改commit的提交信息tag操作，创建、创建有描述信息的tag、删除tag、删除远程tag、推送本地单个tag和全部taggit忽略自动生成的垃圾文件、中间文件、敏感信息文件；忽略远程存在，本地不想与远程同步的文件并恢复跟踪和查看哪些文件被跟踪注意事项理论上，git日常用到的命令是 diff show fetch rebase pull push checkout commit status 等，这些命令都不会导致代码丢失，假如害怕代码丢失，可以预先commit一次，再进行修改，但切记不可使用自己不熟悉的命令 任何命令，不要加上-f的强制参数，否则可能导致代码丢失建议多使用命令行，不要使用图形界面操作下集引用git官网廖雪峰的官方网站-git篇hexo博客部署到vps关于git reset –hard这个命令的惨痛教训Git 基础再学习之：git checkout – file如何理解git checkout – file和git reset HEAD – file此文已由腾讯云+社区在各渠道发布获取更多新鲜技术干货，可以关注我们腾讯云技术社区-云加社区官方号及知乎机构号 ...

Forked Repo一般地，本地 forked repo 有两个远端：upstream 指向原作者的 repoorigin 指向 forked repo更新方法# 切换到 master 分支git checkout master# 拉取原作者的 repogit pull upstream master:master# 更新 forked repogit push origin master:master# 更新 forked repo 的远端分支git remote update –prunePull Request 追踪特性pull request 会追踪发起它的远端分支（简称 PR 分支，本地副本被称为“本地PR 分支”），除非已被 merge 或者处于 close 状态。如果 pull request 被 merge，PR 分支可以被原作者删除。如果 pull request 被 close，PR 分支可以被原作者删除。一旦删除，该 pull request 就不能再被 reopen。预览 Pull Request 合并后的状态首先，更新 repo。其次，搭建预览现场。此时完全不用担心 conflict（除非 GitHub 网页已经指出）。git checkout -b [预览分支]git pull [发起 repo 的 URL] [发起分支]然后，预览（一般是测试）。最后，清理预览现场。git checkout mastergit branch -D [预览分支]解决 Pull Request 冲突GitHub 的 pull request 页面指出 PR 冲突，可用下列方法解决：首先，更新 repo。然后，将 master 分支合并到本地 PR 分支。此时必然发生 conflict，解决并新建 commit。建议使用 GitHub Desktop 或 IDE 来执行该步骤。最后，push 本地 PR 发起分支。此时，GitHub 上的 pull request 会追加 commit，并指出冲突已消除。Pull Request 与 IssueGitHub 中 pull request 和 issue 共用一套编号。可在页面末尾添加的 comment，称为 issue comment。相关的 API 都在这里。如果 commit message 包含fix / fixes / fixed / close / closes / closed / resolve / resolves / resolved等关键字加上#编号，一旦 commit 被加入 repo，相应的 issue 就会被 close。 ...

本文由云+社区发表作者：工程师小熊摘要：用了很久的Git和svn,由于总是眼高手低，没能静下心来写这些程序员日常开发最常用的知识点。现在准备开一个专题，专门来总结一下版本控制工具，让我们从git开始。完成本系列博客的阅读以后，你将掌握git的基本概念与git的基本命令，可以在本地随心所欲的完成代码的提交撤销保存修改等操作、可以流畅的参与多人协作，本文致力于快速的入门，如果涉及到更高级的功能需要进行更深一步的学习。本文核心点：Git的基本概念一个人使用Git时的代码版本控制–（提交、拉代码、分支操作）多人合作时的代码版本控制–（合并冲突、暂存代码）什么是Git简介git是世界上目前最先进的分布式版本控制系统,致力于团队、个人进行项目版本管理，完美的解决难以比较代码、难以合并代码、难以取消修改、难以在写当前代码的过程中保存未完成的修改去修改线上版本的bug等的痛点。git是一个非常强大的工具，但作为一个git使用者来说，不用完全学习Git的知识点与命令，因为有的命令的使用频率非常的低甚至数年都不会用到，让我们来由浅入深进行学习。git的历史git是linux的创始人linus，在付费版本控制工具BitMover收回对Linux社区免费使用权利的时候，一怒之下花费两个星期的时间写出来的。（牛笔的人）开始安装git选择自己的操作系统对应的git版本安装，安装成功后运行git version后，输出git版本则安装正确。git 官方： https://git-scm.com/downloads配置用户信息使用git config命令来配置用户名和邮箱git config –global user.name “pzqu” git config –global user.email pzqu@example.com如果用了 –global 选项，那么更改的配置文件就是位于你用户主目录下的那个，以后你所有的项目都会默认使用这里配置的用户信息。如果要在某个特定的项目中使用其他名字或者电邮，只要去掉 –global选项重新配置即可，新的设定保存在当前项目的 .git/config 文件里。使用git config user.name和git config user.email来检查是否成功，也可以直接用git config –list来列出全部git配置信息来查看创建git托管的项目假如我们创建一个项目叫make_money，先创建一个文件夹叫make_money，再使用git init命令创建git项目。# pzqu @ pzqu-pc in ~/Documents/code/test [0:05:29]$ mkdir make_money# pzqu @ pzqu-pc in ~/Documents/code/test [0:06:24]$ lsmake_money# pzqu @ pzqu-pc in ~/Documents/code/test [0:06:29]$ cd make_money# pzqu @ pzqu-pc in ~/Documents/code/test/make_money [0:07:10]$ git initInitialized empty Git repository in /Users/pzqu/Documents/code/test/make_money/.git/# pzqu @ pzqu-pc in ~/Documents/code/test/make_money on git:master o [0:07:12]$ ls -altotal 0drwxr-xr-x 3 pzqu staff 96 11 7 00:07 .drwxr-xr-x 3 pzqu staff 96 11 7 00:06 ..drwxr-xr-x 9 pzqu staff 288 11 7 00:07 .git创建成功以后，会出现一个叫.git的隐藏文件夹，这个就是你的git仓库，以后所有的git操作历史提交记录信息就全部记录在此了，只要这个文件夹在就可以记住我们的全部git操作工作区和暂存区在使用git的时候还要清楚暂存区和工作区的含义，参考廖雪峰的官方网站-git篇-工作区和暂存区常见情况提交代码新文件与修改# pzqu @ pzqu-pc in ~/Documents/code/test/git_test on git:master o [11:37:50]$ lsREADME.md# pzqu @ pzqu-pc in ~/Documents/code/test/git_test on git:master o [11:42:02]$ touch file1.txt# pzqu @ pzqu-pc in ~/Documents/code/test/git_test on git:master x [11:42:15]$ git add file1.txt# pzqu @ pzqu-pc in ~/Documents/code/test/git_test on git:master x [11:42:23]$ git statusOn branch masterYour branch is up to date with ‘origin/master’.Changes to be committed: (use “git reset HEAD <file>…” to unstage) new file: file1.txt# pzqu @ pzqu-pc in ~/Documents/code/test/git_test on git:master x [11:56:38]$ git commit -m “[+]add new file1.txt”[master 66cc488] [+]add new file1.txt 1 file changed, 0 insertions(+), 0 deletions(-) create mode 100644 file1.txt上图操作包含:创建新文件file1.txtadd 添加修改的内容到索引status 查看修改的内容commit 把索引提交到本地分支git add . ：监控工作区的状态树，此命令会把工作时的所有变化提交到暂存区，包括文件内容修改(modified)以及新文件(new)，但不包括被删除的文件。git add -u：他仅监控已经被add的文件（即tracked file），他会将被修改的文件提交到暂存区。add -u 不会提交新文件（untracked file）。（git add –update的缩写）git add -A ：是上面两个功能的合集（git add –all的缩写）upload successfulgit show 列出最近一次的提交对于commit：像这样，你不断对文件进行修改，然后不断提交修改到版本库里，就好比玩RPG游戏时，每通过一关就会自动把游戏状态存盘，如果某一关没过去，你还可以选择读取前一关的状态。有些时候，在打Boss之前，你会手动存盘，以便万一打Boss失败了，可以从最近的地方重新开始。Git也是一样，每当你觉得文件修改到一定程度的时候，就可以“保存一个快照”，这个快照在Git中被称为commit。一旦你把文件改乱了，或者误删了文件，还可以从最近的一个commit恢复，然后继续工作，而不是把几个月的工作成果全部丢失。删除文件# pzqu @ pzqu-pc in ~/Documents/code/test/git_test on git:master o [12:55:24]$ lsREADME.md file1.txt# pzqu @ pzqu-pc in ~/Documents/code/test/git_test on git:master o [12:55:25]$ git rm file1.txtrm ‘file1.txt’# pzqu @ pzqu-pc in ~/Documents/code/test/git_test on git:master x [12:55:30]$ lsREADME.md# pzqu @ pzqu-pc in ~/Documents/code/test/git_test on git:master x [12:55:32]$ git statusOn branch masterYour branch is ahead of ‘origin/master’ by 1 commit. (use “git push” to publish your local commits)Changes to be committed: (use “git reset HEAD <file>…” to unstage) deleted: file1.txt# pzqu @ pzqu-pc in ~/Documents/code/test/git_test on git:master x [12:55:40] C:128$ git commit -m “[-]delete file1.txt”[master e278392] [-]delete file1.txt 1 file changed, 0 insertions(+), 0 deletions(-) delete mode 100644 file1.txt上图操作包含:创建新文件file1.txtgit rm 删除file1.txt文件status 查看修改的内容commit 把索引提交到本地分支tip1: 如果没有用git rm删除文件，在本地删除文件后，git add一下再提交可以达到同样的效果tip2: 要是你加班太晚，头晕不小心删除了不想删除的文件怎么办？见下一篇：版本控制工具——Git常用操作（下）-后悔药拉代码方法一 pull# pzqu @ pzqu-pc in ~/Documents/code/test/git_test on git:master o [17:01:13]$ git pullremote: Enumerating objects: 4, done.remote: Counting objects: 100% (4/4), done.remote: Compressing objects: 100% (2/2), done.remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0Unpacking objects: 100% (3/3), done.From github.com:pzqu/git_test 5fd4d8f..7b54a8a master -> origin/masterMerge made by the ‘recursive’ strategy. share_file.txt | 1 + 1 file changed, 1 insertion(+) create mode 100644 share_file.txt上图命令：git pull查看本地仓库变化git logupload successful上图可以看到向远程仓库pull的时候，出现了两个新的commit，commit 7b54a8ae74…的提交信息为Create share_file.txt,另一个commit fdbb19cf4c51770的提交信息为Merge branch ‘master’ of github.com:pzqu/git_test。事实上主线只有一个提交，为什么会出现这种情况? 是因为pull其实会做两个操作拉远程仓库代码到本地自动与当前分支合并并生成一个合并成功的提交注意这里的第二个个步骤如果远程有人和你改了同一个文件就会出现一个冲突，这个时候git会提示你哪些文件有冲突，手动改了再提交一次就可以了。详情见合并冲突方法二 fetch我在远程修改了文件，向share_file.txt加了一行内容tom modify，此时拉代码。# pzqu @ pzqu-pc in ~/Documents/code/test/git_test on git:master o [21:07:21]$ git fetch# pzqu @ pzqu-pc in ~/Documents/code/test/git_test on git:master o [21:08:43]$ git rebase origin/masterFirst, rewinding head to replay your work on top of it…Applying: [+]add new file1.txtApplying: [-]delete file1.txt上图所示有以下两个操作fetch 拉取远端代码到本地rebase 把本地代码提交基于远端分支重新replay效果如下：upload successful上图是git log所输出的提交内容，刚刚pull的时候忘记把pull自动产生的merge提交到远程，rebase的时候把本地的提交放到了远程提交之后，看起来就是一条直线，比较优雅，也是推荐的方式。同样的，如果产生了冲突，详情见合并冲突分支操作创建分支分支是多人协同最经典的地方所在，我们来创建一个分支$ git checkout -b dev/pzqu origin/masterBranch ‘dev/pzqu’ set up to track remote branch ‘master’ from ‘origin’.Switched to a new branch ‘dev/pzqu’$ git branch* dev/pzqu mastergit checkout -b 分支名 其他分支,-b代表创建并切换到新建的分支，分支名代表新创建的分支叫什么名字，这里叫dev/pzqu ，其他分支代表基于哪一个分支来创建，这里基于远程的master分支origin/master，如果省略则代表基于当前分支git branch展示本地的分支情况，加-a参数可以展示全部的分支，包括远程分支在分支前，指明了现在所在的分支是dev/pzqu切换分支$ git checkout -b dev/pzqu2Switched to a new branch ‘dev/pzqu2’$ git branch dev/pzqu dev/pzqu2 master$ git checkout dev/pzquSwitched to branch ‘dev/pzqu’Your branch is up to date with ‘origin/master’.$ git branch* dev/pzqu dev/pzqu2 master基于当前分支创建了一个新的分支并自动切换过去dev/pzqu2git checkout 已存在的分支名切换分支回到dev/pzqu删除分支$ git branch* dev/pzqu dev/pzqu2 master $ git branch -D dev/pzqu2Deleted branch dev/pzqu2 (was 7c9be37).$ git branch* dev/pzqu master 位于dev/pzqu，删除了dev/pzqu2分支合并冲突合并同一个分支的冲突（常见）为了产生一个冲突，我在另一个地方向远程仓库提交了代码，更改share_file.txt文件，加了一行内容tom add for merge，本地修改同一个文件加了一行pzqu add for merge，并提交到本地，这样一来，本地和远程仓库的同一个文件就不一样了，一会拉代码一定会产生一个冲突。效果如下：upload successful一般rebase或pull冲突的时候，都会出现提示，然后git status会出现上图图示这个时候不可以进行任何分支切换和commit操作，按照他提示进行处理git status提示哪个文件是都被修改的，both modified，然后使用编辑器修改该文件，解决冲突解决完成后，git add 添加该冲突文件git rebase –continue，并更新commit message，完成整个rebase流程 我们来看看这个冲突的文件：upload successfulGit用<<<<<<<，=======，>>>>>>>标记出不同分支的内容，我们修改如下后保存：upload successfulgit add再git rebase –continue后完成rebase，效果如下，再push的远程仓库即可upload successful合并不同分支的代码产生冲突关于怎么创建分支与切换分支见创建分支和切换分支,这里只讨论合并时产生的冲突的情况，我们已经基于master分支创建了一个dev/pzqu分支$ git branch* dev/pzqu master切换到master分支，加一行master add for merge并提交，文件内容如下：$ cat share_file.txttom addtom modifytom add for mergepzqu add for mergemaster add for merge切换到dev/pzqu分支，向share_file.txt加入一行dev/pzqu add for merge并提交，现在share_file.txt内容如下：$ cat share_file.txttom addtom modifytom add for mergepzqu add for mergedev/pzqu add for merge现在两个分支的同一个文件内容不一样了，现在我们在dev/pzqu分支上进行合并：$ git merge masterAuto-merging share_file.txtCONFLICT (content): Merge conflict in share_file.txtAutomatic merge failed; fix conflicts and then commit the result.# pzqu @ pzqu-pc in ~/Documents/code/test/git_test on git:dev/pzqu x [11:17:31] C:1$ git statusOn branch dev/pzquYour branch is ahead of ‘origin/master’ by 1 commit. (use “git push” to publish your local commits)You have unmerged paths. (fix conflicts and run “git commit”) (use “git merge –abort” to abort the merge)Unmerged paths: (use “git add <file>…” to mark resolution) both modified: share_file.txtno changes added to commit (use “git add” and/or “git commit -a”)$ cat share_file.txttom addtom modifytom add for mergepzqu add for merge<<<<<<< HEADdev/pzqu add for merge=======master add for merge>>>>>>> master上图出现了一个冲突，是我们意料之中的，修改share_file.txt文件，解决此冲突：$ cat share_file.txttom addtom modifytom add for mergepzqu add for mergedev/pzqu add for mergemaster add for merge$ git add share_file.txt# pzqu @ pzqu-pc in ~/Documents/code/test/git_test on git:dev/pzqu x [11:22:40]$ git commit -m “[]merge master to dev/pzqu”[dev/pzqu d9e018e] []merge master to dev/pzqu# pzqu @ pzqu-pc in ~/Documents/code/test/git_test on git:dev/pzqu o [11:23:00]$ git statusOn branch dev/pzquYour branch is ahead of ‘origin/master’ by 3 commits. (use “git push” to publish your local commits)nothing to commit, working tree clean冲突解决也提交了，看看我们现在的分支内容：upload successful上图我们可以看到：master分支比远程origin/master分支多一次提交，dev/pzqu分支由于是基于origin/master分支，合并了master分支的提交和当前dev/pzqu分支的提交，超出本地master两个提交，致此我们把master合并到dev/pzqu的操作就完成了。通常我们开一个新的开发分支是为了在自己的分支上写代码，方便提交也不会把主线弄乱，现在我们用同样的方法将dev/pzqu合并到master分支，然后把两个分支都提交到远程。$ git checkout masterSwitched to branch ‘master’Your branch is ahead of ‘origin/master’ by 1 commit. (use “git push” to publish your local commits)$ git merge dev/pzquUpdating 58f047a..d9e018eFast-forward share_file.txt | 1 + 1 file changed, 1 insertion(+)$ git push origin masterTotal 0 (delta 0), reused 0 (delta 0)To github.com:pzqu/git_test.git 7c9be37..d9e018e master -> master $ git push origin dev/pzquCounting objects: 9, done.Delta compression using up to 8 threads.Compressing objects: 100% (9/9), done.Writing objects: 100% (9/9), 887 bytes | 887.00 KiB/s, done.Total 9 (delta 2), reused 0 (delta 0)remote: Resolving deltas: 100% (2/2), done.remote:remote: Create a pull request for ‘dev/pzqu’ on GitHub by visiting:remote: https://github.com/pzqu/git_test/pull/new/dev/pzquremote:To github.com:pzqu/git_test.git * [new branch] dev/pzqu -> dev/pzqu切换到master分支合并dev/pzqu到master分支master推到远程仓库如果dev/pzqu要保留，就可以推送到远程仓库。upload successful现在我们可以看到全部的分支都在一起了，强迫症都舒服了。暂存代码保存现场这种情况一般是出现在你正在完成一个功能，但是忽然线上发现了一个Bug，必须马上开一个新的分支来修复bug，但是现在的功能没写完不打算提交(commit)，现在怎么办？？不用怕暂存代码来帮助你。$ git statusOn branch dev/pzquYour branch is up to date with ‘origin/master’.Changes to be committed: (use “git reset HEAD <file>…” to unstage) new file: need_stash.txt modified: share_file.txt$ git stashSaved working directory and index state WIP on dev/pzqu: d9e018e []merge master to dev/pzqu$ git stash liststash@{0}: WIP on dev/pzqu: d9e018e []merge master to dev/pzqu$ git statusOn branch dev/pzquYour branch is up to date with ‘origin/master’.nothing to commit, working tree clean//省略操作：去创建一个Bug分支，修复他并完成与主线的合并，删除Bug分支。//省略操作：切回来当前分支继续开发//下面来恢复现场$ git stash apply stash@{0}On branch dev/pzquYour branch is up to date with ‘origin/master’.Changes to be committed: (use “git reset HEAD <file>…” to unstage) new file: need_stash.txtChanges 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: share_file.txtstatus查看到有2个文件修改没有提交stash把修改放到暂存区，并生成一个idstash list列出暂存区所有内容stash apply重新把暂存区内容放到本地这里的stash apply成功的把暂存区的一次暂存恢复到了本地，但是暂存区还有会保存这次暂存，如果想删除这次暂存要用git stash drop来删除；也可以用git stash pop，恢复最后一次暂存的同时把stash内容也删了。$ git stash drop stash@{0}Dropped stash@{0} (bfdc065df8adc44c8b69fa6826e75c5991e6cad0)$ git stash list好了，暂存区清干净了。 注意：要放到暂存区的文件一定要先通过git add加到index小结本文阅读结束以后，我们学会了Git的基本概念，知道git的作用、历史；学会安装配置Git，使用Git创建项目托管以及工作区和暂存区的概念学会Git的本地操作，提交、拉代码、创建切换删除分支操作，多人合作时的代码版本控制，学会了不同情况下的合并冲突、暂存代码操作下集预告Git常用操作（下）我计划给大家介绍以下点：后悔药-各种后悔操作（撤消commit,回滚，回退远程仓库等）哎呀，提交的时候漏了文件tag操作git忽略不想提交的文件注意事项理论上，git日常用到的命令是 diff show fetch rebase pull push checkout commit status 等，这些命令都不会导致代码丢失，假如害怕代码丢失，可以预先commit一次，再进行修改，但切记不可使用自己不熟悉的命令 任何命令，不要加上-f的强制参数，否则可能导致代码丢失建议多使用命令行，不要使用图形界面操作引用git官网廖雪峰的官方网站-git篇hexo博客部署到vps此文已由腾讯云+社区在各渠道发布获取更多新鲜技术干货，可以关注我们腾讯云技术社区-云加社区官方号及知乎机构号 ...

在日常工作中公司会用到gitlab托管代码，但是自己的一些项目会放到github上，这时就需要为每个托管平台设置ssh key。下面是具体操作：1.生成ssh-key进入到.ssh目录下，输入以下命令生成ssh-key，your_email@example.com填入自己的邮箱ssh-keygen -t rsa -C “your_email@example.com"此时第一次输入的文件名，如果直接按回车会自动生成私钥和公钥：id_rsa、id_rsa.pub；第二次和第三次是密码和确认密码，此时直接回车即可。2.将ssh-key添加到ssh agentssh-add 私钥文件名如果执行ssh-add时提示”Could not open a connection to your authentication agent”可以先执行命令：ssh-agent bash然后在重新运行ssh-add命令3.修改配置文件将不同的账号对应的不同的ssh key 和不同的远程服务器关联起来，这个配置是在config下配置的(如果没有config可以自己新建)Host github.com HostName github.com User git IdentityFile ~/.ssh/id_rsa_aHost git.gitlab.net HostName git.gitlab.net User git IdentityFile ~/.ssh/id_rsa_gitlab其中，Host和HostName填写git服务器的域名。IdentityFile指定私钥的路径。未加入配置文件的网站会自动应用id_rsa4.将id_rsa.pub 上传到GitHub或GitLab上测试下是否成功ssh -T git@gitlab.com出现welcome to gitlab！就代表连接成功了现在你的多个ssh key就可以使用了

本篇文章要解决的问题是: 本地git客户端和github账户邮箱不一致导致提交的commit不能够显示在github个人主页的contributions中4个步骤分别是:1. 将git的email修改成和github的邮箱对应修改邮箱地址:git config –global user.email “eamil@example.com"查看当前邮箱:git config user.email2. 将git中提交的的commit修改复制到git中执行:git config alias.change-commits ‘!’“f() { VAR=$1; OLD=$2; NEW=$3; shift 3; git filter-branch –env-filter "if [[ \"$`echo $VAR`\" = ‘$OLD’ ]]; then export $VAR=’$NEW’; fi" $@; }; f “然后执行下面这条命令,把命令中的邮箱地址换成你自己的: (HEAD3的意思是将最近提交的3次commit的邮箱设置成newEmail) git change-commits GIT_AUTHOR_EMAIL “oldEmail@example.com” “newEmail@example.com” HEAD3..HEAD3. 重新拉取代码并提交即可看到效果4. 删除修改commit时的备份(不是必须的)执行命令: git update-ref -d refs/original/refs/heads/master参考:https://stackoverflow.com/que…https://www.cnblogs.com/wyhli...http://lincolnge.github.io/pr…

拉项目git clone: 克隆远程仓库创建切换分支git branch [branch_name]: 创建分支git checkout [branch_name]: 切换分支git checkout -b [branch_name]：创建并切换分支提交git文件状态commit <–（git commit） stage <–（git add -A） modify提交到暂存区git add -A 提交所有变化（一般使用这个）git add -u 提交被修改(modified)和被删除(deleted)文件，不包括新文件(new)git add . 提交新文件(new)和被修改(modified)文件，不包括被删除(deleted)文件将暂存区改动提交到本地版本库git commit -m “message”推送到远程仓库git push [remote_name(默认origin)] [branch_name]拉取git fetch 从远程获取最新到本地，不会自动mergegit fetch orgin master 将远程仓库的master分支下载到本地当前branch中git log -p master ..origin/master 比较本地的master分支和origin/master分支的差别git merge origin/master //进行合并git pull [remote_name(默认origin)] [branch_name] 相当于是从远程获取最新版本并merge到本地一般情况下，用git pull比较省事，当然git fetch更安全一点。合并分支将test分支合并到developgit checkout developgit merge test

前言一般来说，我们从github克隆代码，有两个模式，一个是https模式，一个是ssh模式。如果我么没有建立ssh信任，是无法通过ssh模式克隆代码的。ssh模式有一个优势就是可以建立本地git工具和github服务器之间的信任，不需要使用账号密码登录，尤其是我们push origin提交服务器的时候，省去输入账号密码的步骤。场景系统：ubuntu 18.04工具：VSCode 1.31.1工具：git 2.17.1过程本地准备SSH-KEY打开终端，cd ~进入根目录，执行ssh keygen，一路回车，生成本地的SSH-KEY，在目录/home/myubuntu/.ssh下分别是id_rsa和id_rsa.pub文件。其中id_rsa.pub文件是公钥，另一个id_rsa是私钥。公约提供给服务器，私钥自己保留，在这里，服务器就是github。把SSH-KEY写入服务器登录github，访问https://github.com/settings/keys页面，主页面有两个模块SSH keys和GPG keys，我们需要使用的是SSH keys。右边页面有一个绿色按钮New SSH key，点击会出现添加栏，分别是Title和Key。把本地文件id_rsa.pub打开，可以在/home/myubuntu/.ssh下执行命令vi id_rsa.pub，完整复制粘贴到Key输入栏，Title可以随便命名，比如ubuntu key，点击下方的绿色按钮Add SSH key，保存成功。在本地终端执行命令ssh -T git@github.com，会用本地秘钥连接github主机，如果有提示You’ve successfully authenticated, but GitHub does not provide shell access.代表连接成功。这时候可以通过ssh从自己的github仓库拉取项目了。拉取数据的时候必须选择ssh地址，复制到本地终端，进入存放代码的目录，执行命令git clone git@github.com:No2015/vue-cli3-typescript.git。只有通过ssh拉取的项目才能通过ssh来控制。本地项目克隆完毕，安装依赖模块，正常运行之后。如果修改成功，可以通过命令行执行git add .、git commit -m ‘add all’,git push origin master三个命令提交代码。或者通过VSCode工具提供的快捷方式提交。因为有ssh签名的信任，账号密码都是免除了的，省事很多。结语之前搞了一小会儿，因为项目是通过https模式拉取下来的，ssh建立之后还是需要输入账号密码，折腾很长时间才发现，修改本地仓库的remote就好了，或者删除本地代码，重新通过ssh拉取新代码。修改本地仓库地址的命令是git remote set-url origin git@github.com:No2015/vue-cli3-typescript.git

git 本地仓库与远程仓库的强制合并错误提示： refusing to merge unrelated historiesThe local repository is out of date过程是这样的今天在本地新建了一个 git 仓库，并往里添加了一些文件，也在本地提交了几次。这时候再去 github 上新建了个仓库，然后把 github仓库添加到本地的仓库中。git remote add rime git@github.com:KyleBing/rime-wubi86-jidan.git可以看到已经添加了远程仓库：pull 远程仓库的内容：然后执行上传到 github 的时候出现下面错误：错误原因其实本地建的那个仓库和远程 github 仓库是两个独立的仓库，互不相关。如果在建完 github 后再 git clone 到本地就不会出现该问题了。解决办法git pull 有个 –allow-unrelated-histories 参数，是为了合并两个不相关的仓库的历史，这个可以通过 git pull –h 查看帮助。因为我们这两个仓库并没有冲突，可以直接合并:git pull rime master –allow-unrelated-histories这时候出现填写合并信息的窗口填写保存后，结果显示，合并成功。后续提交# 提交更新到 githubkyle-mbp:Rime Kyle$ git push rime master# 结果Counting objects: 38, done.Delta compression using up to 4 threads.Compressing objects: 100% (38/38), done.Writing objects: 100% (38/38), 1.85 MiB | 305.00 KiB/s, done.Total 38 (delta 20), reused 0 (delta 0)remote: Resolving deltas: 100% (20/20), done.To github.com:KyleBing/rime-wubi86-jidan.git 27c22af..bf39b8c master -> master查看历史记录是这样的，可以看到本地 master 和远程 master 已经合并在一起了：再看一下远程仓库的提交记录，已经能看到本地的提交记录了。结决 ...

Git 使用官方文档： https://git-scm.com/docGit与Github关联教程： https://www.cnblogs.com/flora...Git 远程操作详解： http://www.ruanyifeng.com/blo…推荐看看这本介绍 Git 的电子书，看完什么都知道了，介绍的很详细Git电子书下载 【PDF】 【EPUB】 【MOBI】我理解的 Git 是个什么东西Git是现在流行的VCS(“Centralized Version Control Systems” 版本控制系统)之一。版本控制系统主要目的是，控制项目不同版本，可随时回溯到任何需要的版本。如软件开发行业，版本控制系统扮演着不可或缺的重要角色。VCS可以把软件开发的各个岗位连接起来，各自完成自己的工作，且井井有条，前端和后台的工作同时进行。VCS可以把所有管理的文件都进行版本标记，如果任何文件修改出错，都可以随时恢复到前面的任何版本。说白了，VCS可以把开发人员紧密联合起来，大家同时进行开发，不会出现前后端融合错误。使用 git 每个用户都会在本地拥有 git 仓库的所有信息，过往记录，所以可以随时随地的提交代码。git 对文件版本的记录区别于其它 vcs， 其它vcs是对每个版本的文件进行标记，而 git 是对每个版本的所有文件进行快照，并根据项目内的所有文件计算出 hash 值来记录版本号。保证完整性。三种状态你的文件可能处于尺寸三种状态之一：已提交（committed）、已修改（modified）和已暂存（staged）由此引入 Git 项目的三个工作区域的概念：Git 仓库、工作目录以、暂存区域。基本的 Git 工作流程如下：在工作目录中修改文件。暂存文件，将文件的快照放入暂存区域。提交更新，找到暂存区域的文件，将快照永久性存储到 Git 仓库目录。安装windows 的我就不说了，需要的请自行百度。Mac 系统在安装 Xcode 的时候就会自动安装查看当前版本git –version# git version 2.17.2 (Apple Git-113)初次配置git 自带 git config 工具来修改 git 的配置文件/etc/gitconfig 系统上每一个用户及他们仓库的通用配置，带 –system 参数使用 git config 时，会读写这个文件 ~/.gitconfig 是只针对当前用户。 带 –global 参数可读写此文件当前目录是正在使用的仓库时，配置文件路径是 .git/config每一个级别覆盖上一级别的配置，所以 .git/config 的配置变量会覆盖 /etc/gitconfig 中的配置变量。用户信息安装完git，第一件事就是设置用户名和邮件地址，这些信息会在每次提交时使用$ git config –global user.name “John Doe”$ git config –global user.email johndoe@example.com指定git默认的文本编辑器默认的编辑器是 vim，如果你想自定义编辑器，可以通过这个指令指定：$ git config –global core.editor 编辑器名称查看配置信息git config –list 可以查看你的 git 配置信息$ git config –listuser.name=John Doeuser.email=johndoe@example.com…初始化 Git 仓库在当前目录下初始化仓库git init这个命令会将本目录初始化为一个代码仓库，并在目录中增加 .git 目录，里面是关于本仓库的所有信息。初始化之后，目录中的文件并没有加入到 git 的版本控制中，需要手动将文件添加到 git 的控制列表中，操作见下一步。$ git add .c$ git add LICENSE$ git commit -m ‘initial project versionGit 本地库的常规操作忽略特定文件在 git 管理的目录下 新建文件 .gitignore如：.[oa]~上面的文件意思是忽略所有以 .o .a 的文件，忽略以 ~ 结尾的文件.gitignore 的格式规范：空行 或 # 开头的行会被忽略可以使用标准的 glob 模式匹配以 / 开头防止递归以 / 结尾指定目录用 ! 反向选择glob shell 所使用的简化了的正则表达式 0个或任意个字符[abc] 任意其中一个字符? 匹配一个字符[0-9] 表示匹配任意中间的字符** 两个星表示任意中间目录 a/**/c a/b/c a/d/c查看当前状态git status查看当前目录下的文件状态，如果有文件未加入到跟踪中，会提示你。git status -s可以查看简短的报告git status -s M READMEMM RakefileA lib/git.rbM lib/simplegit.rb?? LICENSE.txt?? 表示未跟踪的文件A 表示新添加的文件MM 右边的M表示修改后未保存到暂存区，左边表示修改并放入了暂存区添加文件如果我们新建了一个名为 README 的文件，git status 会显示文件没有被跟踪，通过以下指令把文件添加到 git 的文件跟踪中。加入到跟踪中后，没有 commit 之前，文件处于暂存区。git add README如果这时候修改了 README 文件，再用 git status 查看状态的时候，会看到提示 changes not staged for commit，此时如果想在下次 commit 的时候提交这次修改，需要再次 git add 这个文件。git add 可以理解为标记文件到下次提交，而非只是添加文件到跟踪状态查看区别在修改了文件之后，没有添加到暂存区之前，可以用 git diff 查看前后版本的区别这是在文件没有添加到暂存区的时候的查看方式，在存入后，需要用 git diff –cached 来查看不同提交文件git commit这会打开默认的文本编辑器，让你输入此次提交的信息。就像平时用 vi 编辑文本那样，按 i 进入输入模式，然后输入你要写的话，再 esc wq 保存退出就会提交了。或者用简短的方式，直接在命令中输入此次提交的信息，多个 -m 参数会作为多个分段。git commit -m ‘初次提交’如果闲每次添加文件麻烦，可以用 -a 参数跳过添加到暂存区的操作，直接在提交的时候把所有已经跟踪的文件上传。git commit -a移除文件移除文件并取消该文件的跟踪，需要用 git rm 指令，并删除本地文件。如果只是在目录中删除了文件，在 git status 的时候会提示文件没有添加到跟踪中。如果文件已经添加到暂存区，且修改了文件还没有提交，此时删除文件就需要用 -f 参数了。只移除文件跟踪，不删除文件git rm -cached READMEgit rm 后面还可以跟 glob 模式的匹配字符串移动文件git mv 给文件重命名用这个指令其实它是三个指令的集合mv README.mb READMEgit rm README.mbgit add README所以用 git mv 会更方便一些。查看历史git log -p -2-p 显示不同版本的区别-2 显示最近的再次更新–stat 可以查看每次更新的简略信息–graph 以字符图的样子显示分支情况撤消操作有时候，在提交了之后发现有几个文件没有提交，可以用 git commit –amend。git commit -m “initial commit"git add forgotten_filegit commit –amend如果在你提交之后，在没有修改文件之前马上添加未提交的文件，再 –amend 就会打开上次提交的注释，接着编辑信息，然后再提交。Github 远程代码仓库的使用查看当前目录下的远程仓库 URLgit remotegit remote -v$ git remote -vdiary git@github.com:KyleBing/Diary.git (fetch)diary git@github.com:KyleBing/Diary.git (push)在URL前面如果显示 origin 那是 git 给 URL 仓库的默认名字，添加远程仓库git remote add tb git@github.com:KyleBing/TouchbarBBT.git这样就添加了 git@github.com:KyleBing/TouchbarBBT.git 的仓库，别名为 tb这时候拉取远程仓库内容的时候，直接用 tb 代替 git@github.com:KyleBing/TouchbarBBT.git从远程仓库拉取内容git fetch [仓库别名]这个指令会拉取远程仓库的所有内容，包括所有分支。git pull会拉取远程分支到当前分支，并自动合并。推送到远程仓库git push [仓库别名] [分支名]会将你的项目推送到远程查看远程仓库git remote show [仓库别名]在没有设置仓库别名的时候，git 会默认把这个仓库命名为 origin$ git remote show tb* remote tb Fetch URL: git@github.com:KyleBing/TouchbarBBT.git Push URL: git@github.com:KyleBing/TouchbarBBT.git HEAD branch: master Remote branch: master tracked Local ref configured for ‘git push’: master pushes to master (local out of date)给远程仓库重命名git remote rename origin tb重命名 origin 为 tbgit remote rm tb移除远程仓库 tb定义发布版本 tag查看标签git tag列出已有标签git tag -l ‘v1.8.5’只查看 v1.8.5 的相关版本v1.8.5v1.8.5-rc…创建 annotated 标签添加 annotated 标签，用 -a 参数git tag -a v1.4 -m “tag version info"git show v1.4可以查看标签和对应的提交信息创建 light-weight 标签git tag -v1.4 -lw不需要填写提交信息后期打标签查看过往提交记录，然后取一个记录的校验和的部分字符串，把该提交打成标签git log –pretty=online# 显示为86bc9a426f04817fe47c07685ac60e0fcdd33af9 (HEAD -> master, tb/master) 添加外部链接4200265a6990c78fb5d0667eb0bbb99ab2760fc0 Merge branch ‘master’ of github.com:KyleBing/TouchbarBBT6df11cb1ee1726291d8ef20da1a93773a8e40fff Last6529785f35f5f2fd6333d95430d46e6dc75c590f Update README.mdaa6a05ba99933e5505969d36f66191a499e7c2b8 文章发布前的版本7eaa5924d0b5e7675d90d9b31b8daedaacaca0ea 定稿4f2320c2dcbe5ccd9dac551817cbc90653fd377b 调整按钮尺寸大小，正在播放背景色改为黑色18dce9bf2c84183e9030d5f7e8431ca2c0504a57 Update README.mdaf58e9c024ecbe2994d0c3bb21ab112dbed008fa 更新说明文档04da2e77f336f87827e2cf5801305f075c45d7dd 添加默认 touchbar 文件，添加 最新 Touchbar 文件d797ff57fd5ff74c233c804fb627c7df04456595 Update README.mdd8a1f7ea817a0aa51ff5b2c1f075e064a9a323f7 Merge branch ‘master’ of github.com:KyleBing/TouchbarBBTf9075467294865fe1a31b0879aa2d11071fe1110 修改目录名字，添加实际照片51fde532cb2d1ef7197d14e66cdaaed46dc8be3a Create README.mdd0611a4e511641e772e56ec7c923291e254a54ad 初始化该仓库，添加基础的配置文件和基础的图标git tag -a v1.2 51fde共享标签git push 并不会把标签传送到远程仓库，显式的推送才会显示。git push origin v1.3用 –tags 会把所有不在远程服务器的标签都推送到服务器上git push origin –tags删除标签删除本地标签git tag -d v1.3检出标签git checkout 2.0Git 别名git 可以像系统那样设置别名git config –global alias.co checkoutgit config –global alias.br branchgit config –global alias.ci commitgit ci -m “infos”# 跟下面作用一样git commit -m “infos"分支如果项目中新建了三个文件，在提交的时候，Git 仓库中有五个对象：三个 blob 对象（保存着文件快照一个树对象（记录着目录结构和 blob对象索引）一个提交对象（包含着指向前述树对象的指针和所有提交信息）HEAD、 分支 master 是什么东西git 的分支，其实是指向不同提交版本的指针。在 git init 初始化的时候，默认生成了一个名为 master 的分支，其实它跟其它分支的等级是一样的，都只是一个分支，默认名为 master，只是我们都懒得给它改名罢了。git 还有一个名为 HEAD 的指针，作用是指向当前本地库正在的修改的分支，如上图，本地库正在 master 分支上做修改。创建分支git branch testing上面的指令的结果如上图，在当前版本上新建了一个名为 testing 的分支。git branch 只是创建一个分支，并不会切换到该分支。分支切换git checkout testing上述操作会把 HEAD 指针指向 testing 分支，作用如下图：当前在 testing 分支上，现在新建并提交一个文件，只会保存在 testing 分支上，而 master 分支还停留在前一个提交状态上，也就是说该文件只存在于 testing 分支上。效果如下图；master 没有动，testing 已经向前移动到了最新的节点。切换分支的时候会改变本地的目录结构切换分支的时候，本地文件会变到当前分支的目录结构上，如果由于特殊原因没法切换分支的时候，会提示切换分支失败。此时我们再切换回 master 分支并做修改后提交，master 指针就会指向新的提交节点。此时，master testing 分别处于不同的提交节点上，如下图： ...

问题描述线上项目有一个小bug，我修改了xx.js中的一行代码解决了问题，然后webpack打包，准备提交代码。git add .git status这时候我发现，git status的输出为：renamed: xx.1.js -> xx.2.js我发现这不太对啊：renamed虽然可以体现出来webpack打包的时候改掉文件名hash值这个重命名的过程，但不能体现我改了文件内容啊。我觉得应该这样输出才对：deleted: xx.1.jsnew file: xx.2.js于是开始找答案，看为什么和我想的不一样。问题解决搜了一圈，最终有些收获，结论先行：git把文件标为renamed的意思是并不是很具体的指这个文件重命名了。他是一个泛指，这是一个种所谓heuristic(启发式，不懂不懂)的用法。关于这个问题没有找到足够的资料，但是通过我的测试，发现：一个文件的改动的行数低于总行数的50%的，并且进行重命名操作就会出现这种被标为renamed的情况测试方法如下：a.txt，里面内容为0-99的数字，每个一行，共100行。把这个文件做commit重命名a.txt为b.txt删除49行内容，然后做add操作，然后做git status操作删除50行内容，然后做add操作，然后做git status操作删除51行内容，然后做add操作，然后做git status操作同时在找资料的时候我也尝试了下面两个链接里提到的方式，但是在我的版本(2.19.2.windows.1)都没有成功复现。参考文档git status shows rename but it’s incorrectWhat’s git’s heuristic for assigning content modifications to file paths

usuallyjsusuallyjs 是一个面向现代 Web 开发的 JavaScript 实用函数库。usuallyjs 基于 ES6 开发，抛弃了传统 Web 开发中 DOM 和 BOM 操作部分的内容，精选了一系列 Web 开发过程中最常用的、最实用的 JavaScript 函数。与 Vue、React、Angular等现代 Web 框架搭配使用，更好的服务于开发现代 Web 应用。GitHub文档安装和使用npm安装和使用通过 npm 使用如下命令安装：npm install –save-dev usuallyjs通过 es6 模块引用：import U from ‘usuallyjs’通过 node 模块引用：const U = require(‘usuallyjs’)浏览器安装和使用下载本存储库，在页面中通过 script 标签引入 dist 文件夹下的 usually.js 文件即可，建议使用压缩版本 usually.min.js。通过命名空间 U 调用相关的函数。如：<!DOCTYPE html><html> <head> <meta charset=“utf-8”> <title>usually浏览器安装和使用示例</title> <script src=“dist/usually.js”></script> </head> <body> <script> var a = U.random() </script> </body></html>浏览器兼容支持 IE9+ 和现代浏览器贡献在提出拉取请求之前，请务必阅读贡献指南。感谢所有为usuallyjs做出贡献的人！LICENSEMIT

忙里偷闲的时候，有一好友又来问我关于Git的命令问题。（为啥是又，因为关于这个问题，他至少问了我三四五六遍了……每次讲完，过段时间必定忘！！！也不知脑回路是咋整的？？？）为了让他这个经常记不住的童鞋不要每次都来问我相同的问题，我决定把他能用到的命令，都列出来，作用也标明。童鞋，下次自己来看文章啊~~~No.1 克隆远程仓库git clone 远程仓库名 例如：https://gitee.com/****/****No.2 查看远程分支git branch -a注：当前分支 仅有master一个远程分支 No.3 创建本地分支test,环境切换为test分支并推送至远程（此时test的所有内容均为master内容，也就是说，test分支是基于master的新的分支）git checkout -b test// 此时在文件夹中增加一个readme.txt文件(也就是说，test分支内容已更改)// 将test分支推送至远程git add .git commit -m “add readme.txt"git push –set-upstream origin test// 仅有第一次推送至远程时需要以上的push命令 // 在test分支之后更改内容推送至远程时 均使用git push即可No.4 多人协同开发过程中，出现场景为，同学A 在分支dev上开发，同学B在test上开发。此时同学B需要基于同学A的内容，开发新需求。操作步骤应为：将自己本地test分支推送至远程，确认无误后，切换为同学A的dev分支，同时基于dev分支创建新分支名为feature-dev，然后在新的分支上进行开发// 先拉取最新内容git pull// 切换至dev分支 git checkout dev// 查看当前所在分支git branch -a// 新建并切换至分支 feature-devgit checkout -b feature-dev// 此时再次查看当前所在分支git branch -a// 当前所在分支为feature-dev 进行一些内容操作 例如：增加两张图片git add .git commit -m “add photo"git push –set-upstream origin feature-dev// 此时已经将feature-dev分支推送至远程 // 接下来再修改内容需要add、commit、push即可No.5 现在情况是，我需要在同学A的dev分支上去合并我的feature-dev的东西，也就是说，我需要把我更改的内容，合并到人家dev的分支上。此时我应该做的是：git pull 先获取最新内容，然后切换至dev分支，然后合并我更改的内容// 拉取最新 切换至devgit pull git checkout dev// 此时在dev分支，准备合并feature-dev的内容git merge –squash feature-dev// –squash 当在feature-dev分支上提交过很多回时，使用此命令可以将多条commit合并为一条// 即为 多条合并 如果有错回退的时候也方便// 如果有冲突，解决冲突，如果没有冲突即可提交git add .git commit -m “dev merge feature-dev"git push// 此时合并已完成No.6 嗯，我还没想到有啥常用的，有啥需要补充的随时补充吧~~~ ...

Git命令环境：git客户端，gitlab网页端，putty客户端安装完git客户端之后生成公钥：ssh-keygen -t rsa -C “邮箱名@qq.com"更新下来：git pull查看修改：git status新增：git add .提交：git commit -m ‘提交注释’上传：git push:q：退出命令冲突解决方案，即gitlab覆盖我的（我并不作更新，否则冲突）：git checkout ‘main.html’下载：git clone git@gitlab.xxx.com:xxx/base.git注意：1）没有pull的情况下报错To gitlab.xxx.com:jbid/bid.git ! [rejected] master -> master (fetch first)error: failed to push some refs to ‘git@gitlab.xxx.com:jbid/bid.git’hint: Updates were rejected because the remote contains work that you dohint: not have locally. This is usually caused by another repository pushinghint: to the same ref. You may want to first integrate the remote changeshint: (e.g., ‘git pull …’) before pushing again.hint: See the ‘Note about fast-forwards’ in ‘git push –help’ for details.2）通过post传递对象时候(不过现在都用postman软件)：git:(post方法本地测试)curl -H “Content-Type:application/json;charset=utf-8” -X POST http://localhost:81/xxxinfo/reguser -d ‘{“sessionkey_3rd”: “c24f4a3b9f414ae54e46536649f61688”,“username”: “mingzi”,“password”: “123456”,“busilicence”: “00”,“mobile”: “具体手机号码”,“captcha”: “”}‘git:(post方法正式环境测试）：curl -H “Content-Type:application/json;charset=utf-8” -X POST https://bidmini.xxx.cn/xxxinf… -d ‘{“sessionkey_3rd”: “c24f4a3b9f414ae54e46536649f61688”,“username”: “名字”,“password”: “123456”,“busilicence”: “03”,“mobile”: “具体手机号码”,“captcha”: “”}‘3）git 实现post请求时候对windows系统的中文执行不了，下面文章链接是参考：https://blog.csdn.net/qq_2112… ...

分支操作git branch 创建分支git branch -b 创建并切换到新建的分支上git checkout 切换分支git branch 查看分支列表git branch -v 查看所有分支的最后一次操作git branch -vv 查看当前分支git brabch -b 分支名 origin/分支名 创建远程分支到本地git branch –merged 查看别的分支和当前分支合并过的分支git branch –no-merged 查看未与当前分支合并的分支git branch -d 分支名 删除本地分支git branch -D 分支名 强行删除分支git branch origin :分支名 删除远处仓库分支git merge 分支名 合并分支到当前分支上暂存操作git stash 暂存当前修改git stash apply 恢复最近的一次暂存git stash pop 恢复暂存并删除暂存记录git stash list 查看暂存列表git stash drop 暂存名(例：stash@{0}) 移除某次暂存git stash clear 清除暂存回退操作git reset –hard HEAD^ 回退到上一个版本git reset –hard ahdhs1(commit_id) 回退到某个版本git checkout – file撤销修改的文件(如果文件加入到了暂存区，则回退到暂存区的，如果文件加入到了版本库，则还原至加入版本库之后的状态)git reset HEAD file 撤回暂存区的文件修改到工作区标签操作git tag 标签名 添加标签(默认对当前版本)git tag 标签名 commit_id 对某一提交记录打标签git tag -a 标签名 -m ‘描述’ 创建新标签并增加备注git tag 列出所有标签列表git show 标签名 查看标签信息git tag -d 标签名 删除本地标签git push origin 标签名 推送标签到远程仓库git push origin –tags 推送所有标签到远程仓库git push origin :refs/tags/标签名 从远程仓库中删除标签其它操作常规操作git push origin test 推送本地分支到远程仓库git rm -r –cached 文件/文件夹名字 取消文件被版本控制git reflog 获取执行过的命令git log –graph 查看分支合并图git merge –no-ff -m ‘合并描述’ 分支名 不使用Fast forward方式合并，采用这种方式合并可以看到合并记录git check-ignore -v 文件名 查看忽略规则git add -f 文件名 强制将文件提交git创建项目仓库1、git init 初始化2、git remote add origin url 关联远程仓库3、git pull4、git fetch 获取远程仓库中所有的分支到本地忽略已加入到版本库中的文件1、git update-index –assume-unchanged file 忽略单个文件2、git rm -r –cached 文件/文件夹名字 (. 忽略全部文件)取消忽略文件git update-index –no-assume-unchanged file拉取、上传免密码git config –global credential.helper store ...

缘起读了“扔物线”老师的小册《Git 原理详解及实用指南》感觉收获良多，于是想写点东西做一个总结，即加深自己的印象也希望能给社区小伙伴一点帮助，写的不对的地方还请多多指导。身为一个初入前端半年的菜鸟，由伊始的只知道git是用来托管代码的工具到逐步了解中央版本控制系统与分布式版本控制系统(git)的原理与区别；从之前只会基本的add、commit、pull、push操作到使用stash、merge、reset方便得不亦乐乎，都得益于对git原理的深入理解，逼话少说，咋们直接进入正题。前方长篇预警…从了解版本控制系统开始所谓版本控制，就是在文件修改的历程中保留修改历史，可以方便的撤销（如同文本编辑的撤销操作一般，只是版本控制会复杂的多）之前对文件的修改。一个版本控制系统的三个核心内容：版本控制（最基本的功能），主动提交（commit历史）和远程仓库（协同开发）。中央式版本控制系统（VCS）工作模型主工程师搭好项目框架在公司服务器创建一个远程仓库，并提交代码其他人拉取代码，并行开发每个人独立负责一个功能，开发完成提交代码其他人随时拉取代码，保持同步分布式版本控制系统（DVCS）分布式与中央式的区别主要在于，分布式除了远程仓库之外团队中每一个成员的机器上都有一份本地仓库，每个人在自己的机器上就可以进行提交代码，查看版本，切换分支等操作而不需要完全依赖网络环境。工作模型主工程师搭好项目框架 ，并提交代码到本地仓库在公司服务器创建一个远程仓库，并将1的提交推送到远程仓库其他人把远程仓库所有内容克隆到本地，拥有了各自的本地仓库，开始并行开发每个人独立负责一个功能，可以把每一个小改动提交到本地（由于本地提交无需立即上传到远程仓库，所以每一步提交不必是一个完整功能，而可以是功能中的一个步骤或块）功能开发完毕，将和这个功能相关的所有提交从本地推送到远程仓库每次当有人把新的提交推送到远程仓库的时候，其他人就可以选择把这些提交同步到自己的机器上，并把它们和自己的本地代码合并分布式版本管理系统的优缺点：优点大多数操作本地进行，数度更快，不受网络与物理位置限制，不联网也可以提交代码、查看历史、切换分支等等分布提交代码，提交更细利于review缺点初次clone时间较长本地占用存储高于中央式系统继续深入git原理假设你已经安装好了git并将代码clone到了本地，新手移步git安装与代码拷贝指南。git最基本的工作模型首先理解三个基本概念：工作区：就是你在电脑里能看到的目录版本库：工作区有一个隐藏目录.git，这个不算工作区，而是Git的本地版本库,你的所有版本信息都会存在这里暂存区：英文叫stage, 或index。一般存放在 “.git目录下” 下的index文件（.git/index）中，所以我们把暂存区有时也叫作索引（index）工作模型1.首先新建一个test.txt文件并对其进行修改，通过status可以查看工作目录当前状态，此时test.txt对git来说是不存在的（Untracked）2.然后通过add命令将修改放入暂存区（git开始追踪它）可以看到，test.txt 的文字变成了绿色，它的前面多了「new file:」的标记，而它的描述也从 “Untracked files” 变成了 “Changes to be commited”。这些都说明一点：test.txt 这个文件的状态从 “untracked”（未跟踪）变成了 “staged”（已暂存），意思是这个文件中被改动的部分（也就是这整个文件）被记录进了 staging area（暂存区）<blockquote> stage 这个词在 Git 里，是「集中收集改动以待提交」的意思；而 staging area ，就是一个「汇集待提交的文件改动的地方」。简称「暂存」和「暂存区」。至于 staged 表示「已暂存」，就不用再解释了吧？</blockquote>3.现在文件已经放入暂存区，可以用commit命令提交：在这里你也可以直接commit提交会进入commit信息编辑页面，而加上-m参数可以快捷输入简短的提交备注信息，这样你就完成了一次提交（可以通过git log查看提交历史）接着对该文件再次进行修改，输入git status可以看到，该文件 又变红了，不过这次它左边的文字不是 “New file:” 而是 “modified:"，而且上方显示它的状态也不是 “Untracked” 而是 “not staged for commit”，意思很明确：Git 已经认识这个文件了，它不是个新文件，但它有了一些改动。所以虽然状态的显示有点不同，但处理方式还是一样的：接下来再次将该文件add、commit，查看log可以看到已经存在两条提交记录4.最后通过push把本地的所有commit上传到远程仓库：团队工作基本模型工作模型1.在上面基本操作的基础上，同事 commit 代码到他的本地，并 push 到远程仓库2.你把远程仓库新的提交通过 pull指令拉取到你的本地通过这个流程，你和同事就可以简单地合作了：你写了代码，commit，push 到远程仓库，然后他 pull 到他的本地；他再写代码，commit, push 到远程仓库，然后你再 pull 到你的本地。你来我往，配合得不亦乐乎。（但是有时候push会失败）为什么会失败？因为 Git 的push 其实是用本地仓库的commit记录去覆盖远程仓库的commit记录（注：这是简化概念后的说法，push 的实质和这个说法略有不同），而如果在远程仓库含有本地没有的commit的时候，push （如果成功）将会导致远端的commit被擦掉。这种结果当然是不可行的，因此 Git 会在 push 的时候进行检查，如果出现这样的情况，push 就会失败这时只需要先通过git pull（实为fetch和merge的组合操作）将本地仓库的提交和远程仓库的提交进行合并，然后再push就可以了Feature Branching：最流行的工作流核心：（1）任何新的功能（feature）或 bug 修复全都新建一个 branch 来写；（2）branch 写完后，合并到 master，然后删掉这个 branch（可使用git origin -d 分支名删除远程仓库的分支）。优势：（1）代码分享：写完之后可以在开发分支review之后再merge到master分支（2）一人多任务：当正在开发接到更重要的新任务时，你只要稍微把目前未提交的代码简单收尾一下，然后做一个带有「未完成」标记的提交（例如，在提交信息里标上「TODO」），然后回到 master 去创建一个新的 branch 进行开发就好了。HEAD、branch、引用的本质以及push的本质HEAD：当前commit的引用当前 commit 在哪里，HEAD 就在哪里，这是一个永远自动指向当前 commit 的引用，所以你永远可以用 HEAD 来操作当前 commit，branch：HEAD 是 Git 中一个独特的引用，它是唯一的。而除了 HEAD 之外，Git 还有一种引用，叫做 branch（分支）。HEAD 除了可以指向 commit，还可以指向一个branch，当指向一个branch时，HEAD会通过branch间接指向当前commit，HEAD移动会带着branch一起移动：branch 包含了从初始 commit 到它的所有路径，而不是一条路径。并且，这些路径之间也是彼此平等的。像上图这样，master 在合并了 branch1 之后，从初始 commit 到 master 有了两条路径。这时，master 的串就包含了 1 2 3 4 7 和 1 2 5 6 7 这两条路径。而且，这两条路径是平等的，1 2 3 4 7 这条路径并不会因为它是「原生路径」而拥有任何的特别之处创建branch：git branch 名称切换branch：git checkout 名称（将HEAD指向该branch）创建+切换：git checkout -b 名称在切换到新的 branch 后，再次 commit 时 HEAD 就会带着新的 branch 移动了：而这个时候，如果你再切换到 master 去 commit，就会真正地出现分叉了：删除branch：git branch -d 名称注意：（1）HEAD 指向的 branch 不能删除。如果要删除 HEAD 指向的 branch，需要先用 checkout 把 HEAD 指向其他地方。（2）由于 Git 中的 branch 只是一个引用，所以删除 branch 的操作也只会删掉这个引用，并不会删除任何的 commit。（不过如果一个 commit 不在任何一个 branch 的「路径」上，或者换句话说，如果没有任何一个 branch 可以回溯到这条 commit（也许可以称为野生 commit？），那么在一定时间后，它会被 Git 的回收机制删除掉）（3）出于安全考虑，没有被合并到 master 过的 branch 在删除时会失败（怕误删未完成branch）把-d换成-D可以强制删除引用的本质所谓引用，其实就是一个个的字符串。这个字符串可以是一个 commit 的 SHA-1 码（例：c08de9a4d8771144cd23986f9f76c4ed729e69b0），也可以是一个 branch（例：ref: refs/heads/feature3）。Git 中的 HEAD 和每一个 branch 以及其他的引用，都是以文本文件的形式存储在本地仓库 .git 目录中，而 Git 在工作的时候，就是通过这些文本文件的内容来判断这些所谓的「引用」是指向谁的。push的本质：把 branch 上传到远程仓库（1）把当前branch位置上传到远程仓库，并把它路径上的commits一并上传（2）git中（2.0及以后版本），git push不加参数只能上传到从远程仓库clone或者pull下来的分支，如需push在本地创建的分支则需使用git push origin 分支名的命令（3）远端仓库的HEAD并不随push与本地一致，远端仓库HEAD永远指向默认分支（master），并随之移动（可以使用git br -r查看远程分支的HEAD指向）。开启git操作之旅merge：合并含义：从目标 commit 和当前 commit （即 HEAD 所指向的 commit）分叉的位置起，把目标 commit 的路径上的所有 commit 的内容一并应用到当前 commit，然后自动生成一个新的 commit。当执行git merge branch1操作，Git 会把 5 和 6 这两个 commit 的内容一并应用到 4 上，然后生成一个新的提交 7 。merge的特殊情况：（1）merge冲突：你的两个分支改了相同的内容，Git 不知道应该以哪个为准。如果在 merge 的时候发生了这种情况，Git 就会把问题交给你来决定。具体地，它会告诉你 merge 失败，以及失败的原因；这时候你只需要手动解决掉冲突并重新add、commit（改动不同文件或同一文件的不同行都不会产生冲突）；或者使用git merge –abort放弃解决冲突，取消merge（2）HEAD 领先于目标 commit：merge是一个空操作：此时merge不会有任何反应。（3）HEAD 落后于 目标 commit且不存在分支（fast-forward）：git会直接把HEAD与其指向的branch（如果有的话）一起移动到目标commit。rebase：给commit序列重新设置基础点有些人不喜欢 merge，因为在 merge 之后，commit 历史就会出现分叉，这种分叉再汇合的结构会让有些人觉得混乱而难以管理。如果你不希望 commit 历史出现分叉，可以用 rebase 来代替 merge。可以看出，通过 rebase，5 和 6 两条 commits 把基础点从 2 换成了 4 。通过这样的方式，就让本来分叉了的提交历史重新回到了一条线。这种「重新设置基础点」的操作，就是 rebase 的含义。另外，在 rebase 之后，记得切回 master 再 merge 一下，把 master 移到最新的 commit。为什么要从 branch1 来 rebase，然后再切回 master 再 merge 一下这么麻烦，而不是直接在 master 上执行 rebase？从图中可以看出，rebase 后的每个 commit 虽然内容和 rebase 之前相同，但它们已经是不同的 commit 了（每个commit有唯一标志）。如果直接从 master 执行 rebase 的话，就会是下面这样：这就导致 master 上之前的两个最新 commit （3和4）被剔除了。如果这两个 commit 之前已经在远程仓库存在，这就会导致没法 push ：所以，为了避免和远程仓库发生冲突，一般不要从 master 向其他 branch 执行 rebase 操作。而如果是 master 以外的 branch 之间的 rebase（比如 branch1 和 branch2 之间），就不必这么多费一步，直接 rebase 就好。需要说明的是,rebase 是站在需要被 rebase 的 commit 上进行操作，这点和 merge 是不同的。stash：临时存放工作目录的改动stash 指令可以帮你把工作目录的内容全部放在你本地的一个独立的地方，它不会被提交，也不会被删除，你把东西放起来之后就可以去做你的临时工作了，做完以后再来取走，就可以继续之前手头的事了。操作步骤：（1）git stash可以加上save参数后面带备注信息（git stash save ‘备注信息’）（2）此时工作目录已经清空，可以切换到其他分支干其他事情了（3）git stash pop弹出第一个stash（该stash从历史stash中移除）；或者使用git stash apply达到相同的效果（该stash仍存在stash list中），同时可以使用git stash list查看stash历史记录并在apply后面加上指定的stash返回到该stash。注意：没有被track的文件会被git忽略而不被stash，如果想一起stash，加上-u参数。reflog：引用记录的log可以查看git的引用记录，不指定参数，默认显示HEAD的引用记录；如果不小心把分支删掉了，可以使用该命令查看引用记录，然后使用checkout切到该记录处重建分支即可。注意：不再被引用直接或间接指向的 commits 会在一定时间后被 Git 回收，所以使用 reflog 来找回被删除的 branch 的操作一定要及时，不然有可能会由于 commit 被回收而再也找不回来。看看我都改了什么log：查看已提交内容git log -p可以查看每个commit的改动细节（到改动文件的每一行）git log –stat查看简要统计（哪几个文件改动了）git show 指定commit 指定文件名查看指定commit的指定文件改动细节diff：查看未提交内容git diff –staged可以显示暂存区和上一条提交之间的不同。换句话说，这条指令可以让你看到「如果你立即输入 git commit，你将会提交什么」git diff可以显示工作目录和暂存区之间的不同。换句话说，这条指令可以让你看到「如果你现在把所有文件都 add，你会向暂存区中增加哪些内容」git diff HEAD可以显示工作目录和上一条提交之间的不同，它是上面这二者的内容相加。换句话说，这条指令可以让你看到「如果你现在把所有文件都 add 然后 git commit，你将会提交什么」（不过需要注意，没有被 Git 记录在案的文件（即从来没有被 add 过的文件，untracked files 并不会显示出来。因为对 Git 来说它并不存在）实质上，如果你把 HEAD 换成别的commit，也可以显示当前工作目录和这条 commit 的区别。刚刚提交的代码发现写错了怎么办？再提一个修复了错误的commit？可以是可以，不过还有一个更加优雅和简单的解决方法：commit –amend。具体做法：（1）修改好问题（2）将修改add到暂存区（3）使用git commit –amend提交修改，结果如下图：减少了一次无谓的commit。错误不是最新的提交而是倒数第二个？使用rebase -i（交互式rebase）：所谓「交互式 rebase」，就是在 rebase 的操作执行之前，你可以指定要 rebase 的 commit 链中的每一个 commit 是否需要进一步修改，那么你就可以利用这个特点，进行一次「原地 rebase」。操作过程：（1）git rebase -i HEAD^^说明：在 Git 中，有两个「偏移符号」： ^ 和 。^ 的用法：在 commit 的后面加一个或多个 ^ 号，可以把 commit 往回偏移，偏移的数量是 ^ 的数量。例如：master^ 表示 master 指向的 commit 之前的那个 commit； HEAD^^ 表示 HEAD 所指向的 commit 往前数两个 commit。 的用法：在 commit 的后面加上 ~ 号和一个数，可以把 commit 往回偏移，偏移的数量是 ~ 号后面的数。例如：HEAD~5 表示 HEAD 指向的 commit往前数 5 个 commit。上面这行代码表示，把当前 commit （ HEAD 所指向的 commit） rebase 到 HEAD 之前 2 个的 commit 上：(2)进入编辑页面，选择commit对应的操作，commit为正序排列，旧的在上，新的在下，前面黄色的为如何操作该commit，默认pick（直接应用该commit不做任何改变），修改第一个commit为edit（应用这个 commit，然后停下来等待继续修正）然后:wq退出编辑页面，此时rebase停在第二个commit的位置，此时可以对内容进行修改：（3）修改完后使用add，commit –amend将修改提交（4）git rebase –continue继续 rebase 过程，把后面的 commit 直接应用上去，这次交互式 rebase 的过程就完美结束了，你的那个倒数第二个写错的 commit 就也被修正了：想直接丢弃某次提交？reset –hard 丢弃最新的提交git reset –hard HEAD^HEAD^ 表示 HEAD 往回数一个位置的 commit ，上节刚说过，记得吧？用交互式 rebase 撤销历史提交操作步骤与修改历史提交类似，第二步把需要撤销的commit修改为drop，其他步骤不再赘述。用 rebase –onto 撤销提交git rebase –onto HEAD^^ HEAD^ branch1上面这行代码的意思是：以倒数第二个 commit 为起点（起点不包含在 rebase 序列里），branch1 为终点，rebase 到倒数第三个 commit 上。错误代码已经push？有的时候，代码 push 到了远程仓库，才发现有个 commit 写错了。这种问题的处理分两种情况：出错内容在自己的分支假如是某个你自己独立开发的 branch 出错了，不会影响到其他人，那没关系用前面几节讲的方法把写错的 commit 修改或者删除掉，然后再 push 上去就好了。但是此时会push报错，因为远程仓库包含本地没有的 commits（在本地已经被替换或被删除了），此时直接使用git push origin 分支名 -f强制push。问题内容已合并到master（1）增加新提交覆盖之前内容（2）使用git revert 指定commit它的用法很简单，你希望撤销哪个 commit，就把它填在后面。如：git revert HEAD^上面这行代码就会增加一条新的 commit，它的内容和倒数第二个 commit 是相反的，从而和倒数第二个 commit 相互抵消，达到撤销的效果。在 revert 完成之后，把新的 commit 再 push 上去，这个 commit 的内容就被撤销了。它和前面所介绍的撤销方式相比，最主要的区别是，这次改动只是被「反转」了，并没有在历史中消失掉，你的历史中会存在两条 commit ：一个原始 commit ，一个对它的反转 commit。reset：不止可以撤销提交git reset –hard 指定commit你的工作目录里的内容会被完全重置为和指定commit位置相同的内容。换句话说，就是你的未提交的修改会被全部擦掉。git reset –soft 指定commit会在重置 HEAD 和 branch 时，保留工作目录和暂存区中的内容，并把重置 HEAD 所带来的新的差异放进暂存区。什么是「重置 HEAD 所带来的新的差异」？就是这里：git reset –mixed（或者不加参数） 指定commit保留工作目录，并且清空暂存区。也就是说，工作目录的修改、暂存区的内容以及由 reset 所导致的新的文件差异，都会被放进工作区。简而言之，就是「把所有差异都混合（mixed）放在工作区中」。checkout：签出指定commitcheckout的本质是签出指定的commit，不止可以切换branch还可以指定commit作为参数，把HEAD移动到指定的commit上；与reset的区别在于只移动HEAD不改变绑定的branch；git checkout –detach可以把 HEAD 和 branch 脱离，直接指向当前 commit。最后希望我的总结能给大家带来些许帮助，也希望和大家一起学以致用，一起成长。最后，万分感谢扔老师的小册，强势安利《git原理详解与实用指南》，认准扔物线。 ...

ggit-npm-tool https://www.npmjs.com/package…文章后续更新，存入草稿时间长会被删， 希望谅解

目前cenots版本为7.2，自带git@1.8.3，为了体验新功能，将git进行更新首先将原git进行删除：# yum remove git安装依赖：# yum install curl-devel expat-devel gettext-devel openssl-devel zlib-devel下载最新git：# wget https://github.com/git/git/archive/v2.20.0.tar.gz编译并安装：# tar -zxf v2.20.0.tar.gz# cd git-2.20.0# sudo make prefix=/usr/local all# sudo make prefix=/usr/local install添加环境变量:# echo “export PATH=$PATH:/usr/local/git/bin” >> /etc/bashrc# source /etc/bashrc查看git# git –versiongit version 2.20.0参考资料：https://git-scm.com/book/en/v…

git 是分布式代码管理工具，越来越多的企业使用它。所以掌握git的使用至关重要。它的远端管理是基于ssh，所以在使用远端git的时候需要进行ssh配置。 ssh是一种免密登录，使用的rsa非对称加密来进行服务器认证；一、git 的ssh配置如下首先你需要拥有gitlab或是github的一套账号，然后设置git的user name 和 user email：1、全局配置账号# git 全局设置账号git config –global user.name “your name"git config –global user.email “your e-mail"2、根据 user name 和 user email 生成自己的ssh密钥cd $USER cd .ssh #如果存在，需要备份可以备份下，如果不需要可以直接覆盖ssh-keygen -t rsa -C “your e-mail” #生成 ssh执行结果：最终得到 id_rsa 和 id_rsa.pub3、gitlab上面添加ssh密钥，使用文件 id_rsa.pub。打开https://gitlab.company.com/ ，使用自己账号登录，然后添加ssh密钥；主页头像 -> profile -> SSH Keys -> Add key将id_rsa.pub文件中的内容添加上去，然后点击Add key；4、测试 ssh 链接gitlab.company.comssh git@gitlab.company.com#会出现如下提示，说明链接成功The authenticity of host ‘gitlab.company.com (100.98.137.229)’ can’t be established.RSA key fingerprint is SHA256:WiQ1s8RKGjQpO0ICFY3NV2Hs0axwIbrv6j6q0XJsdsc.RSA key fingerprint is MD5:6c:8d:0f:09:31:c9:08:9b:67:48:09:7c:d9:46:65:3e.Are you sure you want to continue connecting (yes/no)? yesWarning: Permanently added ‘gitlab.company.com,100.98.137.229’ (RSA) to the list of known hosts.PTY allocation request failed on channel 0Welcome to GitLab, your name!Connection to gitlab.company.com closed.二、git 的简单使用创建一个新的仓库git clone git@gitlab.company.com:yaoname/my-test-git-project.gitcd my-test-git-projecttouch README.mdgit add README.mdgit commit -m “add README"git push -u origin mastertouch .gitignorevi .gitignore #编辑git add .gitignoregit commit -m “add .gitignore"git push -u origin master本地仓库和远端仓库建立连接cd existing_foldergit initgit remote add origin git@gitlab.company.com:yourname/my-test-git-project.gitgit add .git commitgit push -u origin mastergit基本操作讲解The most commonly used git commands are: add Add file contents to the index bisect Find by binary search the change that introduced a bug branch List, create, or delete branches checkout Checkout a branch or paths to the working tree clone Clone a repository into a new directory commit Record changes to the repository diff Show changes between commits, commit and working tree, etc fetch Download objects and refs from another repository grep Print lines matching a pattern init Create an empty Git repository or reinitialize an existing one log Show commit logs merge Join two or more development histories together mv Move or rename a file, a directory, or a symlink pull Fetch from and merge with another repository or a local branch push Update remote refs along with associated objects rebase Forward-port local commits to the updated upstream head reset Reset current HEAD to the specified state rm Remove files from the working tree and from the index show Show various types of objects status Show the working tree status tag Create, list, delete or verify a tag object signed with GPG1、git 仓库初始化git init2、git 生成快照并且存入项目索引git add . #或 git add * 提交所有文件git add README.md #提交指定文件git add folder/ #提交某个文件夹下面的所有文件3、git 将项目多索引提交到本地仓库的当前分支下git commit -m ‘注解’ 4、git 将远端仓库信息更新到本地，并且merge到本地分支git pull origin master5、git 推送当前分支到远端分支git push origin master6、git 将远端仓库信息更新到本地，不合并到本地分支git fetch7、git 创建分支操作git branch -a #查看所有分支git branch –list #查看本地分支git branch feature/20181017.business.chao #创建分支git checkout feature/20181017.business.chao #切换分支#或直接创建并且切换git checkout -b feature/20181017.business01.chaogit push origin feature/20181017.business01.chao #推送到远端git pull origin feature/20181017.business01.chao #从远端拉取#删除git branch -d/-D feature/20181017.business01.chao #删除本地git push origin –delete feature/20181017.business01.chao #删除远端分8、git 查看当前分支的状态git status 9、git merge合并分支#当前分支 git checkout feature/20181017.business01.chaotouch 1.txtvi 1.txt # 编辑内容然后提交到远端git checkout git checkout feature/20181017.business.chaogit merge feature/20181017.business01.chao #合并本地分支10、git grep 查找当前分支文件中的内容git grep –text “test” #使用git grep -h 查看更多用法11、git diff 比较分支git diff master #比较两个分支的不同12、git log 查看commit记录git log -n 10 #查看最近10条提交记录13、git rm 删除文件以及索引touch 2.txtgit add 2.txtgit commit -m ‘add 2.txt’git rm 2.txt #删除已经提交到本地仓库的文件14、git tag 一般用来管理【里程碑】git checkout mastergit tag –list #查看所有标签git tag v1.0 #添加taggit tag –list ‘v1.*’ # 列出version为1的所有子版本15、git show 获取项目的详细信息git show #展示项目的各种类型commit eaa7f945204bed8f2b01d284d99fcf0b3ac3029eAuthor: chao <chao@yourcompany.com>Date: Wed Oct 17 06:16:26 2018 +0000 add READMEdiff –git a/README.md b/README.mdnew file mode 100644index 0000000..7088fed— /dev/null+++ b/README.md@@ -0,0 +1,5 @@++# this is repositry16、git rebase 重置当前的操作options,写的不错rebase详解git rebase branchName #消除本分支下面的commitgit rebase –continue #在rebase的过程中，也许会出现冲突(conflict). 在这种情况，Git会停止rebase并会让你去解决 冲突；在解决完冲突后，用"git-add"命令去更新这些内容的索引(index), 然后，你无需执行 git-commit,只要执行git rebase –abort #在任何时候，你可以用–abort参数来终止rebase的行动，并且"mywork” 分支会回到rebase开始前的状态17、git stash 储藏（临时保存到git栈中，独立于git分支管理之外。那个分支使用恢复到哪个分支就行了）#储藏使用名称和不使用名称保存未提交到仓库的（暂存和非暂存）git stash git stash save “stash-name-1”#变更统计git stash show#每次储藏git stash list#恢复到git版本管理中git stash pop #弹出栈#通过名字使用储藏git stash apply #删除git stash drop#清空git stash clear#直接使用stash创建分支git stash branch testbranch18、git revert 向前滚动的方式回滚，不会丢失源代码git revert commit_id 19、git reset 使用HEAD的状态的方式回滚，会丢失源代码git reset –hard HEAD^ #回退到上个版本git reset –hard HEAD~3 #回退到前3次提交之前，以此类推，回退到n次提交之前git reset –hard commit_id #退到/进到 指定commit的sha码git push origin HEAD –force #强推到远端,使用git push 推送推送失败20、git bisect 通过二进制搜索找到引入错误的更改git bisect start #开启查找git bisect good v2.6.18 git bisect bad master #查找报错的版本21、删除并忽略已经加入到git仓库的文件#查找到对应的文件find . -name .DS_Store -print0 | xargs -0 git rm -f –ignore-unmatch#加入git忽略echo .DS_Store >> ~/.gitignore#addgit add –all#提交忽略git commit -m ‘.DS_Store banished!’ ...

开发背景：年后回来公司业务不忙，闲暇时间了解一下node的使用场景，一篇文章吸引了我15个Nodejs应用场景，然后就被这个hexo框架吸引了，说时迟，那时快，赶紧动手搭建起来，网上找了好多资料一天时间才搭建完成，我的博客地址：博客，记录一下过程，以便以后学习。开始搭建学习新框架的一般步骤：中文文档撸一遍，跟着做（Hexo中文文档），一般都会有各种问题出现，当然直接成功的也有，很不幸，我就是出现问题的那一类，没关系，出现问题，解决问题的过程，才能学到更多东西；上网找一些hexo使用的教程，继续弄；这个时候要是再有问题就是很难解决的有针对性的问题了，继续上网找相关的解决办法；网上资源真的很多，很好用，只要想学没有找不到的东西，哈哈哈…一、安装前提：既然是node框架，肯定前提是你已经安装过Node.js(下载地址)，另外还需要你安装Git（下载地址）；如果你已经成功安装了上述程序后，接下来就是hexo的安装：$ npm install -g hexo-cli安装完成以后，需要初始化一下项目，执行下列命令：$ hexo init$ npm install完成以后，项目大概目录就是这样的：.├── _config.yml├── package.json├── scaffolds├── source| ├── _drafts| └── _posts└── themes_config.yml网站的配置信息，可以在此配置大部分的参数。后面发布到github上面时，有用到这个文件；package.json应用程序的信息。文件的其他部分的详细解释请看文档，此处只是记录一下搭建以及发布的过程，具体写文章的步骤，先不进行过多说明；接下来可以在本地启服务来查看一下项目的初始状态：$ npm install hexo-server –save$ hexo server效果大概就是下面的样子：我稍微修改了一下文字配置，可能你的会跟我的有点不一样，项目能启动就是成功了；二、发布到github并设置成个人博客1、github上新建一个仓库登录自己的github后，在界面右上角用户信息点击左边的加号，新建一个repository：然后给新建的仓库起个名字，注意：这个名字必须跟用户名一致，github才会默认设置成用户的博客：项目建好以后，就是一些信息的设置：设置页面里面有分支选项，如果有master分支，会默认成博客的首选代码；2、将本地搭建好的hexo发布到github上：将本地代码上传到github上的方法有很多：可以用Github Desktop,简单直观，但是需要把之前我们搭建好的项目生成的文件放到GitHub Desktop指定的位置，再上传，感觉不那么智能，还有点麻烦，所以我选择planB，耶！我可真是个小机灵鬼…下面是在项目中生成静态文件的命令：$ hexo generate简写，结果是一样的$ hexo g执行完以上代码，会在项目的根目录下生成public文件夹，选择planA的童鞋就可以将里面的所有文件用GitHub Desktop上传到github上了；而另外一种，就是在当前项目直接远程连接自己的github上传文件，这会涉及到SSH（关于SSH是什么，网上有很多详细说明，可以自己查找学习）安装插件：npm install hexo-deployer-git –save修改网站配置文件_config.yml,添加deploy信息：deploy: type: git repo: git@github.com:wjlilh/wjlilh.github.io.git branch: master 上面的repo的配置信息，替换成自己的项目名字生成SSH key:按照网上的教程生成ssh key的时候是直接ssh-add,但是失败了，调查问题，发现原因是因为，我是第一次使用ssh-agent代理，第一次需要首先执行以下命令，以后就不需要了（具体原来请参考此处链接）：$ ssh-agent bash以上命令回车，启动进程，后再输入命令：$ ssh-add ~/.ssh/id_rsa按照提示操作输入密码，这样就在c盘对应位置生成了ssh-key；配置github账户的ssh-key打开id_rsa.pub文件将一整串公钥拷贝下来进入你的github账户设置，在ssh and GPG keys中新增一个ssh key，如下 title随意，key填id_rsa.pub文件中内容，保存即可；验证是否连接成功：$ ssh -T git@github.com出现下面的语句说明你的ssh key已经配置好了Hi wispyoureyes! You’ve successfully authenticated, but GitHub does not provide shell access.ok,到了这一步，本地跟远程github的连接已经建立，在项目中，直接生成静态文件，上传就可以了：$ hexo clean //清除缓存文件db.json和已生成的静态文件public$ hexo g //生成网站静态文件到默认设置的public文件夹$ hexo d //部署网站到设定的仓库这样就完成了个人博客的github部署，直接打开过程中设置的地址就可以查看了，我的是：https://wjlilh.github.io/ ...

爬虫简介这是一个在未登录的情况下，根据企业名称搜索，爬取企业页面数据的采集程序注意: 这是一个比较简单的爬虫，基本上只用到了代理，没有用到其他的反反爬技术，不过由于爬取的数据比较多，适合刷解析技能的熟练度，所以高手勿进代码已经上传到GitHub上，有用还请给个星python版本：python2.7编码工具：pycharm数据存储：mysql爬虫结构：广度爬虫爬虫思路：先获取需要采集信息的公司：从数据库中获取获取字段：etid，etname将获取的数据存储的状态表中从状态表中获取数据，并更新状态表拼接初始URL：将etname和初始url进行拼接，获得初始网址将初始url放到一个列表中，获取HTML的时候如何出错，将出错的url放到另一个列表中，进行循环获取请求解析初始一级页面：验证查询的公司是否正确（？？）获取二级页面url将二级url放到一个列表中，获取HTML的时候如何出错，将出错的url放到另一个列表中，进行循环获取请求解析二级页面：获取的信息待定将公司的信息存储到数据库中：建表存储信息所建的表：企业主要信息： et_host_info工商信息： et_busi_info分支机构信息： et_branch_office软件著作权信息： et_container_copyright_info网站备案信息： et_conrainer_icp_info对外投资信息： et_foreign_investment_info融资信息： et_rongzi_info股东信息： et_stareholder_info商标信息： et_trademark_info微信公众号信息：et_wechat_list_info状态表： et_name_status看一下部分的结果图：

gitlab remote: The project you were looking for could not be found. 错误git clone 新项目进行开发时一直报 remote: The project you were looking for could not be found. 原因就是 username的问题解决方案://把 username 更换为自己的 username????1:git clone http://username@rdc.nansongx.com/gitl.tttgit????2：git clone -b dev https://11XX6@rdc.nansongx.com/gitl.tttgit

1.新建一个本地分支并切换到新建的那个分支：git checkout -b (新分支名)2.从一个分支切换到另一个分支：git checkout 分支名3.将代码恢复到最近的一次commit 时候的状态：git stash4.将代码从最近的一次commit的状态恢复到最新的进度：git stash pop5.将一个本地子分支合并到本地的master分支：先将分支切换到master分支，然后执行git merge 将要合并的子分支6.回退到某一次commit状态git reset –hard commit的id如果想要回退到上一个commit，同时要保留上一个commit之后新添加的内容，需要使用git reset –soft commit的id7.添加一个远程git仓库git remote add 别名 git仓库地址8.删除一个本地分支git branch -D 本地分支名9.git add 添加错文件后撤销操作git reset HEAD 被错误添加的文件名如果git reset HEAD后面什么都不加，就撤销上一次git add的全部内容10.使远端仓库回退到本地的commit状态：git push origin <分支名> –force11.更改本地分支的名字git branch -m oldName newName

git分支查看分支git branch //查看本地分支git branch -r //查看远端分支git branch -a //查看所有分支创建分支git branch [branch name] //创建本地分支切换分支git checkout [branch name] //切换分支git checkout -b [branch name] //创建+切换分支，相当于git branch & git checkout推送新分支git push origin [branch name]删除分支git branch -d [branch name] //删除本地分支git push origin :[branch name] //删除远端分支，分支前面的冒号代表删除git处理冲突当拉取下来的文件与本地修改的文件有冲突，先提交你的改变，或者先将你的改变暂时存储起来1、将本地修改存储起来git stash2、pull内容 git pull 3、还原暂存的内容git stash pop stash@{0}也可以简写git stash popgit放弃修改文件本地修改了文件但还未addgit checkout –filename //单个文件git checkout . //全部文件本地新增了文件还未addrm filename / rm dir -rf //单个文件 //直接删除文件git clean -xdf //全部文件// 删除新增文件，如果文件已经git add到缓存区，并不会删除已经git add提交到了暂存区git reset HEAD filename //单个文件git reset HEAD . //全部文件git add以及git commit之后git reset commit_id //commit_id是你回到的那个节点，可通过git log查看，可以只选前几位//撤销之后，已经commit的修改还在工作区git reset –hard commit_id//撤销之后，已经commit的修改将会删除，仍在工作区/暂存区的代码不会清除git另一个进程还在运行问题描述出现这种情况可能是git在执行的过程中，你中止之后异常，进程一直停留Another git process seems to be running in this repository, e.g.an editor opened by ‘git commit’. Please make sure all processesare terminated then try again. If it still fails, a git processmay have crashed in this repository earlier:remove the file manually to continue.问题原因因为进程的互斥，所以资源被上锁，但是由于进程突然崩溃，所以未来得及解锁，导致其他进程访问不了。问题解决打开隐藏文件夹选项，进入工作区文件目录的隐藏文件.git，把其中的index.lock问价删除掉git本地版本回退通过tortoiseGit查看日志show log选中需要回退的代码版本右键选择Reset “master to this…在弹出的窗口Reset Type选择Hard:Reset working tree and index(discard all local changes)git lfs的使用操作步骤：1、安装lfs安装包地址：https://git-lfs.github.com/2、把项目从gitlab clone下来F:\镜像文件>git clone https://xxx/dc/vmware-image.gitCloning into ‘vmware-image’…remote: Enumerating objects: 3, done.remote: Counting objects: 100% (3/3), done.remote: Total 3 (delta 0), reused 0 (delta 0)Unpacking objects: 100% (3/3), done.3、初始化git lfs项目F:\镜像文件\vmware-image>git lfs installUpdated git hooks.Git LFS initialized.4、选择要作为大文件处理的文件扩展名F:\镜像文件\vmware-image>git lfs track “.wim"Tracking “.wim"5、提交文件F:\镜像文件\vmware-image>git add install.wimPossibly malformed conversion on Windows, see git lfs help smudge for more details.F:\镜像文件\vmware-image>git commit -am “添加install.wim”[master 43c28b8] 添加install.wim 1 file changed, 3 insertions(+) create mode 100644 install.wimF:\镜像文件\vmware-image>git push origin xxxLocking support detected on remote “origin”. Consider enabling it with: $ git config lfs.https://xxxx/dc/vmware-image.git/info/lfs.locksverify trueUploading LFS objects: 100% (1/1), 11 GB | 23 MB/s, doneCounting objects: 3, done.Delta compression using up to 4 threads.Compressing objects: 100% (3/3), done.Writing objects: 100% (3/3), 407 bytes | 0 bytes/s, done.Total 3 (delta 0), reused 0 (delta 0)remote:remote: To create a merge request for xxx, visit:remote: https://xxx/dc/vmware-image/merge_requests/new?merge_request%5Bsource_branch%5D=xxxremote:To https://xxx/dc/vmware-image.git * [new branch] xxx -> xxx参考https://blog.csdn.net/ustccw/article/details/79068547https://blog.csdn.net/top_code/article/details/51931916https://www.cnblogs.com/wteam-xq/p/4122163.html ...

当重置了.ssh秘钥后，不是简单的生成秘钥，重新复制粘贴公钥到git即可。1.在申请ssh秘钥之前，首先要重置全局git用户名和邮箱地址。$ git config –global user.name “Alexandra”$ git config –global user.email “alexandral@qq.com"2.使用下面的命令生成秘钥，注意这里一定要加上上面注册的那个邮箱地址$ ssh-keygen -t rsa -C “alexandral@qq.com"一路回车，密码为空。3.将_rsa.pub文件中的密码复制粘贴到git或者码云中4.只有成功设置了ssh key，我们的本地电脑才可以从远端git、码云等仓库中以ssh方式clone代码。5.在某个文件夹下单独使用git连接了远程仓库，这些连接都只是在当前文件夹下生效即git remote列出的远程连接都只在当前文件夹下有用。6.如果一台电脑在git/ gitee/自己公司的git系统中分别注册了一个用户名和密码，且需要分别提交代码到对应的远程仓库中，此时，要使用一下命令重新生成各个注册邮箱对应的ssh key。ssh-keygen -t rsa -C “每个账户的邮箱地址”

build your own git reposity建立服务器端从头新建mkdir gitrepochown harriszh:harriszh /home/harriszh/gitrepogit init –bare /home/harriszh/gitrepo/memtrans.git基于已有工作区git clone –bare memtrans memtrans.git建立客户端git initgit add .git commit -m “first commit"git remote add origin harriszh@sj-harriszh:/home/harriszh/gitrepo/memtrans.gitgit push -u origin master默认每次都要输入密码可以配置默认的branch[core] repositoryformatversion = 0 filemode = true bare = false logallrefupdates = true[remote “origin”] url = harriszh@sj-harriszh:/home/harriszh/gitrepo/memtrans.git fetch = +refs/heads/:refs/remotes/origin/[branch “master”] remote = origin merge = refs/heads/master权限修改repo文件的读写执行权限chmod g+wx /home/harriszh/gitrepo/memtrans.git注意点客户端每次修改时先git pull从服务器端拉回最新修改再进行修改和git push， 这样可以减少很多冲突

实际开发过程中，有时候我们会发现历史版本是对的，当前版本和远程分支是错的情况。我们这时候需要回滚到历史版本，并且让远程分支也回退到历史版本，下面来说一种解决办法。1，先把本地的分支回退到历史版本：1.1 使用git log –pretty=oneline命令查看历史版本1.2 使用下面命令回滚，我们这里回滚到上一个提交版本git reset –hard HEAD^注意：上一个版本就是HEAD^，上上一个版本就是HEAD^^，当然往上100个版本写100个^比较容易数不过来，所以写成HEAD~1002，把当前分支push到远程仓库并且让远程仓库和当前分支保持一致：2.1 使用命令,这里假定我们当前的分支名为mastergit push -f origin master 到此为止，我们就做到本地分支和远程分支都回滚到上一个历史版本了。

前言环境搭建完成之后，我们来看看Flutter:New Project后生成的项目结构。具体环境搭建可以参考：w7上使用VSCode配置Flutter开发环境项目结构pubspec.yaml配置文件说明作用 每个发布包都需要一些元数据，以便能够指定它的依赖项。与他人共享的发布包还需要提供一些其他信息，以便用户能够发现它们。所有这些元数据都放在一个名为pubspec.yaml的yamll(YAML 是专门用来写配置文件的语言，非常简洁和强大，远比 JSON 格式方便)文件中。支持的字段 name,version,description,author/authors,homepage,repository,issue_tracker,documentation,dependencies,dev_dependcencies,dependency_overrides,environment,excutables,publish_to与Node.js的package.json文件的类比 （因为我在web开发里是使用Node.js来做包管理的，所以类比nonde.js的package.json对于由web入门学习flutter的同学会比较容易理解。）简单而言，pubspec.yaml文件的作用就相当于Node.js的package.json文件，是用来进行包管理的； 两者都分离了两个环境，dependencies和dev_dependencies; 前者使用yaml语法来定义，后者使用json语法； pubspec.yaml对版本的约束规则与package.json规则类似； Node.js Flutter 安装依赖 npm install flutter package get 升级依赖包版本 npm update flutter packages upgrade 协同开发保证包版本一致 package-lock.json pubspec.lock 关于此后续可以再丰富~~默认的配置如下，有备注解释：#包名name: todo_app#描述信息description: A new Flutter project.#版本号version: 1.0.0+1#指定环境environment: sdk: “>=2.0.0-dev.68.0 <3.0.0”#指定包依赖dependencies: flutter: sdk: flutter # The following adds the Cupertino Icons font to your application. # Use with the CupertinoIcons class for iOS style icons. cupertino_icons: ^0.1.2 english_words: ^3.1.0#指定开发环境下的包依赖dev_dependencies: flutter_test: sdk: flutter# For information on the generic Dart part of this file, see the# following page: https://www.dartlang.org/tools/pub/pubspec# The following section is specific to Flutter.flutter: # The following line ensures that the Material Icons font is # included with your application, so that you can use the icons in # the material Icons class. uses-material-design: true ...

一、先讲背景目前的就职的公司，虽不是BAT之类，但是直接领导和后端业务团队的领导基本来自阿里和华为，git分支主要有以下：主分支：master，保证所有已发布到生产环境的分支都已merge到master，并且，新分支比如从master创建日常分支：daily，本地开发和测试环境使用，保证所有的已上生产和发布测试的分支都已merge到daily其他分支：版本分支或bug分支，从master拉取，并在merge到master后删除前端团队采用如下开发流程:（接到版本需求后，假设不需要后端接口配合，或后端接口已开发完毕）二、开发阶段第一阶段（本地开发+测试环境阶段）step1：master创建一个新分支featrue-2019-2，此为版本分支，并拉取到本地，使用SwicthHosts将本地开发环境映射到日常环境，也称测试环境，在本地开发调试step2：本地开发后，使用sourcetree保存并提交到远程featrue-2019-2分支，你使用git命令也是一样step3：拉取日常环境分支daily，并将featrue-2019-2 merge到 dailystep4：使用JenKins（日常环境账号）登录后构建daily分支，表示对daily的代码执行npm run build+push，构建成功后通知测试人员step5：若测试有问题，修改后，重复step2、step3、step4，直到测试通过第二阶段（预发阶段）step1：merge master 到 featrue-2019-2，保证featrue-2019-2已包含所有的生产代码step2：使用JenKins（预发环境账号）登录后构建featrue-2019-2分支，构建成功后通知测试step3：若测试有问题，检查测试环境是否也有此问题，若有，则要返回第一阶段的step2第三阶段（生产阶段）step1：此分支发预发后，若有别的分支发了生产，则需要执行merge master 到 featrue-2019-2，保证featrue-2019-2已包含所有的生产代码step2：使用JenKins（生产环境账号）登录后构建featrue-2019-2分支，构建成功后通知测试step3：featrue-2019-2 merge 到 master，并删除featrue-2019-2，step4：若测试有问题，汇总问题，从master拉取bug分支，例如可命名为featrue-2019-2-bug，从第一阶段开始，开启一个新的版本开发三、分支原则1、保证master分支是唯一主分支2、所有版本分支，所有需求，所有代码，必须按“照构建日常——>构建预发——>构建生产”的顺序执行3、所有版本分支只开发此版本相关内容，不可混合其他版本需求开发4、分支发布生产后，必须尽快merge到master5、分支的生命周期，从master上拉取开始，到merge到master以后结束，一个分支尽量只使用一次，即merge到master以后就删除6、不要频繁发布生产，日常和预发不受限制四、预发环境的必要性以前的公司，只有测试/预发环境和正式/生产环境，来到这家公司后，才了解到预发环境的必要性。测试环境，用来测试代码没有问题，但是测试环境里都是测试数据，和真实数据差别很大，大家都知道，对于前端来说这些数据的不同会造成特殊情况存在，例如测试环境的数据不合法。而预发环境则是真实数据，基本上用户在预发环境的所见，99%等同于在生产环境的所见，所以，必要性可想而知。

你是不是在git工程里遇到过.gitkeep文件？如果你通过angular脚手架来生成angular2或者angular4工程，你会发现.gitkeep文件在./src/app/assets文件夹里。你对着个文件感到奇怪吗？我们都知道我们的老朋友.gitignore。你也许会觉得它是.gitignore的兄弟。git提供给我们这个神奇的文件有什么特殊的属性吗？ .gitkeep是什么在知道这件事之前，我们必须要先了解git是不能追踪空的目录的。如果你有一个空的目录，git会对它视而不见。但这是我们想要的一个特性，现在你放一个文件到这个目录中，git就能开始追踪这个目录了，这个文件可以是任何东西，这个文件也可以包含任何东西。所以.gitkeep是什么？通常，团队里把这个神奇的文件命名为.gitkeep。其他人就能很容易理解，git这个软件没有赋予它其他的特性相对于.gitignore。现在如果你希望追踪获取push一个空的目录，你只要创建一个.gitkeep文件就可以，其他的开发者就能很容易理解，一般来说，人们把它用于assets文件夹或者log文件夹（因为一上来这两个文件夹可能是空的）。注意：千万不要把.gitkeep写到.gitignore里，这样的话，所有的空目录都不会被追踪了，也就提交不了了。有一小部分团队会把.gitignore文件放到空的文件夹中，这样的话大部分人看到这个文件就会感到困惑。.gitignore文件是用来让git去忽略你版本控制系统中不需要的文件的。所以也可以利用这个方法，在空目录中添加一个.gitignore文件让git来追踪他们。总结：对于空目录的追踪我们可以用.gitkeep来做。

mac上命令行比windows好用很多，但是git默认按tab键是不会自动补全的，很不爽。下面我们按步骤来介绍怎么做到自动补全。 1.安装home-brew,相应大家装装过了，如果没装，直接去官网看下命令行，copy过来装下就好了。2.执行 brew install bash-completion3.if [ -f ~/.git-completion.bash ]; then. ~/.git-completion.bashfi把上面这段代码copy到 ~/.bash_profile 中，如果没有，就创建下这个文件，怎么创建文件？touch .bash_profile 4.打开https://github.com/git/git/bl…，把这个文件下下来，然后cp git-completion.bash ~/.git-completion.bash这个命令意思就是把这个文件拷贝到 /目录下，并且名字前面加了个点。 5.在/.bashrc文件（该目录下如果没有，新建一个）中添加下边的内容source ~/.git-completion.bash 6.运行test -f ~/.git-completion.bash && . $_然后重启终端，试试按tab键吧。git命令就自动补全了。

分布式git是分布式版本控制系统，这么一来，任何一处协同工作用的服务器发生故障，事后都可以用任何一个镜像出来的本地仓库恢复。 因为每一次的克隆操作，实际上都是一次对代码仓库的完整备份。直接记录快照，而非差异比较每次你提交更新，或在 Git 中保存项目状态时，它主要对当时的全部文件制作一个快照并保存这个快照的索引。 为了高效，如果文件没有修改，Git 不再重新存储该文件，而是只保留一个链接指向之前存储的文件。Git 中所有数据在存储前都计算校验和，然后以校验和来引用。三种状态配置git config$ git config –global user.name “John Doe”$ git config –global user.email johndoe@example.com$ git config –global core.editor emacs //配置文本编辑器，可选$ git config –list // 查看当你想针对特定项目使用不同的用户名称与邮件地址时，可以在那个项目目录下运行没有 –global 选项的命令来配置。常用命令$ git init$ git add 文件名|.$ git commit 这种方式会启动文本编辑器以便输入本次提交的说明$ git commit -m ‘message’$ git commit -a -m ‘added new benchmarks’ 跳过使用暂存区域的方式$ git clone url [name]$ git status查看差异$ git diff 比较的是工作目录中当前文件和暂存区域快照之间的差异， 也就是修改之后还没有暂存起来的变化内容。$ git diff –cached 查看已经暂存起来的变化删除文件$ git rm [filename] 从已跟踪文件清单中移除（确切地说，是从暂存区域移除）并从工作目录中删除指定的文件$ git rm -f [filename] 删除之前修改过并且已经放到暂存区域的文件$ git rm –cached [filename] 把文件从 Git 仓库中删除（亦即从暂存区域移除），但保留在当前工作目录中$ git mv file_from file_to 重命名查看提交历史$ git log –pretty=format 以指定格式输出format如下:选项 说明%H 提交对象（commit）的完整哈希字串%h 提交对象的简短哈希字串%T 树对象（tree）的完整哈希字串%t 树对象的简短哈希字串%P 父对象（parent）的完整哈希字串%p 父对象的简短哈希字串%an 作者（author）的名字%ae 作者的电子邮件地址%ad 作者修订日期（可以用 –date= 选项定制格式）%ar 作者修订日期，按多久以前的方式显示%cn 提交者（committer）的名字%ce 提交者的电子邮件地址%cd 提交日期%cr 提交日期，按多久以前的方式显示%s 提交说明其他选项如下:-p 用来显示每次提交的内容差异–stat 每次提交的简略的统计信息–graph 显示 ASCII 图形表示的分支合并历史。–pretty=xxx 使用其他格式显示历史提交信息。可用的选项包括 oneline，short，full，fuller 和 format（后跟指定格式）。撤销操作$ git commit –amend 有时候我们提交完了才发现漏掉了几个文件没有添加，这个命令会将暂存区中的文件提交。 如果自上次提交以来你还未做任何修改（例如，在上次提交后马上执行了此命令），那么快照会保持不变，而你所修改的只是提交信息$ git reset HEAD <file> 取消暂存$ git checkout – [file] 撤消对文件的修改远程仓库$ git remote 查看远程仓库$ git remote -v 查看远程仓库$ git remote show [remote-name] 查看远程仓库$ git remote add <shortname> <url> 添加远程仓库$ git remote rename 旧名 新名 重命名远程仓库$ git remote rm [remote-name] 删除远程仓库$ git fetch [remote-name] 将数据拉取到你的本地仓库 - 它并不会自动合并或修改你当前的工作$ git pull 抓取数据并自动尝试合并到当前所在的分支。$ git push [remote-name] [branch-name] 推送到远程仓库,只有当你有所克隆服务器的写入权限，并且之前没有人推送过时，这条命令才能生效打标签$ git tag 列出已有的标签$ git tag -a 标签 -m 备注 打附注标签$ git show 标签 查看标签的信息$ git push origin 标签 将标签推送到远程仓库服务器上$ git push origin –tags 将所有的标签推送到远程仓库$ git tag -d 标签 删除本地标签$ git push <remote>:refs/tags/<tagname> 删除远程标签分支Git 保存的不是文件的变化或者差异，而是一系列不同时刻的文件快照假设现在有一个工作目录，里面包含了三个将要被暂存和提交的文件,暂存操作(git add)会为每一个文件计算校验和,然后会把当前版本的文件快照保存到 Git 仓库中（Git 使用 blob 对象来保存它们），最终将校验和加入到暂存区域等待提交。当使用 git commit 进行提交操作时，Git 会先计算每一个子目录（本例中只有项目根目录）的校验和，然后在 Git 仓库中这些校验和保存为树对象。 随后，Git 便会创建一个提交对象，它除了包含上面提到的那些信息外，还包含指向这个树对象（项目根目录）的指针。如此一来，Git 就可以在需要的时候重现此次保存的快照。现在，Git 仓库中有五个对象：三个 blob 对象（保存着文件快照）、一个树对象（记录着目录结构和 blob 对象索引）以及一个提交对象（包含着指向前述树对象的指针和所有提交信息）。做些修改后再次提交，那么这次产生的提交对象会包含一个指向上次提交对象（父对象）的指针。Git 的分支，其实本质上仅仅是指向提交对象的可变指针它有一个名为 HEAD 的特殊指针,指向当前所在的本地分支$ git branch [branch-name] 这会在当前所在的提交对象上创建一个指针(分支)。$ git branch -d [branch-name] 删除指定分支$ git branch -D [branch-name] 强制删除$ git branch -v 查看每一个分支的最后一次提交$ git checkout [branch-name] 切换分支$ git checkout -b [branch-name] 创建并切换分支$ git log –oneline –decorate –graph –all 输出提交历史、各个分支以及项目的分支分叉情况$ git merge [branch-name] 合并指定分支到当前分支,当你试图合并两个分支时，如果顺着一个分支走下去能够到达另一个分支，那么 Git 在合并两者的时候，只会简单的将指针向前推进（指针右移），因为这种情况下的合并操作没有需要解决的分歧——这就叫做 “快进（fast-forward）”。如果有分叉，出现这种情况的时候，Git 会使用两个分支的末端所指的快照（C4 和 C5）以及这两个分支的工作祖先（C2）,做一个新的快照并且自动创建一个新的提交指向它。 这个被称作一次合并提交，它的特别之处在于他有不止一个父提交。看一个例子:首先创建并切换到testing分支在testing分支上进行修改, 并提交接着切换回master分支, 并修改提交合并的例子:合并后如下出现冲突合并它们的时候产生合并冲突, Git 会暂停下来，等待你去解决合并产生的冲突。 你可以在合并冲突后的任意时刻使用 git status 命令来查看那些因包含合并冲突而处于未合并（unmerged）状态的文件, 在你解决了所有文件里的冲突之后，对每个文件使用 git add 命令来将其标记为冲突已解决。 一旦暂存这些原本有冲突的文件，Git 就会将它们标记为冲突已解决。这时你可以输入 git commit 来完成合并提交远程分支远程引用是对远程仓库的引用（指针），包括分支、标签等等$ git ls-remote [remote] 某个远程引用的完整列表$ git remote show [remote] 获得远程分支的更多信息$ git checkout -b [branch] [remote-ranch] 创建并跟踪分支$ git branch -u|–set-upstream-to 远程分支 将已有分支跟踪到指定的远程分支$ git branch -vv 查看已有的所有跟踪分支$ git push [remote] –delete branch 删除远程分支 如果有人对远程仓库进行了修改，你也对你本地仓库进行了修改,此时进行fetch分支-变基在 Git 中整合来自不同分支的修改主要有两种方法：merge 以及 rebasemerge它会把两个分支的最新快照（C3 和 C4）以及二者最近的共同祖先（C2）进行三方合并，合并的结果是生成一个新的快照（并提交）。合并之后rebase你可以使用 rebase 命令将提交到某一分支上的所有修改都移至另一分支上，就好像“重新播放”一样。$ git rebase [branch] 将当前分支的修改提取，并移动到[branch]上$ git rebase 被提取的分支 目标分支 将被提取分支的修改移动到目标分支$ git merge [branch] 一般在变基后，需要进行一次快进合并$ git pull –rebase 将当前分支的修改提取，并合并到目标分支, 等同于执行git fetch origin/branch然后再执行git rebase origin/branch提取修改：合并后：不要对在你的仓库外有副本的分支执行变基。 如你已经将提交推送至某个仓库，而其他人也已经从该仓库拉取提交并进行了后续工作 ...

PS峰采第二期姗姗来迟。原来我们的世界一直在进步？人类有了希望？刘作虎的英文名是什么？硅谷的尤达大师是哪位？Read on…The Listhttps://standardnotes.org/跨平台的笔记软件。比EverNote轻量。支持Android, iOS, MacOS, Windows, Linux。无需科学上网。全程加密。不限量，不限设备。非常适合像我这样用Android手机，但是其它设备都是iOS的同学。https://www.vox.com/2014/11/2…世界一直在进步的数据证明。从历史上看，哪怕是近二十年的历史，贫穷，饥饿的数据一直都在改善。西欧国家人民的休闲时间一直在增加。https://howmuch.net/articles/…world economy in one charthttps://github.com/warmchang/…KubeCon 2018 北美PPT。翻翻可以接受些新概念https://github.com/rhysd/vim….Vim被移植到Webassembly了。难道Write Once， Run Everywhere终于要实现？https://www.nytimes.com/2018/…大神膜拜时间。英文title叫"The Yoda of Silicon Valley"。硅谷的尤达大师。看照片像不像？https://github.com/Netflix-Sk…用命令行操作jirahttps://www.theverge.com/2018…你知道刘作虎的英文名叫什么？Pete Lau。。。。一个浙江人挺起来象香港人。。我也是醉了。https://www.eater.com/2016/6/…Maybe Just Don’t Drink Coffee关于咖啡鄙视链的好玩的英文文章，没啥技术东西https://mp.weixin.qq.com/s/aB…王兴：20年to C，20年to B第一篇中文文章。理论很高。服后可能有醍醐灌顶的感觉。但最后结论还是“学欧美”难免让人丧气。https://github.com/jaywcjlove…又一篇Awesome XXXX。这篇是给Mac的。https://ideas.ted.com/how-wor…TED talk。少干活可是解决你所有的问题，真的。。。。真的吗？https://www.wired.com/2017/02…标题就够炫：程序猿是新蓝领。原来美国只有8%的程序人在硅谷工作。IT的平均工资是81000刀 - 重点是其它工种的两倍。我天朝也差不多吧。。。。http://facesofopensource.com又到拜大神时间，“开源的面孔”。 第一位是Linus! 看看你能认出几个？我看了一下，里面美女还不少哦。 Eric Schmit 创造了 Lex。说明牛人早已是牛人。另外还有几个几个亚洲面孔：git 维护者，Henry Zhuhttps://github.com/rgcr/m-cli又一个命令行工具。号称macOS的瑞士军刀!PS图片有点大。下次看看能不能缩一下。

我们在使用java编程的时候免不了使用数组这种数据类型，今天我们就来聊聊数组的初始化。java有两种初始化方式：静态初始化所谓静态初始化就是由我们给数组指定每一个具体的值， 长度由系统给我们分配， 例如： String[] names = {“zhangsan”, “lisi”}; String[] name = new String[]{“zhangsan”, “lisi”};动态初始化所谓动态初始化就是我们指定数组的长度， 由系统给我们指定初始的值，即系统会给我们分配默认的值 例如：String[] name = new String[5];需要注意的是不能同时进行动态初始化和静态初始化， 例如下面的例子编译就不能通过：String[] name = new String[2]{“zhangsan”, “lisi”}(这是错误初始化方式)