标签：git

希望从git仓库中拉取代码时目录就已经存在了，不需要再手动创建，但是git并不允许git提交空目录，应该怎么办呢？

其实这里有两种情况：

目录是空的

这种情况下只需要在目录下创建.gitkeep文件，然后在项目的.gitignore中设置不忽略.gitkeep

.gitkeep 是一个约定俗成的文件名并不会带有特殊规则

目录中已经存在文件

那就需要首先在根目录中设置!.gitignore，然后在目标目录也创建一个.gitignore文件，并在文件中设置

*!.gitignore

这样就可以在项目中提交空目录了

一，新建代码库

1，在当前目录下新建一个git代码库

$ git init 

2，新建一个目录将其初始化为git代码库

$ git init [project-name]

3，git clone 远程代码库

$ git clone [url]

二，配置

1，Git的设置文件为.gitconfig，它可以在用户主目录下（全局配置），也可以在项目目,录（项目配置）。
2， 显示当前的Git配置

$ git config--list

3，编辑git配置文件

$ git config -e[--global]

4，设置提交代码时的用户信息

$ git config[--global] user.name "[name]" 
$ git config[--global] user.email "[email address]"

三、增加/删除文件

1，添加指定文件到暂存区

$ git add [file1][file2] ...

2， 添加指定目录到暂存区，包括子目录,

$ git add [dir]

3， 添加当前目录的所有文件到暂存区

$ git add .

4 添加每个变化前，都会要求确认， 对于同一个文件的多处变化，可以实现分次提交

$ git add -p

5，删除工作区文件，并且将这次删除放入暂存区

$ git rm [file1][file2] ...

6， 停止追踪指定文件，但该文件会保留在工作区

$ git rm --cached[file] 

7， 改名文件，并且将这个改名放入暂存区

$ git mv[file-original] [file-renamed]

四、代码提交

1， 提交暂存区到仓库区,

$ git commit -m[message],

2， 提交暂存区的指定文件到仓库区

$ git commit[file1] [file2] ... -m [message],

3，提交工作区自上次commit之后的变化，直接到仓库区

$ git commit -a,

4， 提交时显示所有diff信息

$ git commit -v

5，使用一次新的commit，替代上一次提交，如果代码没有任何新变化，则用来改写上一次commit的提交信息

$ git commit--amend -m [message]

6， 重做上一次commit，并包括指定文件的新变化

$ git commit--amend [file1] [file2] ...

五、分支

1， 列出所有本地分支

$ git branch

2， 列出所有远程分支

$ git branch -r

3， 列出所有本地分支和远程分支

$ git branch -a

4， 新建一个分支，但依然停留在当前分支

$ git branch[branch-name]

5， 新建一个分支，并切换到该分支

$ git checkout -b[branch]

6， 新建一个分支，指向指定commit

$ git branch[branch] [commit]

7， 新建一个分支，与指定的远程分支建立追踪关系

$ git branch--track [branch] [remote-branch]

8， 切换到指定分支，并更新工作区

$ git checkout[branch-name],

9， 切换到上一个分支

$ git checkout -,

10， 建立追踪关系，在现有分支与指定的远程分支之间

$ git branch--set-upstream [branch] [remote-branch]

11， 合并指定分支到当前分支,

$ git merge[branch]

12， 选择一个commit，合并进当前分支,

$ git cherry-pick[commit]

13， 删除分支,

$ git branch -d[branch-name]

14， 删除远程分支,

$ git push origin--delete [branch-name]
$ git branch -dr[remote/branch]

六、标签,

1， 列出所有tag

$ git tag

2， 新建一个tag在当前commit,

$ git tag [tag]

3， 新建一个tag在指定commit,

$ git tag [tag][commit]

4， 删除本地tag,

$ git tag -d[tag]

5， 删除远程tag,

$ git push origin:refs/tags/[tagName]

6， 查看tag信息,

$ git show [tag]

7， 提交指定tag,

$ git push[remote] [tag]

8， 提交所有tag,

$ git push[remote] --tags

9， 新建一个分支，指向某个tag

$ git checkout -b[branch] [tag]

七、查看信息

1， 显示有变更的文件

$ git status

2， 显示当前分支的版本历史

$ git log

3， 显示commit历史，以及每次commit发生变更的文件

$ git log --stat

4， 搜索提交历史，根据关键词

$ git log -S[keyword]

5， 显示某个commit之后的所有变动，每个commit占据一行

$ git log [tag]HEAD --pretty=format:%s

6， 显示某个commit之后的所有变动，其”提交说明”必须符合搜索条件,

$ git log [tag]HEAD --grep feature

7， 显示某个文件的版本历史，包括文件改名

$ git log --follow[file]
$ git whatchanged[file]

8， 显示指定文件相关的每一次diff

$ git log -p[file]

9， 显示过去5次提交,

$ git log -5--pretty --oneline

10， 显示所有提交过的用户，按提交次数排序

$ git shortlog-sn

11， 显示指定文件是什么人在什么时间修改过,

$ git blame[file]

12， 显示暂存区和工作区的差异

$ git diff

13，显示暂存区和上一个commit的差异

$ git diff--cached [file]

14， 显示工作区与当前分支最新commit之间的差异

$ git diff HEAD

14， 显示两次提交之间的差异,

$ git diff[first-branch]...[second-branch]

15，显示今天你写了多少行代码,

$ git diff--shortstat "@{0 day ago}"

16， 显示某次提交的元数据和内容变化

$ git show[commit]

17， 显示某次提交发生变化的文件,

$ git show--name-only [commit]

18，显示某次提交时，某个文件的内容

$ git show[commit]:[filename]

19， 显示当前分支的最近几次提交

$ git reflog

八、远程同步

1， 下载远程仓库的所有变动

$ git fetch[remote]

2，显示所有远程仓库,

$ git remote -v

3， 显示某个远程仓库的信息,

$ git remote show[remote]

4， 增加一个新的远程仓库，并命名

$ git remote add[shortname] [url]

5，取回远程仓库的变化，并与本地分支合并

$ git pull[remote] [branch]

6， 上传本地指定分支到远程仓库

$ git push[remote] [branch]

7， 强行推送当前分支到远程仓库，即使有冲突

$ git push[remote] --force

8， 推送所有分支到远程仓库

$ git push[remote] --all

九、撤销

1， 恢复暂存区的指定文件到工作区,

$ git checkout[file]

2， 恢复某个commit的指定文件到暂存区和工作区,

$ git checkout[commit] [file]

3，恢复暂存区的所有文件到工作区,

$ git checkout .

4， 重置暂存区的指定文件，与上一次commit保持一致，但工作区不变

$ git reset[file]

5， 重置暂存区与工作区，与上一次commit保持一致

$ git reset--hard

6， 重置当前分支的指针为指定commit，同时重置暂存区，但工作区不变

$ git reset[commit]

7， 重置当前分支的HEAD为指定commit，同时重置暂存区和工作区，与指定commit一致

$ git reset--hard [commit]

8， 重置当前HEAD为指定commit，但保持暂存区和工作区不变

$ git reset--keep [commit]

9， 新建一个commit，用来撤销指定commit， 后者的所有变化都将被前者抵消，并且应用到当前分支

$ git revert[commit]

10， 暂时将未提交的变化移除，稍后再移入

$ git stash
$ git stash pop

十、其他

1， 生成一个可供发布的压缩包

$ git archive

git一般有很多分支，我们clone到本地的时候一般都是master分支，那么如何切换到其他分支呢？主要命令如下：

1. 查看远程分支

$ git branch -a
我在mxnet根目录下运行以上命令：

~/mxnet$ git branch -a
* master
  remotes/origin/HEAD -> origin/master
  remotes/origin/master
  remotes/origin/nnvm
  remotes/origin/piiswrong-patch-1
  remotes/origin/v0.9rc1

可以看到，我们现在在master分支下

2. 查看本地分支

~/mxnet$ git branch
* master

3. 切换分支

$ git checkout -b v0.9rc1 origin/v0.9rc1
Branch v0.9rc1 set up to track remote branch v0.9rc1 from origin.
Switched to a new branch 'v0.9rc1'

＃已经切换到v0.9rc1分支了
$ git branch
  master
* v0.9rc1

＃切换回master分支
$ git checkout master
Switched to branch 'master'
Your branch is up-to-date with 'origin/master'.

这里说的自动布署是两方面的，第一部分是脚本自动布署服务器环境，第二部份是自动布署代码，完成这两部分，在我理解，就算是完成自动部署了。

我们要做的，就是本地写完代码提交 git 后，使用git push 自动将代码推送到测试或生产环境的站点目录。 好的，开工吧！

LNMP线上环境自动布署脚本

使用 此脚本 可在一台全新的 Ubuntu 14.04 LTS 或者 Ubuntu 16 上自动部署适合 Laravel 使用的 LNMP 生产环境。 按照此 文档 安装即可。

但是此方法在使用中会有一些小问题

1、网易镜像加速后会出现一些安装错误 可能是网易镜像没有更新完全。 需要将网易镜像地址更新为其它地址，可以参考 Ubuntu 官方模版 来更新镜像。 我使用的是阿里云的镜像替换了网易的镜像。

vi /etc/apt/sources.list

更新为

deb http://mirrors.aliyun.com/ubuntu/ xenial main restricted universe multiverse
deb http://mirrors.aliyun.com/ubuntu/ xenial-security main restricted universe multiverse
deb http://mirrors.aliyun.com/ubuntu/ xenial-updates main restricted universe multiverse
deb http://mirrors.aliyun.com/ubuntu/ xenial-backports main restricted universe multiverse
##測試版源
deb http://mirrors.aliyun.com/ubuntu/ xenial-proposed main restricted universe multiverse
# 源碼
deb-src http://mirrors.aliyun.com/ubuntu/ xenial main restricted universe multiverse
deb-src http://mirrors.aliyun.com/ubuntu/ xenial-security main restricted universe multiverse
deb-src http://mirrors.aliyun.com/ubuntu/ xenial-updates main restricted universe multiverse
deb-src http://mirrors.aliyun.com/ubuntu/ xenial-backports main restricted universe multiverse
##測試版源
deb-src http://mirrors.aliyun.com/ubuntu/ xenial-proposed main restricted universe multiverse
# Canonical 合作夥伴和附加
deb http://archive.canonical.com/ubuntu/ xenial partner
deb http://extras.ubuntu.com/ubuntu/ xenial main

2、正常安装后Nginx 启动前需要把 apache 卸载掉，然后再启动 Nginx .

apt-get purge apache2
service nginx restart

3、redis 默认没有启动

service redis-server start  // 启动 redis
service redis-server status  // 查看 redis
service redis-server  stop  // 停止 redis

配置Git自动部署

创建Git远程仓库

我们用一个独立的路径来做远程仓库。 然后在仓库的路径下，创建一个git裸仓库：

cd /home/ubuntu/repo/
git init --bare blog.git

git 默认是禁止 push 的，所有要设置允许 push：

vi config

修改或添加如下内容：

[receive]
        denyCurrentBranch = ignore

编辑自动部署脚本

自动部署用到 git hooks ，在 git 路径下有个 hooks 文件夹，里面有一些示例。我们把 post-update.sample 重命名为 post-update ，并进行编辑：

mv post-update.sample post-update
vi post-update

#!/bin/sh
#
# An example hook script to prepare a packed repository for use over
# dumb transports.
#
# To enable this hook, rename this file to "post-update".

#exec git update-server-info

unset GIT_DIR

NowPath=`pwd`

DeployPath="/home/ubuntu/www/blog"

cd $DeployPath
git pull origin master
composer install

cd $NowPath

echo 'deploy success'
exit 0

这样每当 push master 分支到服务器时，都会自动切换到 DeployPath ，也就是 Nginx root 路径，执行 git pull origin master 从仓库拉去最新 master 分支，并执行 composer install ，如果项目 composer 有变更则安装，没有变更则不会安装。

部署路径初始化

先把空的仓库克隆到 home/ubuntu/www/ 路径下 ：

git clone  /home/ubuntu/repo/blog.git

服务器的配置就级别完成了，此 blog 即为你的站点目录

推送git仓库

进入本地共享文件夹，执行

git clone root@server_ip:/home/ubuntu/repo/blog.git blog_back

将远程的空仓库克隆下来。名称为 blog_back，防止与本地 blog 目录冲突。 ok,现在我们来创建一个项目

本地创建项目并提交 Git

composer create-project --prefer-dist laravel/laravel blog
mv blog_back/.git  blog/.git  //将 .git 目录拷贝过来即可在此目录操作 git
cd  blog
git add -A
git commit -m 'init'
git push origin master //此时输入服务器密码即可将本地项目推送到服务器上

这里我使用的是默认的 root 用户，我们可以单独设置一个 git 用户，也可以使用公钥的形式，类似于 github 的方式。

安装 Composer

打开命令行并依次执行下列命令安装最新版本的 Composer：

php -r "copy('https://install.phpcomposer.com/installer', 'composer-setup.php');"
//下载安装脚本 － composer-setup.php － 到当前目录。
php composer-setup.php //执行安装过程。
php -r "unlink('composer-setup.php');"  //删除安装脚本

执行第一条命令下载下来的 composer-setup.php 脚本将简单地检测 php.ini 中的参数设置，如果某些参数未正确设置则会给出警告；然后下载最新版本的 composer.phar 文件到当前目录。 打开命令行窗口并执行如下命令将前面下载的 composer.phar 文件移动到 /usr/local/bin/ 目录下面：

sudo mv composer.phar /usr/local/bin/composer

进程监控器 Supervisor 配置

项目中有些脚本需要在后台运行，比如队列、Horizon ，Supervisor可以监控后台脚本的运行，再产生异常或是停止后自动重启，保证了脚本不会被异常中断。定时任备也可以直接用 Supervisor 来执行，Supervisor 还可以写入执行成功或失败的日志，方便查看。 此脚本默认安装了 supervisor ，我们只需设置好启动即可。

配置

在 /etc/supervisor/conf.d/ 下新建一个配置文件 horizon.conf,写入以下内容

[program:horizon]
process_name=%(program_name)s_%(process_num)02d
command=php /home/ubuntu/www/site/artisan horizon  //启动脚本命令。
autostart=true  //随着supervisord的启动而启动
autorestart=true //自动重启
user=ubuntu  // 用户组
numprocs=1 // 启动进程，根据脚本决定
redirect_stderr=true  //重定向stderr到stdout
stdout_logfile=/var/log/supervisor/horizon.log  //日志 注意日志目录的权限

接下来就可以启动 supervisord 了。

supervisord -c /etc/supervisord.conf  //启动
supervisorctl shutdown //关闭
supervisorctl reload  //重新载入配置

好了。到这里自动布署就完成了，接下来就是尽情的敲代码吧！

由于 git rebase 命令的存在，强制将提交推送到远端仓库似乎也有些必要。不过都知道 git push –force 是不安全的，这让 git rebase 命令显得有些鸡肋。

本文将推荐 –force-with-lease 参数，让我们可以更安全地进行强制推送。

–force-with-lease 参数自 Git 的 1.8.5 版本开始提供，只在解决 git push –force 命令造成的安全问题。

那么 git push –force 命令有什么安全问题？

–force 会使用本地分支的提交覆盖远端推送分支的提交。也就是说，如果其他人在相同的分支推送了新的提交，你的这一举动将“删除”他的那些提交！就算在强制推送之前先 fetch 并且 merge 或 rebase 了也是不安全的，因为这些操作到推送之间依然存在时间差，别人的提交可能发生在这个时间差之内。

–force-with-lease 将解决这种安全问题

使用了 –force-with-lease 参数之后，上面那种安全问题就没有那么危险了。

使用此参数推送，如果远端有其他人推送了新的提交，那么推送将被拒绝，这种拒绝和没有加 –force 参数时的拒绝是一样的。

walterlv$ git push --force-with-lease
To https://github.com/walterlv/walterlv.github.io.git
 ! [rejected]        master -> master (fetch first)
error: failed to push some refs to 'https://github.com/walterlv/walterlv.github.io.git'

请特别注意——如果你 fetch 之后在本地的 origin 相关分支上已经看到了别人的提交，依然进行强制推送，你还是会覆盖别人的提交。也就是说，–force-with-lease 解决的是本地仓库不够新时，依然覆盖了远端新仓库的问题，如果你执意想要覆盖远端提交，只需要先 fetch 再推送，它也不会拒绝的。

在使用 git push –force-with-lease 命令被拒绝时，你需要 fetch 仓库，然后确认其他人是否对此分支有新的修改，如果没有，你才可以继续强制推送。

walterlv$ git fetch
remote: Counting objects: 46, done.
remote: Compressing objects: 100% (29/29), done.
remote: Total 46 (delta 21), reused 40 (delta 15), pack-reused 0
Unpacking objects: 100% (46/46), done.
From https://github.com/walterlv/walterlv.github.io
   e75edf0..217a49d  master     -> origin/master

在 fetch 完毕之后，请一定检查此分支是否已经被其他人修改，如果有新的提交，你应该进行一次 merge 或者 rebase。

walterlv$ git rebase
First, rewinding head to replay your work on top of it...
Applying: Add post "safe push using force with lease".

此后，再次进行推送或强制推送即可。

walterlv$ git push --force-with-lease
Counting objects: 4, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 363 bytes | 363.00 KiB/s, done.
Total 4 (delta 3), reused 0 (delta 0)
remote: Resolving deltas: 100% (3/3), completed with 3 local objects.
To https://github.com/walterlv/walterlv.github.io.git
   219a6d5..dff94a5  master -> master

额外的问题：为什么推送到远端的提交还依然要用 rebase？

Git 官方文档对 rebase 有如下描述：

▲ 如果你想吐槽那段中文翻译，我只想说——那是 Git 的官方中文文档

既然已经推送的提交不应该再进行 rebase，那本不应该会遇到本文提到的问题。但是——GitHub 的工作流或者 GitLab 的工作流中，都有一种行为是 rebase 自己的分支到 origin/master 上，以保证 master 分支上的提交是纯粹的干净的。也就是说，本意是禁止对合并到 master 或 develop 分支上的提交进行 rebase；但对于自己的 temp 分支或者 feature 分支，因为提交还没有合并到主干中，随时删除掉或者将历史进行美化也不会造成太大的问题。

▲ 这是 GitLab 上的设置，可以要求提交者必须进行 rebase 才允许合并。