composer update 和 composer install 的区别

composer 是 php 的一个依赖管理工具。它允许你申明项目所依赖的代码库，它会在你的项目中为你安装他们。

然而，对于如何『安装他们』，新手可能并不清楚。网上的答案有的说 composer install，有的说composer update，而这两者似乎都能成功把依赖下载下来并安装好，那么他们究竟有何区别呢？

首先要搞清楚的一件事情是，所有的依赖都定义在composer.json中，手册中给出了一些基本用法和例子。你可能已经注意到，在指定版本号的时候，我们并不一定要指明一个精确的版本。那么就有可能发生这么一个情况，对于同一份composer.json，我们在不同时刻拉取到的依赖文件可能不同（因为composer会在满足条件的情况下去拉取最新的那份依赖），从而导致一些异常情况。composer update和composer install正是为了解决这个问题而出现的。

当你执行composer update的时候，composer会去读取composer.json中指定的依赖，去分析他们，并且去拉取符合条件最新版本的依赖。然后他会把所拉取到的依赖放入vendor目录下，并且把所有拉取的依赖的精确版本号写入composer.lock文件中。

composer install所执行的事情非常类似，只在第一步的时候有差别。当你本地如果已经存在一份composer.lock时，它将会去读取你的composer.lock而非composer.json，并且以此为标准去下载依赖。当你本地没有composer.lock的时候，它所做的事情和composer update其实并没有区别。

这意味着，只要你本地有一份composer.lock，你就可以保证无论过去了多久，你都能拉到相同的依赖。而如果你把它纳入你的项目的版本控制中，那么你就可以确保你项目中的每一个人、每一台电脑，不管什么系统，都能拉取到一模一样的依赖，以减少潜在的依赖对部署的影响。当然，请记得，你应该使用的命令是composer install。

那什么时候该使用composer update呢？当你修改了你的依赖关系，不管是新增了依赖，还是修改了依赖的版本，又或者是删除了依赖，这时候如果你执行composer install的时候，是不会有任何变更的，但你会得到一个警告信息

Warning: The lock file is not up to date with the latest changes in composer.json. You may be getting outdated dependencies. Run update to update them.

有人可能会很好奇php是怎么知道我修改了依赖，或者composer.lock已经过期了。很简单，如果你打开composer.lock的话，会发现其中有一个hash字段，这就是当时对应的那份依赖的哈希值。如果值不一致自然而然就知道发生了变更了。

这时候，你应该去通过composer update来更新下你的依赖了。

如果你不希望影响别的已经安装的依赖，仅仅更新你修改的部分，那你可以通过指定白名单来确定要更新的范围，例如composer update monolog/monolog仅会更新monolog/monlog这个依赖，别的依赖哪怕有更新也会被忽略。

git chrrey-pick 相关用法

https://blog.****.net/FightFightFight/article/details/81039050

GIT clone 报错 git did not exit cleanly fatal: Authentication failed

提示报错：致命的身份验证失败
解决方法如下：


再次指定clone的时候 会要求从新填写 username password

远程代码仓库已经删除分支本地git branch还是可以看到

git branch -a 本地和远程
git branch -r 远程
git branch -d dev_one 删除本地分支 (-D强制删除 )
使用命令 git remote show origin，可以查看remote地址，远程分支，还有本地分支与之相对应关系等信息

根据提示，使用 git remote prune origin 命令

git默认不区分大小写，对大小写敏感的不友好

git config --global core.ignorecase false

设置忽略文件权限

git config --global core.filemode false

设置不自动转换换行符

git config --global core.autocrlf false

校验混用则拒绝提交

git config --global core.safecrlf true

pull操作默认rebase，避免出现自动merge

git config --global pull.rebase true

https://git-scm.com/book/zh/v2

alias自定义命令

https://juejin.im/post/5c9660c45188252d60192c5e
git config --global alias.ck checkout
执行上面config配置后，命令 git checkout，直接输入git ck就ok
alias.xx yy 点后面的xx就代表了我们设置的别名 ，yy是原始命令

git log历史纪录显示优化

使用alias 的 全局配置
git config --global alias.lg “log --graph --pretty=format:’%Cred%h%Creset - %C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset’ --abbrev-commit --date=relative”

生成**

https://git-scm.com/book/zh/v1/%E6%9C%8D%E5%8A%A1%E5%99%A8%E4%B8%8A%E7%9A%84-Git-%E7%94%9F%E6%88%90-SSH-%E5%85%AC%E9%92%A5
在项目录下执行 ssh-******.exe 会生成一个**
然后使用cat ~/.ssh/id_rsa.pub
将密文(整个ssh。。。。PCO)复制到git下

另外 vi ~/.gitconfig

另外git config --list

删除全局配置项：
终端执行命令：
git config --global --unset user.name
编辑配置文件：
git config --global --edit

如果我们git clone的下载代码的时候是连接的https://而不是[email protected] (ssh)的形式，当我们操作git pull/push到远程的时候，总是提示我们输入账号和密码才能操作成功，频繁的输入账号和密码会很麻烦。
解决办法：
git bash进入你的项目目录，输入：
git config --global credential.helper store
然后你会在你本地生成一个文本，上边记录你的账号和密码。当然这些你可以不用关心。
然后你使用上述的命令配置好之后，再操作一次git pull，然后它会提示你输入账号密码，这一次之后就不需要再次输入密码了。

**husk_3.0 分支得某个节点往master 合： **

1.切到master分支 拉去代码
2.切到husk_3.0拉取代码
3.再切到master 执行 merge commit id(代码push的记录id)

git回退

http://www.ruanyifeng.com/blog/2015/12/git-cheat-sheet.html

常规操作

1.修改文件file.php没有add
git checkout file.php
2.修改文件file.php并且add
首先 git log file.php
然后 git reset fd15184d424facf33f304c52a2fb48ab1f3b538b file.php
最后 git checkout file.php
3.多个文件修改并且 add
首先 git reset HEAD .
然后 git checkout .
4.如果文件已修改并且add commit
首先 git log 此时已经可以看到刚刚commit得记录
然后 git reset --hard 9f455072d0f1df9fef4f876d9899a7a67db6f8f0

查看修改修改的文件
只修改 没有add ： git diff
已修改并且add commit ： git show 9f455072d0f1df9fef4f876d9899a7a67db6f8f0

分支master代码合并

husk_3.0 分支往master 合：
1.切到master分支 拉去代码
2.切到husk_3.0拉取代码
3.再切到master 执行 merge commit id(代码push的记录id)

例：
在 cc 的 husk3.1分支上，有两个我的commit，
我想把这两个commit 合并到 cc的master上。

我先 执行下面命令:
git checkout master
git pull
git checkout husk_3.1
git pull
git checkout master
git merge 1id

将master代码合并到分支

一、将分支切换到master
git checkout master
二、将代码pull到本地
git pull
三、修改冲突
四、提交到本地
git add .
git commit -m “merge”
五、切换到分支husk_3.1
git checkout husk_3.1
六、merge
git merge master
七、将本地内容push到dev分支
git push

TX git fixed bug 经验

牵扯 git 代码类库bug修复流程：
1.首先 从 library_master 拉取library_dev 分支修bug
2.在git上 发起合并请求 将library_dev 合并到 library_master
3.在git上添加tags 。复制已有最新tags id 加1作为 Name for new tag的值 。Create from = master
4.在相关的服务包文件里 composer update
5.然后将 代码push