第一章 Linux常用软件一、Linux目录结构 ./bin
这个目录存放着最经常使用的命令
./sbin
s就是super user，存放着系统管理员使用的系统程序
./home
存放普通用户的主目录
./root
该目录为系统管理员，也称为超级权限者的用户主目录
./lib
系统开机时所需要的最基本的动态链接共享库
./lost+found
这个目录一般为空，当系统非法关机时，这里就存放一些文件
./etc
所有系统所需要的配置文件和子目录
./usr
这是一个非常重要的目录，用户很多应用程序和文件都放在这个目录下
./boot
存放的是启动linux时使用的一些核心文件，包括连接文件和镜像文件
./proc
./sys
./srv
这三个文件内容都不能动，否则系统会崩溃
./temp
存放一些临时文件
./dev
类似于windows的设备管理系统，把所有的硬件用文件的形式存储
./media
linux 系统会自动识别一些设备，例如u盘，光驱等
./mnt
系统提供该目录是为了让用户临时挂载别的文件系统
./opt
这是给主机额外的安装文件所存放的目录
二、远程登录linux-Xshell6介绍Xshell 是目前最好登录到Linux操作的软件，流畅的速度并且完美的解决了中文乱码的问题Xshell是一个强大的安全终端模拟软件，它支持SSH1、SSH2以及Microsoft Windows平台的TELNET协议Xshell可以在Windows界面下用来访问远端不同程序下的服务器，从而比较好的到达远程控制终端的目的Xshell使用操作登录远程服务器通过linux操作系统ifconfig获取ip地址：192.168.246.128新建会话，输入ip地址连接快捷键
Alt + N：新建会话Alt + S：简单模式Alt + R：透明模式Alt + A：总在最前面Alt + Enter：全屏Alt + 1 ：切到第一个会话，2，3，4…类推Ctrl + Alt + F：新建传输文件Ctrl + Shift + L：清屏Ctrl + Insert ：复制Shift + Insert ：粘贴
三、远程上传下载软件 Xftp6介绍是一个基于windows平台功能强大的SFTP、FTP文件传输软件处理中文乱码修改编码为UTF-8四、vi和vim编辑器介绍Linux系统会内置vi文本编辑器Vim具有程序编辑能力，可以看做Vi的增强版本，可以用字体的颜色辨别语法的正确性，方便程序设计vi和vim常用的三种模式 正常模式 以vim打开一个档案就直接进入一般模式。在这个模式下可以使用【上下左右】按键来移动光标，可以使用【删除符号】来进行档案内容处理，也可以使用【复制、粘贴】来处理文件数据
插入模式 按下 i 、I 、o、O、a、A、r、R等任何一字母才会进入的编辑模式，一般来说按 i 即可
命令行模式 输入esc 在输入：进入，在这个模式下，可以提供你相关的指令，完成读写、存盘、替换、离开vim、显示行号等的动作则在此模式中达成 正常模式命令命令说明w移动到下一个单词的开头e移动到当前单词的结尾b移动到上一个单词的开头ge移动到前一个单词的结尾^移动到行头$移动到行尾f<字母>向后搜索<字母>并跳转到第一个匹配的位置F<字母>向前搜索<字母>并跳转到第一个匹配的位置shift+zz退出vimdd删除整行2dd向下删除2行，以此类推d$或D删除至行尾d^删除至行首.(小数点)重复上一次的命令操作gg游标移动到第一行G游标移动到最后一行nG游标移动到第n行（如果默认没有显示行号，请先进入命令行模式，输入:setnu以显示行号）Ctrl+o快速回到上一次（跳转前）光标所在位置yy复制游标所在的整行3yy向下复制3行，以此类推p粘贴至光标后R连续替换，直到按下Esc>>整行向右缩进<<整行向左回退插入模式命令命令说明i在当前光标处进行编辑I在行首插入A在行末插入a在光标后插入编辑o在当前行后插入一个新行O在当前行前插入一个新行cw替换从光标所在位置到一个单词的结尾字符命令行模式的命令命令说明:q!强制退出vim，不保存:q退出vim:wq!强制保存并退出vim:w<文件路径> 另存为:saveas<文件路径> 另存为:x保存并退出vim:wq保存并退出vim:set nu显示行号:set shiftwidth=10设置缩进为10个字符，以此类推（输入Esc回到普通模式，再次尝试>>看缩进是否变化）:ce(center)本行内容居中:ri(right)本行内容居右:le(left)本行内容居左命令行下 /+关键字，回车在文件中查找某个单词，输入n查找下一个vim键盘图第二章 Linux操作系统命令一、关机&重启命令shutdown -h now立刻进行关机shutdown -h 1一分钟后会关机shutdown -r now现在重新情动计算机halt关机，作用和上边一样reboot现在重新启动计算机sync把内存的数据同步到磁盘二、用户登录和注销登录时尽量少使用root账号进行直接登录，可以先登录普通账号，再用==su - 用户名 ==命令来切换管理员身份在提示符下输入logout 即可注销用户logout 注销指令在图形运行级别无效，在运行级别3下有效三、用户管理用户添加用户useradd 【选项】用户名选项作用-d指定用户登录时的目录-e指定用户的有效期限-f缓冲天数，密码过期时在指定天数后关闭该账号-g指定用户所属组-G指定用户的附加组-m自动创建用户的登录目录-r创建系统账号-s指定用户的登录shell-u指定用户的用户ID设置和修改密码设置用户密码 passwd [选项] 用户名，修改密码也使用同样的语法格式选项：选项作用-l锁定密码，锁定后密码失效，无法登录-d删除密码，仅系统管理员可用-S列出密码的相关信息，仅管理员可使用-f强制执行删除用户删除用户userdel [选项] 用户名选项作用-f强制删除，即使是当前用户-r删除用户的同时，删除与用户相关的所有文件，慎重选择查询用户信息：id 用户名查看当前登录用户 ： whoami用户组介绍系统可以对有共性/权限的多个用户进行统一的管理新增组指令：groupadd 组名删除组指令： groupdel 组名增加用户是直接加上组指令： useradd -g 用户组 用户名
groupadd mingjiaouseradd -g mingjiao zhangwuji
修改用户组指令：usermod - g 用户组 用户名用户和组相关文件/etc/passwd 文件用户（user）的配置文件，记录用户的各种信息每行含义：用户名：口令：用户标识号：注释性描述：主目录：登录Shell/etc/shadow 文件口令的配置文件每行含义：登录名：加密口令：最后一次修改的时间：最小时间间隔：最大时间间隔：警告时间：失效时间：标志/etc/group 文件组（group）配置文件, 记录Linux包含组的信息每行含义：组名：口令：组标识号：组内用户列表四、指定运行级别运行级别说明0关机1单用户工作状态，root权限，用于系统维护，禁止远程登陆2多用户状态(没有NFS)3完全的多用户状态(有NFS)，登陆后进入控制台命令行模式4系统未使用，保留5X11控制台，登陆后进入图形GUI模式6系统重启应用实例命令：init [0123456] 通过init 来切换不同的运行级别应用案例：init 0 实现关机查看当前运行级别: systemctl get-default设置运行级别:systemctl ser-default multi-user.target //设置为三级别systemctl ser-default graphical.target//设置为五级别五、帮助指令man 获得帮助指令基本语法：man[命令或配置文件]（获得帮助信息）help指令基本语法：help 命令（获得shell内置命令的帮助信息）六、文件目录类指令pwd指令基本语法：pwd （显示当前工作目录的绝对路径）ls指令基本语法：ls [选项][目录或者文件]选项作用-a显示隐藏文件-l以列表显示信息cd指令基本语法：cd[选项] （切换到指定目录）选项作用~当前用户家目录/根目录-上一次访问的目录…上一级目录mkdir指令基本语法：mkdir [选项] 要创建的目录 （实现在指定位置创建命名的文件夹或目录）选项作用-p创建多级目录rmdir指令基本语法：rmdir[选项] 要删除的空目录（删除空目录）rmdir 删除的是空目录，如果目录下有内容时无法删除要删除非空目录，需要 rm - rf 要删除的目录touch指令基本语法：touch 文件名称（创建空文件）cp指令基本语法：cp [选项] 要拷贝的文件 文件拷贝到的位置（拷贝文件到指定目录）选项作用-r递归复制整个文件夹cp 前加“\”强制覆盖不提醒rm 指令基本语法：rm [选项] 要删除的文件或者目录（移除文件或目录）选项作用-r递归删除整个文件-f强制删除不提示mv指令基本语法：mv oldnamefile newnamefile（重命名）mv 目录A下的文件 目录B（移动文件）cat指令基本语法：cat [选项] 要查看的文件选项作用-n显示行号cat只能浏览文件，而不能修改文件，为了浏览文件方便，一般会带上 管道命令|moremore指令more指令是一个基于VI编辑器的文本过滤器，他以全屏的方式按页显示文本文件的内容，more指令内置了若干快捷键（交互指令）基本语法： more 要查看的文件操作功能说明space代表性向下翻一页Enter代表向下翻【一行】q代表立即离开more，不显示文件内容ctrl+f向下滚动一屏Ctrl+B返回上一屏=输出当前行的行号:f输出文件名和当前行的行号less指令基本语法：less 要查看的文件（用来分屏查看文件内容）操作功能space向下翻滚一页pagedown向下翻动一页pageup向上翻动一页/字串向下搜寻【字串】的功能；n:向下查找；N：向上查找?字串向上搜寻【字串】的功能；n:向上查找；N：向下查找q离开lessecho指令echo输出内容到控制台基本语法：echo [选项] [输出内容]head指令head显示文件的开头部分内容，默认情况下head指令显示文件前10行内容基本语法：head 文件（查看文件头10行内容）head -n 文件 （想查看文件头5行内容，5可以为任意数）>指令和>>指令
'>'输出重定向（覆盖），>>追加
基本语法：ls - l > 文件（列表的内容写入文件中（覆盖写））ls - l >> 文件（列表的内容追加到文件中的末尾）cat 文件1 >文件2 （将文件1的内容覆盖到文件2）echo “内容” >>文件（追加）In指令In - s [源文件或目录] [软连接名]（给原文件创建一个软链接）七、时间日期指令date指令基本语法：date （显示当前日期）+%Y显示当前年份+% m显示当前月份+%d显示当前是哪一天+%Y+%m+%d %H:%M:%S显示年月日时分秒-s 字符串日期设置日期cal指令基本语法：cal cal [选项][月份][年份]（查看日历指令）选项作用-1显示一个月的月历-3显示系统前一个月，当前月，下一个月的月历-s显示星期天为一个星期的第一天，默认的格式-m显示星期一为一个星期的第一天-j显示在当年中的第几天（一年日期按天算，从1月1号算起，默认显示当前月在一年中的天数）-y显示当前年份的日历八、搜索查找类指令find指令寻找条件从我们给出的目录开始对其中文件及其下子目录中的文件进行递归搜索，将满足条件的文件或者目录显示在终端基本语法：find [搜索范围] [选项]选项说明- name <查询方式>按照指定的文件名查找模式查找文件- user<用户名>查找指定用户名所有文件- size<文件大小>按照文件大小查找文件locate指令locate 指令能够快速定位文件路径基本语法：locate 搜素文件由于locate指令基于数据库进行查询，所以第一次运行前，必须使用updatedb指令创建locate数据库grep指令和管道符号|grep过滤查找，管道符 “|”，表示前一个命令处理结果输出结果传递给后面的命令处理基本语法：grep [选项] 查找文件 源文件选项作用-n显示匹配行和行号-i忽略文字大小写案例：请在aaa.txt文件中，查找“yes”所在行，并显示行号写法1：cat/home/aaa.txt
grep -n “yes”写法2：grep -n “yes” /home/aaa.txt九、压缩与解压指令gzip/gunzip指令gzip用于压缩文件，gunzip用于解压文件基本语法：gzip 文件 （压缩文件，只能将文件压缩为*.gz文件）gunzip 文件.gz （解压缩文件命令）zip/unzip指令zip用于压缩文件，unzip用于解压文件基本语法：zip [选项] xxx.zip 将要压缩的内容（压缩文件和目录命令）选项作用-r递归压缩，即压缩目录unzip [选项] XXX.zip（解压缩文件）选项作用-d <目录>指定压缩后文件存放目录tar指令tar指令是打包指令，最后打包的文件是.tar.gz文件基本语法：tar [选项] xxx.tar.gz 打包文件选项作用-c产生.tar 打包文件-v显示详细信息-f指定压缩后的文件-z打包同时压缩-x解包.tar文件压缩 ： tar -zcvf pa.tar.gz aaa.txt bbb.txt解压：tar -zxvf pa.tar.gz -C(解压到指定路径) /opt/tmp2十、组管理和权限管理在Linux中每个用户必须属于一个组，不能独立于组外，在Linux中每个文件有所有者、所在组、其他组的概念组 所有者一般为文件的创建者，谁创建了该文件，就自然成为文件的所有者查看文件所有者指令：ls -ahl修改文件所有者指令：chown 用户名 文件名
所在组创建组：groupadd 组名查看文件所在组：ls -ahl修改文件所在组：chgrp 组名 文件名
其他组除文件的所有者和所在组的用户外，系统的其他用户都是文件的其他组
改变用户所在组
usermode -g 新组名 用户名usermod -d 目录名 用户名（改变该用户登录的初始目录（用户需要又有进入新目录的权限））
权限用 ll 或 ls -l 命令可以显示目录下所有文件详细信息(不包括隐藏文件), 如下图在每个文件信息开头的 d - w r x 共10位是什么信息呢, 是文件对于不同文件访问者的权限, 具体如下图 :文件类型说明d文件夹-普通文件l软链接（类似Windows的快捷方式）b块设备文件（例如硬盘、光驱等）p管道文件c字符设备文件（例如屏幕等串口设备）s套接口文件修改权限介绍Linux系统中，每个文件或目录都有访问许可权限，用它来确定以何种方式对文件或目录进行访问和操作。在Linux中，如果要对文件的权限进行修改，那么可在终端中使用 chmod 命令对其文件的权限进行修改，但是 chmod 命令修改文件权限有两种方式：1、字母法，2、数字法第一种方法：+、-、= 变更权限u:所有者 、q:所有组、o:其他组、a:所有人chmod u=rwx , g=rx , o=x 文件名/目录名chmod o+w 文件名/目录名（给其他组赋予写权限）chmod o-x 文件名/目录名（去除其他组执行权限）第二种方法：通过数字变更权限r = 4 w = 2 x = 1chmod 751 文件名/目录名修改文件所有者chown newowner 文件/目录 （改变所有者）chown newowner : newgroup 文件/目录 （改变所有者和所在组）-R 如果是目录 则是其下所有子文件或目录递归生效修改文件/目录所在组chgrp newgroup 文件/目录（改变所在组）-R 如果是目录 则是其下所有子文件或目录递归生效第三章 Linux实操篇一、定时任务调度crontab 重复执行定时任务选项作用-e编辑crontab定时任务-l查询crontab任务-r删除当前用户的所有项目含义第一个“*” 0-59一小时当中的第几分钟第二个“*” 0-23一天当中的第几小时第三个“*” 1-31一个月当中的第几天第四个“*” 1-21一年当中的第几个月第五个“*” 0-7一周当中的星期几案例：crontab -e 进入调度文件 输入：’* /1*** ls -l >> to.txt’，意思是说每小时每分钟执行一次* /1*** ls -l >> to.txt’命令特殊字符特殊符号含义星号(*)代表任何时间，例如，month字段如果是星号，则表示在满足其它字段的制约条件后，每月都执行该命令操作；逗号(,)代表不连续时间，比如‘0 8,12,16 * * * *’，代表每天的8点0分，12点0分，16点0分都要执行一次命令中杠(-)表示连续的时间范围，例如“0 5 * * 2-6”表示：，代表了周二到周六凌晨5点0分执行任务/ , */n可以用正斜线指定时间的间隔频率，例如“0-23/2”表示每两小时执行一次。同时正斜线可以和星号一起使用，例如*/10 * * * *，表示每十分钟执行一次。at 一次性执行定时任务基本介绍1.ta命令试一次性定时计划任务，at守护进程atd会以后台模式运行，检查作业列来运行2.在使用at命令时，一定要保证atd进程启动，可以用ps -ef
grep atd来检查进程是否在运行at命令格式at [选项] [时间]Ctrl + D 结束 at指令输入选项作用-m当指定的任务被完成之后，将给用户发送邮件，即使没有标准输出-Iatq的别名-datrm的别名-v显示任务将被执行的时间-c打印任务的内容到标准输出-V显示版本信息-q<列队>使用指定的列队-f<文件>从指定文件读入任务而不是从标准输入读入-t<时间参数>以时间参数的形式提交要运行的任务时间格式，这里可以定义出什么时候要进行 at 这项任务的时间，格式有：格式说明HH:MM（小时：分钟）ex> 04:00 在今日的 HH:MM 时刻进行，若该时刻已超过，则明天的 HH:MM 进行此任务HH:MM[am\pm] [Month] [Date]ex> 04pm March 17也是一样，强制在某年某月某日的某时刻进行该项任务案例一：两分钟后执行/bin/ls/homeat now + 2 minutes案例二：2天后的下午5点执行/bin/ls/home输入两次Ctrl +D退出at命令atq命令来查看系统中有没有执行的工作任务atrm 编号 删除已经设置的任务二、磁盘分区、挂载原理介绍1）Linux无论有几个分区，分给哪一目录使用，归根结底只有一个根目录，一个独立且唯一的文件结构，Linux中每个分区都是用来组成整个文件系统的一部分。2）Linux中采用了一种叫 “载入” 的处理方法，它的整个文件系统中包含了一整套的文件和目录，且将一个分区和一个目录联系起来。这时要载入的一个分区将使它的存储空间在一个目录下获得硬盘说明1）Linux硬盘分IDE硬盘和SCSI硬盘，目前基本上都是SCSI硬盘2）对于IDE硬盘，驱动标识为hdx，其中hd分区所在的设备类型，这里指IDE硬盘了。x为盘号（a为基本盘，b为基本从属盘，c为辅助盘，d为辅助从属盘），代表分区，前4个分区用数字1~4表示，他们是主分区或扩展分区，从5开始就是逻辑分区。如：hda3表示为第一个IDE硬盘上的第三个主分区或扩展分区3）对于SCSI硬盘则标识为sdx~，SCSI硬盘是用sd来表示分区所在设备的类型的，其余则和IDE硬盘的表示方法一样。查看所有设备挂载情况命令：lsblk 或者 lsblk -f挂载的经典案例1）虚拟机添加硬盘在 VMware下：虚拟机—>设置—>硬盘—>添加—>下一步（4）—>完成—>重启Linux2）分区分区命令： fdisk /dev/sdb选项作用m显示命令列表p显示磁盘分区n新增分区d删除分区w写入并退出说明：开始分区写入n，新增分区，然后选择p，分区类为主分区，两次回车默认剩余的全部空间。最后输入w写入分区并退出，若不保存退出输入q3）格式化命令：mkfs -t ext4 /dev/sdb1，其中ext4是分区类型4）挂载先创建一个目录 /home/newdisk命令：amount 设备名 目录名但是如果重启这种挂载关系就会消失了！！！！！5 ) 卸载命令：umount 设备名称 或者 挂载目录6）设置可以自动挂载（永久挂载，当你重启Linux之后，仍然可以挂载）永久挂载：通过修改 /etc/fstab 实现挂载添加完成后 执行 mount -a 立即执行三、磁盘情况查询基本语法df -h查看指定目录磁盘占用情况du -h /目录查看指定目录的磁盘占用情况，默认是当前目录-s指定目录占用大小汇总- h带计量单位- a含文件- -max-depth=1子目录深度- c列出明细的同时，增加汇总值。实例：查询 /opt 目录的磁盘占用情况，深度为1磁盘情况 — 工作实用指令1）统计 /home 文件夹下文件的个数2）统计 /home 文件夹下目录的个数3）统计 /home 文件夹下文件的个数，包括子文件夹里的4）统计文件夹下目录的个数，包括子文件夹里的5）以树状显示目录结构（yum install tree 安装tree指令）四、Linux 网络配置NAT网络设置网络地址转换技术NAT（network address translation）主要用于实现位于内部网络的主机访问外部网络的功能。当局域网内的主机需要访问外部网络时，通过NAT技术可以将其私网地址转换为公网地址，并且多个私网用户可以共用一个公网地址，这样既可保证网络互通，又节省了公网地址。查看网络IP和网关查看windows环境下VMnet8网络配置（ipconfig指令）查看 Linux 的网络配置（ifconfig指令）ping 目的主机（测试当前主机是否能够联通目的主机）指定 IP直接修改配置文件来指定IP，并可以连接到外网,(程序员推荐)，
编辑 vim /etc/sysconfig/network-scripts/ifcfg-eth33
要求：将ip地址配置的静态的，比如：ip地址为192.168.200.130
ifcfg-eth0文件说明DEVICE=eth0 #接口名（设备,网卡）HWADDR=00:0C:2x:6x:0x:xx #MAC地址TYPE=Ethernet #网络类型（通常是Ethemet）UUID=926a57ba-92c6-4231-bacb-f27e5e6a9f44 #随机idONBOOT=yes #系统启动的时候网络接口是否有效（yes/no）BOOTPROTO=static #IP的配置方法[none|static|bootp|dhcp]（引导时不使用协议|静态分配IP|BOOTP协议|DHCP协议）IPADDR=192.168.200.130 #IP地址GATEWAY=192.168.200.2 #网关DNS1=192.168.200.2 #域名解析器配置好以后重启服务器或者网络服务生效设置主机名和hosts映射五、进程进程管理基本介绍在Linux中，每个执行的程序都可以称为一个进程，每个进程都分配一个ID号（pid，进程号）每个进程都可能以两种方式存在。前台与后台，所谓前台进程就是用户目前的屏幕上可以进行的操作的；后台进程，但由于屏幕上无法看到进程，通常使用后台方式执行一般系统都是以后台进程的方式存在的，而且都是常驻在系统中，直到关机才结束显示系统执行的进程psps 命令是用来查看目前系统中哪些正在执行的程序，以及它们的执行情况选项说明-a列出所有运行中/激活进程-u以用户的格式显示进程信息-x显示后台进程运行的参数-ef以全格式显示当前所有进程 ， -e 显示所有进程，-f 全格式-aux显示进程信息，包括无终端的（x）和针对用户（u）的进程：如USER, PID, %CPU, %MEM等USER进程执行者PID进程号%CPU占用cpu的百分比%MEM占用物理内存百分比VSZ占用虚拟内存大小RSS占用物理内存大小TTY终端名称STAT运行状态，S 表示sleep睡眠状态，R表示运行状态，D 表示短期等待，Z 表示僵死进程，T被跟踪或者被停止START进程的开始时间TIME进程占用CPU时间COMMAND进程名，即执行该进程的指令1.指令：ps - aux
grep xxx 显示过滤后的进程信息，包括无终端的（x）和针对用户（u）的进程：如USER, PID, %CPU, %MEM等2.指令：ps - ef
grep xxx 以全格式显示当过滤后的进程 ， -e 显示所有进程，-f 全格式终止进程（kill 和 killall）基本语法kill [选项] 进程号（通过进程号杀死进程）killall 进程名称（通过进程名称杀死进程，也支持通配符，这在系统因为负载过大而变得很慢很有用）常用选项-9 ：表示强迫进程立即停止案例1：踢掉某个非法登录用户进程树 pstree服务管理基本介绍查看服务名使用setup -> 服务器系统就可以看到全部服务chkconfig 指令systemctl 指令firewall 指令查看端口协议指令：netstat - anp
more动态监控进程动态监控 top 指令查看系统网络信息netstat指令六、软件包管理rpm 包管理yum 指令七、Linux-java 定制篇安装 JDK安装 tomcat安装 IDEA安装MySQL5.7第四章 Shell编程Shell是一个命令解释器，它为用户提供了一个想Linux内核发送请求以便运行程序的界面系统程序，用户可以使用Shell来启动、挂起、停止，甚至编写一些程序Shell 脚本的执行方式脚本格式要求1.脚本要以 #!/bin/bash 开头2.脚本需要有可执行权限,用 chmod 指令脚本的常用执行方式方式一：输入脚本的绝对路径和相对路径说明：首先要赋予脚本可执行权限，再执行脚本方式二：sh + 脚本说明：不需要赋予脚本可执行权限，直接执行即可Shell 的变量反引号 : 1 前面的键 ~ 的另外一种表示 `环境变量位置参数变量预定义变量运算符条件判断流程控制if语句case语句for循环while循环read 读取控制台输入函数系统函数自定义函数数据库备份第五章 日志管理一、日志文件基本介绍系统常用日志二、日志管理服务rsyslodg三、日志轮替四、查看内存日志第六章 创建自己的Linux系统基本原理操作步骤1.在现有的Linux系统加一个20G硬盘2.分区挂载fdisk /dev/sdb 分为两个区5.安装grub，内核文件拷贝至目标磁盘== grub2-install --root-directory=/mnt /dev/sdb==可以通过查看二进制确认我们是否安装成功hexdump -C -n 512 /dev/sdb6.将 boot内文件全部复制到mnt/boot/rm -rf /mnt/boot/* //清除掉/mnt/boot内文件cp -rf /boot/* /mnt/boot/ //复制文件7.进入grub2/grub.cfg文件，找到框选位置进行修改上下两个操作都是相同的，修改六次，添加两次mkdir -pv /mnt/sysroot/{etc/rc.d,usr,var,proc,sys,dev,lib,lib64,bin,sbin,boot,srv,mnt,media,home,root}cp /lib64/. /mnt/sysroot/lib64/cp /bin/bash /mnt/sysroot/bin/创建一个新的虚拟机创建好虚拟机以后，将原先自带的硬盘移除添加现有磁盘找到之前挂载好的磁盘成功进入界面第七章 Linux 备份与恢复如果Linux上没有dump 和 restore 指令，需要先按照yum -y install dumpyum -y install restore下载相关指令dump-备份restore 恢复第八章 Linux可视化管理工具webminbt宝塔

本文原作者Jeb Barabanov是开源项目angular-builders, jest-marbles, drummer, kite-surfer, gamer和writer的管理者。以下全文翻译李霄。01 什么是开源广义定义—开源是信息可以公开获得，允许复制和修改的概念。在软件开发领域—开源是一种去中心化和鼓励合作的模式。主要原则包括：并行生产，公众可以免费获得相关产品，如源代码和文本等。开源模式有什么好处呢？可想而知的一个主因是开放有益于收获合作者。Together we’re strong. (Zarya, 2016)以维基百科Wikipedia为例子，它的创始人Larry Sanger最早一个人一年只能产出12篇文章。而如今维基百科拥有3789万+的注册用户，其中13万+活跃用户,这就相当于维基百科有13万+的贡献者在编写着维基百科的文章，维基百科现在一共有6百万的海量词条文章。就如同维基百科用户提交文章，然后由编辑审核通过一样；开源软件的贡献者提交拉取请求（pull request, PR），然后由开源软件管理者审核通过提交的代码。（译者：在教育界，开源教科书也开始兴起了，起源于UC Davis的网络开源、免费的网络教科书LibreTexts平台近几年引领了美国教育界的开源风潮，很多美国大学都开始使用这个平台。在这个平台上，教师账户可以自定义自己的教科书，可以对平台上已有的开放教材进行改编应用于自己的课堂，教师分享了这个版本以后，也可以供其它教师直接使用或改编。很多学生都受益于这个项目。）02 创立开源软件的动机虽然寻求合作者是选择开源模式的主因，但大部分人并不单单为这一个原因，通常还有其他原因，一些常见的动机和情景总结如下：你想解决的问题目前市面上没有免费的解决方案（软件）你遇到了一个问题，目前市面上没有软件可以解决这个问题，或者说相关软件需要付费获取。你把这问题解决了，你对你的工作非常兴奋，你也相信你的工作会给他人带来便利，于是你把你的工作变成一个开源软件。你想成为一个创始人你想要成为一个开源软件项目的创始人，这样你就可以在你的简历上添上华丽的一笔。你想要实现自我的成功（毕竟我们都是人）。如果这是驱使你启动一个开源项目的主要原因，那么我可以向你保证，当你读完这篇指南你就会从新考虑了，为了这个原因不值得这么做。你想比别人更好的解决一个问题你遇到了一个问题，在市面上有一个开源软件能解决这个问题，但是你认为它不够好或并不完全是你想要的。如果你完全处于想要做的比当前市面上的开源软件好而启动了一个全新的软件项目，那么这基本上属第#2种原因（为了实现自我成功）。与其开启一个全新的开源软件项目，你不如做一个贡献者，给当前存在的软件提交pull request (PR).如果提交PR不是当前该开源软件版本的一个选项，那么你可以考虑扩展它，或者是重复利用该软件中的相关功能，这样可以让你之后省去很多头疼的事情。你想通过创立开源软件的方式解决一个问题你遇到了一个问题，目前市面上没有软件可以解决这个问题，于是你开启了一个开源软件项目，希望这样可以找到解决方案。在我看来，不一定。你应当先解决这个问题，确保你写的软件有用，然后回到第1个原因。以上是我经常见到的四个动机，在此指南中，我主要关注第1个原因。原因很简单，如果你开启一个开源项目的初心不是想要分享和贡献出你所做的工作，是走不长远的。会有很长一段时间，你所得到的就是你曾帮助他人。如果这不是你寻求的满足感，那么你就不用浪费时间往下读了。在这里，还值得一提的还有另外一种情况，有时候一些公司会向社区开放部分源码，比如，谷歌维护的Angular，脸书维护的React,微软维护的VSCode等等。这些公司开放源码的原因可能各有不同，但一定都包含寻求合作者这一条原因。我不用强调这一做法的重要性，但我想指出这种情景和我们所说的其它开源软件都不太相同，因为在这种情境中，相关开源软件的维护者是相应公司的员工拿着相应公司的薪水。如果你属于这种情况，那么这篇指南的大部分内容对你也会有所帮助，但我们的动机就是不同的。用一句话总结这一部分就是：确认你的目的和你的期望是一致的。03 如何启动一个开源软件项目那么，你现在属于第1种情况——你有一个解决特定问题的方法，你期待与大家分享：我们再强调一次：这无关你的抱负你不指望从中获利你是真心想帮助那些和你遇到同样问题的人如果你对以上回答都是“是”的话，那么以下是可以帮助你做对这件事的一个清单：确认开源软件是正确的打开方式。如果你想要分享的方案不足以构成一个软件，那么你通过一个部落格的分享也许就够了。再三确认市面上并没有相似的方案。如果有的话，也许你的方案可以成为已有开源软件的一个完美PR.为即将发生的事做好准备就如我之前提到的，管理一个开源软件项目有很多挑战。其中最突出的挑战，就是这个任务将会花费你大量的时间。你所做的每一件事都要花时间，无论你是写代码，管理议题（issues），更新相关项，和人们交谈，回答问题，等等。你投入到开源软件的每一分钟都将减少你对家人，业余爱好和健康方面投入的一分钟。你可以做的更好的最好途径就是开始委派任务，当你有足够多的合作者的时候，你就可以“外包”一部分你的责任给那些你信任的人。代码分离进入正题，你现在已经写了一个解决某特定问题的软件，你也认为其他人能从中获益。你的软件代码此时还是你的代码库的一部分，如果你不是想开放你代码库的全部内容，那么你首先应该把你要开源的那部分代码从你自己的代码库中分离出来并放到另外一个目录下。普适化你的代码你要确保你新目录下的代码是普遍适用的而不是只能解决某一个特定的问题。需要的时候，做一个抽象层。举一个例子，我开始做angular-builder的起因是为了解决一个非常特定的问题，（这个问题来源于我的另外一个开源软件项目），当时我想要将本机模块的自定义加载器添加到Angular build中。我当时可以写一个native-module-builder来只为解决这一问题。然而，我意识到，我可以投入相对较少的经历把代码写得更通用一些，这样我的代码就可以解决其它类似但不完全相同的问题。custom-webpack builder就是这样诞生的。让事情简单些通用性虽好，且追求且谨慎。“过度优化”和“过于通用”是两个软件工程里众所周知的问题，你应当在这两个极端之间寻求一个平衡点----你的代码应该在解决你的一个特定问题之外还能解决其它的类似问题，但却不是全世界的所有问题。说得形象一点，如果从1到100，只解决你自己的特定问题是1，能解决世界上的全部问题是100，那么你应该从2开始。尽量多用你自己开发的软件多在你的代码库里使用你将要分享的这份具有通用性的代码—这会帮助你去除那些你不需要的部分。这也保证你将要开源的这部分代码运行是正常的。记住，你是你的开源软件的第一个用户。不要吃官司如果你要从你所在公司的代码库中分离出一部分代码，一定要咨询你的上峰，有必要时咨询法务部门。确保公司支持你的倡议，也要确保你想要开源的代码不属于你公司的知识产权。这个咨询的过程也会帮你确定哪种开源许可证更适用于你的项目。发表你的代码开源软件，顾名思义，就是要开放你的软件源码。公开源码的途径有不少，但我们这个攻略里默认你用的是GitHub.首先，在GitHub上创建一个仓库（repository）.克隆这个仓库把你的开源代码拷贝到这个目录下（暂时还不要删除原先那个源代码的目录）。提交及推送（Commit & push）--大功告成，现在该软件是个开源软件了。创建安装包现在你的软件已经开源了，但还没有用户。现在还没人指导它的存在。并且，你的软件现在是以源代码的形式呈现在网上，用户只有把这些代码拷贝+粘贴到你的代码库才能使用。这并不是很方便，对吧？为了更合理地分发你的软件，你需要：把你的源代码创建成一个安装包。把这个安装包发布在一个公开的安装包注册平台（选择什么安装包注册平台，取决于你所在行业的生态。比如，Java软件通常选择Maven Central Repository,如果是Javascript的话，你应当选择Npm Package Registry）。这正是你在你的新仓库里加入一个构建链,确定你的软件名字等等这些事情的时候。我在这里就不展开叙述了，因为这取决于你所在的生态，你所用的工具和编程语言。如果你是一个自己做一切的人，命名软件项目，加入构建链和生成安装包对你来说都是小事一桩的话，那么恭喜你！但如果你是一个比较习惯于只写代码，但从未处理过定义(defining)，配置（configure），构件(artifact)，等这类事情，那么前方有一个全新的世界等你来学习。如果你是后一类人，那么你得开始学习了。这不会是很速成的事情，但相信我，你会学会的。在你的软件大红大紫以前，确保它能正常运行。再强调一次，你是你自己开源软件的第一个用户。总而言之，当你做完这一切— 把安装包发布了，这个时候你才能说你的软件是一个开源软件了。这个时候，你就可以大声的告诉大家，”嗨，这个软件可以解决你的问题，去下载和使用吧！“如何处理后续的开发当你在你开始使用你软件的安装包时，工作流程就会有所不同。之前，你的软件代码是你的代码库的一部分，如果有什么修改，你马上就能用上。但现在，你的软件相当于一个外来的安装包，和任何你使用的第三方软件无异。所以，以下是一些能帮你规避提交问题版本的几点建议：确保你的新版本被充分的测试了，包括单元测试，和端到端测试。关于测试的重要性，我无需再强调了吧。在你的本地环境里，打包和安装你的软件，确保每个环节都按期待进行，接下来你就可以发布这个新版本了。先给想要的用户分发beta版本，而不是一次性就把新版本发布给全世界。举一个例子，在npm package registry平台上，dist tags (分发标签)就是用来做这个事的。默认的标签是latest。也就是说当你运行npm install mypackage的时候，程序默认运行npm install mypackage@latest.当你把你的版本标上不同的标签，比如beta的时候，用户就需要专门强调他或她要安装的是beta版本：npm install mypackage@beta .看到这里，我再问你一次，你想好要把你宝贵的时间投入到开源社区了吗？04 如何写文档这一部分内容基于一个基础，这就是：你已经有一个开源软件了，它已经在GitHub上了。为什么要写文档，文档包括哪些？一个没有文档的开源软件是没前途的。没有前途是因为没有人会仔细研究你的代码来搞清这个软件应该怎么用，甚至连你的软件是干什么用的都不知道。你的文档应该包含两样最基本的东西– 用途 和 操作方法。这些是文档的必要构成部分。如何写项目说明（description）说明是人们进入到你的GitHub仓库看到的第一则信息，所以一则好的说明应当简明扼要地描述软件的用途。提供以下三个例子给你作为参考：React的说明：A declarative, efficient, and flexible JavaScript library for building user interfaces. https://reactjs.orgMoment.js的说明：Parse, validate, manipulate, and display dates in JavaScript. http://momentjs.comAngular builders（这是原文作者的项目）的说明：Angular build facade extensions (Jest and custom webpack configuration)你可以在仓库的About部分修改说明。如何写自述文件README.mdREADME.md是一个在你项目的根目录里，用标记语法(markdown syntax)书写的包含用户所需的全部信息的文本。README.md文本应当包括软件用途更细节的描述以及详细操作方法。操作方法应当包含公共应用编程接口(public API)的每一个部分，而且最好是结合实例。以下是写好的API接口文档的几点建议：简洁：你的API和实例写的越简单，用户就能越轻松地理解它是干什么的以及怎么用。排版清晰：每一个API函数都用同样的模板和可视化排版。通过这种方式，你也在形成自己与用户传递API信息的特定语言风格。用户视角——确保你是从用户视角来写API描述的。假装你不知道该软件的内在构造而你所有的信息都来自这个文档。及时更新——随着你的项目的迭代，ＡＰＩ可能也跟着有改变。确保你的自述文件反映最新的ＡＰＩ和例子。自述文件可以（但不一定）包含以下几个元素：Link to a contribution guideList of contributorsLink to a change logLatest versionLicenseBuild statusDownloads counterLink to a chat for fast feedback在这个链接里你可以看到一个比较好的自述文件的例子：aws-amplify/amplify-js: A declarative JavaScript library for application development using cloud services. (github.com)善用徽章（badge）使用徽章是一种很好的曝光项目重要信息的视觉呈现方式，项目重要信息包括：构建状态（build），发行版（release）,许可证(license)等等。有不少徽章的选择，但我推荐你使用shields.io徽章，它们的徽章几乎涵盖了所有需求。在自述文件里加入徽章非常简单：打开Shields.io: Quality metadata badges for open source projects；选择相应的类别；点击你想要添加到自述文件里的徽章；填写必要信息（适用的话）；从下拉菜单里选择“Copy Markdown”；把markdown粘贴到你的自述文件里。徽章通常是放在自述文件的最开头，在具体说明之前。以下是一个例子：一定要有测试例子API文档虽然重要，但还是API的实际代码更重要。文档不够，测试来凑。其实很多时候具有说明性的测试比文档能更好地解释你的代码是如何运行的。总结一下，在这一部分里，我们主要是讲了如何写说明和自述文件，但其实还有一些其它的文档。比如说，随着你的项目不断地发展壮大，它的议题（issues）也会不断增多，这些议题会成为文档的有机组成部分。不过，一个涵盖了API接口的自述文件是最基本的。05 如何发布一个开源项目我们已经讨论了如何更好的启动一个项目以及如何写好文档，那么我们现在来聊聊如何吸引用户，和如何更好的吸引和正确地管理贡献者。这一部分内容是基于一个前提，这就是：你已经有一个开源软件了，它已经在GitHub上了，它的文档很完善，用户可以轻松地通过安装包注册表来“消费”这个软件。如何向世界宣传你的项目？我在这里一定要说一句，在你的项目发展的过程中，你自己会很快没有时间处理所有事情的。这个时候，如果你想要你的项目持续性发展壮大的话，你需要更多的人来为这个项目做出贡献。想要更多的人参与到这个项目中，你就需要更多的人知道这个项目的存在，并且对这个项目有信念。从我的经验来看，让更多相关受众知道你的项目的办法就是使用大平台发布消息，或者是发表关于项目的博文。平台可以是开发相关的（比如dev.to）也可以是无关的（比如Medium.com）.这些平台共通的优点就是，它们都拥有固定的受众群体，而且这些受众是你的项目的相关受众。如果你使用Medium.com的话，我强烈建议你把你的博文提交到一些大的发布者（publications）那里。虽然你需要多花一点功夫让你的文章符合相应发布者的要求，但这样能确保你的通稿能被推送到更广且相关的受众那里，比起广度，受众的相关程度更重要。你也可以考虑把博文投放到付费的半开放媒体（你还可以从中获利）：使用付费媒体的情况还包括（热门）话题投放– 这是一种强大的把文章推送到媒体首页、我们门户网站或手机应用里的每日摘要的做法。我说不上哪种方式更好，但我个人偏好通过发布者发博文，因为这种方式能确保博文的曝光，而不只是一个”可以被投放“的模糊名词。如果你的博文被广泛传播就能带来一系列连锁效应，为你的开源项目带来更多的优势。举一个例子，如果你在发布了一篇博文后，你的GitHub项目在一天内收获了不少星然后因此登上GitHub热门搜索页的话，这本身又形成另一种宣传项目的途径。写好一篇博文的几点建议：以你的软件所能解决的问题开篇。你甚至也可以用这个问题当作通稿的标题。通常人们是在寻找一个解决问题的软件，所以在他们决定要不要花时间继续读下去之前他们要能判断这篇文章和他们的问题是否相关。这个链接是我写的一篇文章。你可以看到，我在文章的标题里清晰地指出了我的软件解决的是什么问题。如果你搜索“customizing Angular builder“的话，谷歌搜索的第一条结果就是我的这篇博文。描述你的软件为什么以及是如何解决相关问题的。提供详细的分步骤指南，从安装开始，一直到应用实例。创建一些示例项目，然后在你的博文里提供这些示例项目的链接。比起一篇博文，很多开发者更乐于见到一些应用实例。发布之前，搜集一些反馈意见。先别告诉朋友关于项目的任何信息，看看他们是否能通过读你的博文搞清楚，如果不能，那说明你的文章写得还不够清楚，你需要修改。当你发布了博文之后，记得在社交网络上分享，并扩散给你的亲人，朋友，甚至是陌生人。这可以增加项目的曝光度。除了增加曝光度之外，你还想要吸引贡献者。如何让你的项目对贡献者有吸引力？最好的办法就是和别人一起启动一个开源项目。这样的话，从一开始你就是一个团队，就有人和你分享负担。但并不是每次都能从一个团队开始，如果你一开始是一个人，那你就需要吸引贡献者。以我的经验来看，贡献者一般来自两类人：在寻找一个项目做出贡献，以发挥影响力的人（这类人很少，但还是存在的）。使用了你的软件然后发现了bug或者缺失的功能的用户。对于这两类人来说，仅仅在GitHub上分享你的代码和一篇简单的博文是不够的。你需要多做几件事情，让这些人想要贡献，这几件事情就是：提供待办清单这个清单可以包含一些bug,一些计划中的功能，等等。这个清单会让第#1类贡献者清晰明了的看到他\她可以做的事情然后从中选择合适的来提供拉取请求。这个清单可以是一个单独的文本，或者你可以（或应该）用GitHub上的议题标签。提供贡献者手册基础版的贡献者手册包括仓库结构解释，分步骤的构建、运行和测试的操作说明。进阶版的手册也可以涵盖体系结构（architecture）,设计决策，行为守则等等。Atom的贡献者手册是一个很好的例子。不要低估，这很有价值！这是在你的项目发展壮大的过程中，你会花很多时间来做的一件事。我后悔我没有在一开始就写好这个手册，然后在项目迭代的过程中再逐渐完善这个手册。很遗憾，没有人在我刚开始的时候告诉我贡献者手册的总要性。所以，截至目前，我的项目还没有开发者手册，这一直在我的待办清单里。认可贡献者把贡献者的名字放在开源项目的首页会成为贡献者的动力之一。把贡献者的用户名放在首页还不够，我建议你使用All Contributor（另外一个有用的开源项目）。这个工具不仅能帮你做一个漂亮的区域来展示所有贡献者的头像和徽章，还会通过创建拉取请求的方式自动地把新的贡献者加到这个区域里。总结以下，这一部分，我们讨论了一些关于如何增加项目曝光度和给潜在贡献者提供创建拉取请求和议题的动力的事情。但这些还不足以维系贡献者，或者确保他们从头到尾完成一件他们开始的事务。06 如何管理议题和拉取请求这一部分，我们来聊聊贡献者– 开源项目的圣杯（不可缺少、非常重要的）。什么是对开源项目的贡献？一个对开源项目的贡献是任何除了项目持有者以外的人做出的修改。在实践中，贡献一般有两种形式：议题（issues）GitHub对议题的说法：您可以在仓库中使用议题收集用户反馈，报告软件漏洞，并且组织要完成的任务。议题不只是一个报告软件漏洞的地方。简而言之，议题是一条需要对之采取某种行动的信息。拉取请求（PR）GitHub对拉取请求的说法：拉取请求可让您在GitHub上向他人告知您已经推送到仓库中分支的更改。在拉取请求打开后，您可以与协作者讨论并审查潜在更改，在更改合并到基本分支之前添加跟进提交。简而言之，拉取请求是一则对项目的实际修改。如何处理议题和拉取请求？以我自己为例子我个人能给你最好的建议就是使用一种工作方式。这个方式就是说，当你开始写一个新的特征的时候你应该创建一个拉取请求，然后当它满足你的要求的时候尽快合并它。如果你发现这个拉取请求中有错或者没有涵盖必要的功能，你应该创建一个相应的议题。这样的工作方式不仅把工作整理得井井有条，更给贡献者们提供一个参考，让他们能相应地调整议题和拉取请求。还有，如果你提出很高的标准（比如要求每个拉取请求都要有合适的文档，测试，等），你也应该以相同的标准要求自己。你不能提出一些连你自己不会遵循的标准。有时，你应该对贡献者比对自己宽容些，尤其是在项目初创阶段。这也引出我要说的下一点。感恩所有工作和他人合作完全是建立在相互尊重之上的。你应该尊重贡献者们。耐心地回答问题（哪怕问题很简单），礼貌地提出有建设性的批评。记住：尊重贡献者是很关键的。如果有人创建议题（哪怕没有经过深思熟虑，没有仔细调研，是偶发性不可复制的问题），感谢他们。他们已经多花了功夫，把凳子前移打了一段觉得会对你有用的文字。谢谢他们，如果必要，再礼貌地问问其它细节。如果有人创建了一个拉取请求，但达不到你设定的高标准，谢谢他们。礼貌地提出修改意见，给他们提供一个你自己的拉取请求以及贡献者手册的链接作为参考。有建设性和正面的对话会成为贡献者创建贡献的额外动力。质量还是数量事情总有个取舍（除非你拥有的是一个像Angular和React那样的大型开源项目）。（这里有两个极端：）如果你决定不放宽标准，哪怕一点点也不放宽，那么你很可能最终得自己来实现所有工作。或者，如果你决定为贡献者降低标准，那么你指定标准这个事就变成徒劳的了，因为标准没能被遵从。我学到每个贡献者都需要不同的方式，这取决于每个人的特点以及他们对贡献的兴趣。你应当考虑议题的紧急性，贡献者的经验，你的代码的复杂性，需要修复或添加的功能的复杂度还有贡献者的动机，等等这些因素。通常来说，如果是相对紧急的议题，我会礼貌地请求修改，如果等上几天没有动静，我就自己做。对于相对不太重要（锦上添花）的修复或新特征，我通常就会完全把它们留给开源社区。慢慢地，议题和拉取请求的数量就会变得越来越多，对那么多的议题和拉取请求进行跟踪，排优先顺序，分门别类就会变成一件心有余而力不足的事情。这就意味着标签将起到举足轻重的作用。善用标签GitHub标签是整理议题和拉取请求的利器。它不仅可以让你根据标签来搜索和筛选，我发现最有用的是它可以把一个项目的进度状态图像化地呈现出来。当你进入“议题”页面，如果看到大部分的议题都被帖上了bug标签的话，就意味着你不能再不停地推新功能了，而是应该停下来专注把这些bug修好。相对应的另一种情况就是，大部分的议题被贴上了enhancement（改进）或者required feature（需要新功能）的标签。Priority是另一类有用的标签，它可以告诉管理者和贡献者该优先专注在什么议题上。除此之外，标签也能帮助到贡献者。比如，当潜在贡献者进入到“议题”页面，他们可以通过help-wanted和pr-welcome这样的标签明了的看出哪些议题需要社区的帮助。除了使用单一责任的标签（比如bug和enhancement），我还建议你使用描述范围和程度的标签，比如：priority: low, priority: highrequired: investigation, required: tests, required: docspackages: package1 , packages: package2 etc.以下用我的一个项目中的议题页截图作为例子：标签让你和贡献者一眼就能清晰地看出哪些议题需要你的关注，这些议题跟哪些部件相关，以及需要采取什么行动。使用议题和拉取请求的模板我强烈建议你多花几分钟来定义issues和PR模板。你能通过模板定义和规范贡献者在仓库里创建议题和拉取请求时应该包含的信息。模板会为你节省很多时间，因为你之后就不会需要通过回复议题和拉取请求去询问额外的信息或修改。虽然这偶尔也会发生，因为有的贡献者会没注意到模板的存在，但相比起没有模板，这种事情的概率会大大降低。下面是一个议题模板的典型例子：使用GitHub应用和GitHub Actions有很多不少GitHub应用和actions可以帮你管理issues和PR，以下这个列表是我个人觉得有用的：Stale botWIPAutoapprovalPR labeler及时回复如果我创建了一个议题或拉取请求，然后对方花了“无穷无尽“的时间来回复我，那么我就会换一个项目。这是我遇到的一个例子：刚开始的回复比较快，用了两天；讨论也算有成效；但这个PR现在还没关闭，PR里指出的错误和缺失没有任何更新。就这样，我换到了另外一个软件。角色转换，情况也是一样的，如果你两个多星期才回复用户创建的PR，那么你就会失去这些用户了（用户是潜在的贡献者）。所以，一定要及时回复– 帮助别人就是帮助你自己。你不用立即提供解决方案，哪怕是回复别人你收到了，你预计下星期研究这个问题，你也给了对方一些确定的信号和时间线。坏消息就是，你要信守承诺。但如果你时不时地无法做到每次都按你自己承诺的来做，也不要担心，我们都有自己的生活，大家也都理解也许你遇到了紧急的事情而需要推后开源项目的工作。如果这样的事情发生了，给个简短的更新，这样用户们就知道他们在等待的功能被推迟了。如何给议题排优先顺序？这里我给你提供几个能帮你排优先顺序的方法。首先，怎么确定哪个议题最重要呢？最重要的议题就是用户们最想要的，无论这是一个新功能，一个bug修护还是别的要求。有的时候用户们会在提issues的时候就表达他们的关切程度，但大部分时候他们是不会的。这种情况下，我教你一个可以知道用户们对那些议题感兴趣的途径：每一个项目都会有一个“Insights”按键，其之下有一个“traffic”区域。打开traffic你就可以看到哪些页面是用户访问最多的。见下图：被访问最多的议题很可能就是用户需求最大的。在知道了需求最大的议题之后，你就需要强调这个议题，这通常有两种方法：置顶议题:在每个仓库中，你可以置顶最多三个议题，被置顶的议题会出现在议题页面的最顶端，很显眼，很难被错过，如下图：添加标签：我在前页讲过善用标签的话题了，这就是一个最合适使用help-wanted和priority: high的时候了，这样的标签可以让贡献者们看到这个议题很重要而且很欢迎社区的帮助。总而言之，保持你的项目条理工整是很重要的。。条理工整不仅使得管理更加高效，更会提升整个项目给人的印象。议题和拉取请求也是你开源项目不可分割的一部分，不要低估它们的价值。07 如何实现软件开发自动化一个自然地管理贡献（也就是议题和拉取请求）的方法是自动化管理，这也是OSS（开源软件）管理的一个重要方面。为何选择自动化管理？如果说我从我这么多年的开源软件管理经历中学到了什么经验的话，那就是：你每天在日常工作中花的时间越少，你就有更多的时间能去花在真正的工作中，比如修bug,开发新功能，等等。所以，我就会尽可能地是开发过程自动化。我将会这样来展开我的叙述：我们先来看看非自动化和自动化两种工作流程的区别，从中我们来看看日常工作会花费多少时间，然后我们就来讨论该如何优化我们的工作流程以腾出更多的时间来修bug.最坏情况：完全没有自动化你可以看到，在没有自动化的情况下，你一个人要做全部的事情，光修一个bug你就需要做很多的工作，并且，每修一个bug你都要做一遍这个流程里的所有工作。再让我们看看另一种情况。最好情况：完全自动化在这种情况里，你只需要做你必须做的部分，检查代码，以及（时不时地）同意拉取请求，其它部分都是自动化的。这听起来像科幻小说吧？不是的，这个过程叫做持续集成（continuous integration, CI）和持续部署(continuous deployment, CD)。我就不再这里深入展开关于写脚本和与系统相关的配置问题了，我给大家介绍一下实现CI和CD所需的相关工具，细节就由你自己决定了。什么是持续集成（CI）？持续集成(CI)是一种需要频繁提交代码到共享仓库的软件实践。频繁提交代码能较早检测到错误，减少在查找错误来源时开发者需要调试的代码量。频繁的代码更新也更便于从软件开发团队的不同成员合并更改。这对开发者非常有益，他们可以将更多时间用于编写代码，而减少在调试错误或解决合并冲突上所花的时间。（GitHub中文文档）一个非常基本的CI运行将包括构建和单元测试，但它不仅限于这两个。它还可能包括各种静态代码分析工具、linter等。这是你可以定义标准的地方。为何选择端到端测试（E2E）？构建和单元测试能给你提供的代码更改提供快速的反馈，花费的时间相对较短，但在出现问题也很快就会出现失败。但是端到端(E2E)测试在CI中占有特殊的地位。E2E测试不仅应涵盖代码的正确性，还应涵盖部署流程、包的完整性等。我是在不小心发布了一个不包含任何代码的包的新版本时，才意识到这一点的。我发布那个不包含任何代码的包的时候，竟然构建通过了，单元测试和E2E测试都是绿色的（构建，单元测试和E2E测试是在一次从测试项目里连接构建输出目录时安装的）。哪里失败了？是在打包阶段。为了实现这一点，我有如下建议：在CI运行期间，启动一个本地包注册表。每种语言/生态系统都有一些选项，例如对于Java或Scala项目，有Nexus仓库，对于JavaScript，有Verdaccio（这是我在@angular-builders项目中使用的）令开启一个项目来使用你的包（这个项目可以在同一个仓库中）。这个项目中的测试应该测试你的包的功能。将此项目配置为使用本地包注册表。构建包后，将其发布到本地包注册表（在CI系统中启动）。在你的测试项目中安装最新版本的软件包（你在上一步中刚刚发布的）运行测试。以上这些步骤不仅能测试包完整性和可靠性，而且还会在持续部署方面为你节省一些工作。持续集成系统是如何工作的？有很多为开源项而设计的CI系统免费计划，其中包括Travis CI、CircleCI、AppVeyor、Github Actions等。这些，这些计划基本上的功能都差不多，它们在虚拟机上检测你的代码，运行您定义的脚本（通常运行构建和测试），然后向GitHub报告成功或失败。所有这些系统都在GitHub上用于CI的应用程序，并且所有这些系统的集成流程都非常相似：在平台上注册。在您的GitHub帐户中安装相应的应用程序。配置对选定仓库的访问权限。创建定义构建矩阵、所需构建链和CI脚本的配置文件（如travis.yaml）。推送给master这将使您的CI在每个PR上运行并向GitHub报告状态——但这还不够。您真正想要的是在一个PR通过所有检查之前不让它被合并到主分支。这是通过定义分支保护规则来完成的。为了定义这些，您应该转到仓库“Setting”中的“Branches”部分，然后按“Add rule”按钮：然后选中“Require status checks to pass before merging” 复选框。如你所见，相应的Github Apps复选框已经出现在这里，所以剩下的唯一事情就是启用它们。确切的构建脚本实际上取决于您的生态系统、您的项目所用的语言、您使用的框架等等。因此，我们不会在这里介绍它——你需要自己查看CI系统的文档才能了解细节。不过，你先现在对CI是什么以及它如何自动执行PR应该有了很好的了解，所以让我们继续下一部分的内容。什么是持续部署（CD）？持续部署(CD)是一个软件发布过程，它使用自动化测试来验证对代码库的更改是否正确且稳定，以便在一个生产环境中快速、自主地部署。在我们的例子中，生产环境是一个包在注册表中公开可用的环境。这是一个不可逆的状态，因为一旦你发布了一个包，你就无法撤回了，因为它已经公开了（也就是很可能已经被用户使用了）。持续部署有多种策略，这实际上取决于项目及其复杂性。但在我看来，发布应该只从主分支发布，因为这样能简化工作流程。只从主分支发布的CD策略步骤如下：每个PR代表一个错误修复或一个新功能。代码在到达主分支之前已经经过测试（包括E2E）。主分支是一个受保护的分支，只要你不合并失败的PR，主分支就会保持稳定。每个PR合并到主分支的事件都会触发master CI运行，最终发布一个新版本。这将确保所有发行版本的连续性，并且可以很容易地将某些PR与特定版本相关联。我们需要做以下一些事情来自动化软件包的发布：基于提交消息（commit message）的自动版本升级。基于提交消息（commit message）的自动CHANGELOG更新。自动将包发布到公共包仓库。在Github上自动发布。好消息是：所有这些都有语义发布（semantic-release）的支持了。坏消息是：你必须投入一些时间才能让它正常运作（但这是值得的）。语义发布（semantic-release）是如何工作的？语义发布使整个包发布的工作流程自动化，包括：确定下一个版本号、生成发行说明以及发布安装包。这消除了人的主观情绪和版本号之间的直接联系，严格遵循语义版本控制规范。关于集成，有很好的文档，我们就不在这里赘述了。不过我要提几点：在开始使用Semantic Release之前，确保你已经了解语义版本控制规范和常规的提交格式。为了使语义发布良好运行，你应该强制执行某些提交消息的格式。为此，你可以将commitlint作为husky precommit hook运行。当有人创建本地提交时，它会强制执行常规提交，但它不能对直接从GitHub Web UI执行的提交做任何事情（当人们想要快速修复他们的PR时经常这么做）。因此我建议你使用commitlint Github Action做备份。在您将语义发布设置为工作流程的一部分后，你就接近大功告成了，你不再需要将时间花在这些常规流程上，不过，你还可以额外进行一项优化。如何使项目保持最新？如果你的项目没有外部依赖——你就可以跳过这一部分了。但是，大多数项目通常依赖于其他包，而其他包往往会发生变化。使您的项目与其依赖项保持同步很重要，但也很耗时。对我们来说幸运的是，有不少帮助我们解决这个问题的工具，例如Greenkeeper、Renovate和Dependabot。它们的工作原理几乎相同，所以我将引用Dependabot的“它是如何工作的”部分作为说明：Dependabot查找有没有任何更新Dependabot会提取您的依赖文件并查找任何过时或不安全的需求。Dependabot开启拉取请求如果您的任何依赖项已过期，Dependabot会创建一个单独的拉取请求以更新每个依赖项。交由你审核并合并你检查测试否通过，阅读包含的变更日志和发行说明，然后信心满满地点击合并。以上内容，正如您可能已经知道的那样，只有当您拥有一个正常运行的CI系统时才有意义。总结一下，如果你有一个完全自动化的CI/CD周期，如果现在你的开源项目仓库中出现了一个新问题，您可以在几分钟内提供错误修复。事实上，你可以用你的手机GitHub应用，修复一两条错误的代码，然后提交代码。其余的都是自动完成的，你的用户会立即获得一个新版本。我已经多次这样，快速而轻松地为我的客户提修订过的新版本。使用自动化并不是要腾出一些休闲时间，而是要将您的时间用于真正重要的事情并提高您的响应能力。08 版本管理在这个指南的最后，我想谈谈版本管理，这是一个对于任何拥有大量用户的开源项目都很相关的话题。你将通过这一部分的内容了解版本符号、破坏性变更、向后移植等。什么是软件版本控制？我们先来看看维基百科对软件版本控制的定义：软件升级版本控制是为计算机软件的某个独特状态分配的相对应的唯一版本名称或唯一版本号的过程。我们通常使用两种不同的软件版本控制方案来追踪现代的计算机软件的版本变更：可能在一天内多次递增的内部版本号，例如修订控制号通常更改频率要低得多的发布版本，例如语义版本控制[1]或项目代号。事实上，有多种方法可以给你的软件产品版本一个唯一的标识。最广为人知的方法是给它一个名字。地球上的绝大多数人，即使是那些间接接触到技术的人，可能都听说过Android Ice Cream Sandwich和Marshmallow或Mac OS Leopard、its frozen cousin Snow Leopard和Big Sur。译者李霄2012年拍摄于加州Mountain View谷歌总部程序员可能听说过Eclipse及其天体Luna、Mars和Photon。这些都是软件产品的主要版本的名字。给软件版本取名字固然对市场营销有好处，但名字有时候也会制造困惑。事实上，谷歌已经放弃使用candies这个安卓版本的名字，因为多年来从用户那里听到的反馈是，并不是全球社区中的每个人都能直观地理解这些名称。理所当然，我们还没有进化到足以从动物物种推断版本号，即使雪豹比豹酷得多。天体和糖果是更容易掌握的概念，但前提是你按字母顺序命名它们（如Android和Eclipse这个例子）。但有一件事是肯定的——没有比数字能更好确定演替顺序的方式。因此，如果你将软件产品的第一个版本命名为“产品1”，将第二个版本命名为“产品2”，那么第二个版本是最新的版本这件事就非常直观了，不是吗？但是，与不涉及API的独立软件产品不同，其他软件（如大多数开源软件产品使用的软件需要更好的版本控制，而不仅仅是数字序列。例如，如果我们仅使用简单的数字序列进行版本控制，那么用户怎么能区分bug修复和破坏现有API的更改呢？答案是:语义版本控制。什么是语义版本控制？语义版本（也称为SemVer）是一种广泛采用的版本方案，它使用以下格式的3个数字序列来表示一个版本：MAJOR.MINOR.PATCH。规则很简单——以版本号MAJOR.MINOR.PATCH为例：Major：进行不兼容的API更改时的版本Minor：以向后兼容的方式添加功能时的版本PATC：以向后兼容的方式进行错误修复时的版本预发布和构建元数据的附加标签可以加在MAJOR.MINOR.PATCH格式的后缀扩展里。语义版本控制提供了一种把软件产品的更改用清晰简洁的方式来传达给用户的方法。但更重要的是，语义版本控制被各种允许用户依赖特定范围的版本而不是特定版本的包管理器和构建工具（如NPM和Maven）广泛采用。例如，指定版本范围^2.2.1而不是明确地规定版本2.2.1将让用户接受任何向后兼容的错误修复或在版本2.2.1之上发布的新功能。这就相当于，构建工具和包管理器听从于用户和包所有者之间的合同——一种由SemVer定义的合同。这意味着这一切都是你的责任——你要定义什么是重大变化以及什么是微小变化。如果你不小心将破坏性更改作为错误修复（补丁版本）发布，它将会破坏依赖于版本范围的构建。破坏性构建是一件可怕的事情，因此我建议您使用带有预定义消息格式的语义发布以及强制规定提交格式的工具。你可以参考语义版本控制官网[1]获取更多信息。我们已经谈到什么是破坏性变更了，现在我们来谈谈如何引入它们。什么是破坏性变更（breaking changes）？破坏性更改是对公共API的更改，这种更改以不兼容的方式删除、重命名或更改您与用户的合同。理想情况下，你应当在代码中保持向后兼容性，并且永远不引入任何破坏性更改。然而现实是残酷的。软件和代码都在不断地迭代，用户的需求会发生变化，API也会发生变化。你作为一名开发人员在不断成长，你的软件作为一件产品也是同样在成长。因此，特别是作为一个没有报酬的开源开发人员，你不可能自己一个人一直维护着项目中的所有祖传代码。而且有时，你需要摆脱它们。问题是怎么做？与往常一样，你需要权衡利弊。权衡利弊之后，你会更好地了解此更改或其他更改如何影响用户。你不必不惜一切代价保持向后兼容，也不必在每个旧版本中实现所有新功能。但这当然是您应该考虑的事情。如果用户的迁移成本相对较低，那么进行重大更改是可以的，并且在旧版本中不支持此功能也很合理。但是，如果迁移成本很高并且绝大多数用户负担不起这项工作，您可能应该首先考虑使此更改向后兼容并发布弃用警告。弃用警告通常与新API一起发布，而旧API仍受支持。这样用户就有时间迁移。一旦他们迁移了，在下一个主要版本中，就可以安全地删除弃用警告和旧API了。每次引入破坏性更改，你都应该确保你提供一份迁移指南，其中包含迁移的分步说明。此外，出于礼貌，你最好让用户有时间为重大更改做准备，特别是在你不提供宽限期（新旧API都支持的期限）的情况下。提前一点的解释破坏性变更，其背后的原因以及预期时间表的提示信息对于用户来说是非常有帮助的。它可以是一个推文，一个博文或者是在一个微小变更的新版本里给出的弃用警告。一定要记住，重大变化是一种负面体验，而突然的重大变化是一种极其负面的体验。自动迁移我们可以把破坏性变更分为两种类型：非确定性的和确定性的。非确定性重大变更是指你无法预测迁移工作的结果的变更，例如当你完全删除API的某个部分时。在这种情况下，是用户来自行决定是用其它第三方库替换它，自己实现它，还是完全忽略这个版本。确定性更改是在给定代码X和用户输入I的情况下，允许你将其转换为代码Y的更改。例如，更改函数名称或导入语句。在这种情况下，你可以编写一个自动化程序来更改用户的代码库并将其调整为新的API。有了这种自动化，你就不必关心向后兼容性和详细的迁移指南。这是一种让用户以零努力升级其代码的方法，这在软件更新中至关重要。然而，这里你也需要权衡一个固有的利弊。编写代码需要时间，编写迁移指南也需要时间。自然而然地，写将复杂代码流迁移到新API的代码比写用新函数名替换老函数名的代码花费更多时间。有时候，你就是负担不起这种付出。如果你还是决定去做，有一些工具可以帮助你。最广为人知且与语言无关的是Facebook的Codemode:Codemode是一个工具/库，可帮助你进行大规模代码库重构，这些重构可以部分自动化，但仍需要人工监督和偶尔干预。还有更复杂的工具使用AST，可用于执行比find and replace更复杂的任务.例如，另一个名为JSCodeShift的Facebook库（特定于JS/TS）。又例如，代码迁移——一个工具（同样是JS/TS特定的），它允许你相对容易地编写引导迁移，并为用户提供很好的基于CLI的提示。一些大型开源软件项目甚至有自己的解决方案。比如Angular schematic，一种支持复杂逻辑的基于模板的代码生成器。自动代码迁移可以作为单独的包（如my-cool-oss-migrate-v4-v5）发布，并在迁移指南中的一个步骤进行相关描述。或者，迁移可以是包含重大更改的主要版本的一部分，并在用户代码库中安装此版本时执行。以上都是你可以选择的方式。向后推送（back-porting）另一种常见的做法是将重要更改向后推送到以前的版本。例如，在主要版本（具有重大更改）发行之后发现了一个严重错误，而这个错误也适用于以前的版本。在这种情况下，您不能期望用户因为一个错误而执行繁琐的迁移。另一方面，检查旧版本，在其上实施修复，并将其作为旧版本的小问题发布可能很麻烦。解决方案是：每个主要版本都有一个受保护的分支。每次你计划发布一个主要版本时，你都应该从主分支创建一个名为c.x.x的分支，其中c是当前的主要版本号。然后你把所有此类分支都设置为受保护的（就像主分支一样），这样你就不会意外破坏它们。然后，无论何时你必须从较新的主要版本向后移植功能或错误修复，你要么在此分支上重新实现它（如果可能的话），要么就从主分支中挑选提交。此外，值得一提的策略是给下一个新的主要版本也预留一个单独的分支（这个分支的作用和上面提到的为老版本预留分支的作用是相反的）。这种做法通常与在每个新的主要版本中都有很多变化的大型项目（如Webpack或Babel）相关。为即将发行的主要版本创建一个单独的分支，这种做法不仅允许开发者对其进行处理并将其发布以进行测试，同时仍然在主分支中保留最相关的版本（并对其进行处理）。当新的主要版本发布了以后，我们就应把这个单独的分支变成主分支，并为下一个主要版本创建一个新分支。结语我希望你喜欢这个指南，并且读完以后对拥有开源项目的意义有了比较好的理解。最后，我想与你分享一个点，你在运营一个开源项目时应该始终牢记这一点。这就是：兼听则明（“听”是指倾听软件用户的反馈）。这听起来可能有悖直觉，但事实就是如此——你不是唯一定义路线图的人，用户也可以定义它。事实上，用户定义了大部分。你运营一个开源项目的目的是帮助别人，而不是你自己。你要提供多个反馈渠道。有些用户只有一个小问题，您可以在一秒钟内提供答案。有一些潜在的贡献者想要讨论路线图，但不想公开进行，这种情况你要给他们留一种联系方式。比如Slack或Discord的链接，分享你的Twitter帐户，等等。渠道越多越好。（中文世界就是微信，B站，微博啦。）参考资料【1】Semantic Versioning 2.0.0
Semantic Versioning (semver.org)文章来源：深度势能转载本网文章请注明出处