Linux 中的cd命令讲解
1.切换到指定目录：cd dir

dir为指定目录的路径，可以是绝对路径也可以是相对路径

如：cd/usr , cd Desktop



2.cd / 是跳转到根目录

根目录是所有用户共享的目录



3.cd 、cd ~  和cd $HOME

是跳转到当前用户的家目录

root用户，cd ~ 相当于 cd /root

普通用户，cd ~ 相当于cd /home/当前用户名

注：cd - 返回进入此目录之前所在目录
root用户：



普通用户:user3



4.#cd /home 相当于查看有多少普通用户的家目录

所有普通用户的父目录都是home目录



5.#cd …/ 返回上一层目录

cd        进入用户主目录 
cd ~     进入用户主目录 
cd -      返回进入此目录之前所在目录 
cd ..     返回上一级目录 
cd ../..  返回上两级目录 
cd !$    把上个命令的参数作为cd 参数使用 
cd /      进入根目录
cd .      当前目录
 
转载于:https://www.cnblogs.com/torchstar/p/9976841.html

CD 是切换目录命令

.则是表示目前所在的目录，

..则表示目前目录位置的上一层目录。

cd    进入用户主目录；

cd ~  进入用户主目录；

cd -  返回进入此目录之前所在的目录；

cd ..  返回上级目录（若当前目录为“/“，则执行完后还在“/"；".."为上级目录的意思）；

cd ../..  返回上两级目录；

 

 

cd就是change directory的缩写，即改变目录。

讲cd命令之前，先来看看提示符是什么意思。现在的提示符是c:\>



c:说明现在的工作盘是c盘，\告诉我们当前的工作目录是根目录。

>的作用是把工作目录和我们要输入的命令分隔开来。

好，下面就开始列举cd的各种命令。

1.如果想要进入C盘下的任意文件或文件夹。

直接cd+空格+文件或文件夹的路径（这个路径省略最开始的根目录，即C盘）

比如想要进入C盘下的Program Files里的Java文件里，敲cd Program Files\Java就可以。



 

2.想要返回到上一级目录或者当前工作目录下的根目录

返回到上一句目录：cd+..



返回到根目录：cd + \



3.提醒一下，如果需要访问非当前根目录下的目录文件，

应该先输入该盘符，敲回车，然后再用cd命令



如果要切换到D:\Program Files目录下，大多数人会想当然的在命令行窗口输入 cd D:\Program Files回车。

如下所示：



发现并没有切换到D:\Program Files。

 

正确的做法是输入D:  回车。





发现已经切换到D盘下。

输入cd Program Files 回车。





成功切换到D:\Program Files目录下。

CI, CD AND CD

当我们在谈论现代的软件编译和发布流程的时候，经常会听到CI 和CD这样的缩写短语。CI很容易理解，就是持续集成。但是CD既可以指代码持续交付，也可理解为代码持续部署。CI和CD之间有很多相似的部分，但是也有很大的区别。这里我们将给大家介绍它们之间的区别和联系。

持续集成（CONTINUOUS INTEGRATION）

在持续集成环境中，开发人员将会频繁的提交代码到主干。这些新提交在最终合并到主线之前，都需要通过编译和自动化测试流进行验证。这样做是基于之前

持续集成过程中很重视自动化测试验证结果，以保障所有的提交在合并主线之后的质量问题，对可能出现的一些问题进行预警。

持续交付（CONTINUOUS DELIVERY）

持续交付就是讲我们的应用发布出去的过程。这个过程可以确保我们尽可能快的实现交付。这就意味着除了自动化测试，我们还需要有自动化的发布流，以及通过一个按键就可以随时随地实现应用的部署上线。

通过持续交付，您可以决定每天，每周，每两周发布一次，这完全可以根据自己的业务进行设置。

但是，如果您真的希望体验持续交付的优势，就需要先进行小批量发布，尽快部署到生产线，以便在出现问题时方便进行故障排除。

持续部署（CONTINUOUS DEPLOYMENT）

如果我们想更加深入一步的话，就是持续部署了。通过这个方式，任何修改通过了所有已有的工作流就会直接和客户见面。没有人为干预（没有一键部署按钮），只有当一个修改在工作流中构建失败才能阻止它部署到产品线。

持续部署是一个很优秀的方式，可以加速与客户的反馈循环，但是会给团队带来压力，因为不再有“发布日”了。开发人员可以专注于构建软件，他们看到他们的修改在他们完成工作后几分钟就上线了。基本上，当开发人员在主分支中合并一个提交时，这个分支将被构建、测试，如果一切顺利，则部署到生产环境中。

合并CI CD and CD？

当然，正如我所说，他们每部分都更加接近生产环境。你可以构建自己的持续集成环境，然后，一旦团队适应，你可以添加持续交付流，最后，可以添加持续部署流到整个工作流中。



举例CI, CD and CD 流水线

到底值不值这样做呢?

持续集成:

你需要具备哪些条件:

你的团队需要为每个新功能，代码改进，或者问题修复创建自动化测试用例。
	
你需要一个持续集成服务器，它可以监控代码提交情况，对每个新的提交进行自动化测试。
	
研发团队需要尽可能快的提交代码，至少每天一次提交。
你能获得什么呢？:

通过自动化测试可以提早拿到回归测试的结果，避免将一些问题提交到交付生产中
	
发布编译将会更加容易，因为合并之初已经将所有问题都规避了
	
减少工作问题切换，研发可以很快获得构建失败的消息，在开始下一个任务之前就可以很快解决。
	
测试成本大幅降低-你的CI服务器可以在几秒钟之内运行上百条测试。
	
你的QA团队花费在测试上面的时间会大幅缩短，将会更加侧重于质量文化的提升上面。
持续交付

需要具备什么条件？:

你需要有强大的持续集成组件和足够多的测试项可以满足你代码的需求
	
部署需要自动化。触发是手动的，但是部署一旦开始，就不能人为干预。
	
你的团队可能需要接受特性开关，没有完成的功能模块不会影响到线上产品。
你能收获什么？:

繁琐的部署工作没有了。你的团队不在需要花费几天的时间去准备一个发布。
	
你可以更快的进行交付，这样就加快了与客户之间的反馈环。
	
轻松应对小变更，加速迭代
持续部署

需要具备的条件:

研发团队测试理念比较完善。测试单元的健壮性直接决定你的交付质量。
	
你的文档和部署频率要保持一致。
	
特征标志成为发布重大变化过程的固有部分，以确保您可以与其他部门（支持，市场营销，公关…）协调。
可以获得什么？:

发布频率更快，因为你不需要停下来等待发布。每一处提交都会自动触发发布流。
	
在小批量发布的时候，风险降低了，发现问题也可以很轻松的修复。
	
客户每天都可以看到我们的持续改进和提升，而不是每个月或者每季度，或者每年。
如前所述，您可以采用持续集成，持续交付和持续部署。你怎么做取决于你的需求和你的业务情况。如果你刚刚开始一个项目，并且还没有客户，那么你就可以去创建这些工作流，最好是将这三个方面都实现，并且在你的项目迭代和需求增长中同时迭代它们。如果您已经有一个生产项目，那么您可以一步一步地分阶段去实现他们。

 

from：http://www.ttlsa.com/news/ci-cd-cd/