ByteFisher

- Github使用之git回退到某个历史版本:

1. 查找历史版本

1
2
> 使用git log命令查看所有的历史版本，获取你git的某个历史版本的id,假设查到历史版本的id
> 是:fae6966548e3ae76cfa7f38a461c438cf75ba965

2. 恢复到历史版本

1
> $ git reset --hard fae6966548e3ae76cfa7f38a461c438cf75ba965

3. 把修改推到远程服务器

1
> $ git push -f -u origin master

- git如何避免”warning: LF will be replaced by CRLF“提示？

在Windows下使用Git进行修改提交时，控制台显示了如下输出内容：1warning: in the working copy of ‘styles/global.css’, CRLF will be replaced by LF the next time Git touches it这是因为目前的Git仓库由于跨操作系统操作而引发了部分文件的换行符转换问题。具体来说，Linux、macOS、Windows操作系统对于文本文件的换行符有不同的标准，因此一个文件如果与上次操作的系统环境不同，Git自然会在文件对比时识别到标识符被修改，从而引发提示。LF和CR字符在不同的操作系统中被用作操作符，其中LF（0x0A, \n）的初始定义是将光标从当前位置下移一行，不涉及移动到该行行首位置的动作，而CR（0x0D, \r）的原始含义则是将光标前移到当前行的行首，不涉及下移的动作。Linux系操作系统（含macOS，虽然它在OSX时期曾经使用过CR）使用LF直接表示光标换行+移到行首；Windows组合使用了CRLF（0x0D 0x0A, \r\n），无疑是符合标准语义的做法。尽管这不是一个Bug或错误，但还是可以通过如下方式对Git进行配置，以避免在每次提交代码时显示：

Linux/macOS系统下在提交代码时自动将CRLF转换为LF

1
> $ git config --global core.autocrlf input

Windows系统下在提交代码时自动将LF转换为CRLF

1
> git config --global core.autocrlf true

5步调漂方法：不会调漂别着急，一步步来，肯定错不了！

调漂看似简单，其实道道很多，很多新手钓友都有被调漂折磨的经历。看别人都开钓了，这边还没调好漂，心里着急得不得了。尤其是在夏季野钓，上鱼时间比较短，所以更需要在调漂上减少时间，这样就增加了上鱼时间，说不定就能多钓两条鱼。调漂方法比较多，但是本质没多大区别，精通了一种，其他的方法也就触类旁通了。所以以空钩调漂为例，图解下调漂步骤，希望能帮助到各位钓友。

- 先找底

在铅皮座上裹上足够重的铅皮，保证钓组入水以后铅坠是躺底的状态，而且要求浮漂露出的目数不能过高，这样才保证水线是垂直而且被拉直的状态，对水深的测量也是比较精准的，大致状态如下图。达到这种状态以后可以先不着急调漂，此时可以把钓组和浮漂在水中泡一泡，这是因为钓组和浮漂往往都会吃水，会影响钓组重量的变化，泡上一会再调漂，会更精准一些。可以先开饵做好准备工作。

- 调调目

下一步就是下拉浮漂座了，确定个半水深度来调漂。浮漂座通常是前后各两颗太空豆夹住的，可以把最上面的一颗固定在刚才找底的位置上，这样在后面精确找底的时候会快速很多。浮漂座下拉大概 2 倍子线长度，在这个深度调漂是比较准确的，尤其是在钓深水的时候这点一定要注意。我们以调四钓二为例，空钩半水修剪铅皮到浮漂露出水面 4 目。修剪铅皮是个耐心活，当浮漂开始慢慢沉入水中，铅皮就需要一丝丝的剪了。

钓鱼：遇到螃蟹闹窝怎么办！

小鱼闹窝、小虾闹窝及螃蟹闹窝，但凡遇到其中一个，无疑令钓鱼人烦躁不堪，钩饵入水难以就位着底，中途截口时有发生；浮漂上下浮动，如同跳芭蕾舞，动作剧烈却提竿不中鱼。回到钓友的问题，钓鱼时遇到螃蟹闹窝，如何应对，以最大程度获得较好鱼口。本文以此为起点，一窥究竟。

**应对螃蟹闹窝，采取的应对措施有哪些：**

螃蟹属于甲壳类动物，拥有一双锋利且坚硬的夹钳，所以主线、子线它能轻而易举地切断。绝大多数的螃蟹偏杂食性，同鲫鱼、鲤鱼类似，像植物碎屑、藻类维生素都能摄食，但更偏好些腥味的肉食。另外不同于鱼类，能够在各水层自由游动，螃蟹多栖息在水底，像碎石堆缝隙、水草丛、石穴等常有它活跃的身影。熟悉螃蟹的这些习性，可有针对性采取应对措施。

A*寻路算法是一种常用的路径规划算法，用于在图或者网格中找到最短路径。它基于启发式搜索，综合了Dijkstra算法和贪心算法的优点，通过估算当前节点到目标节点的代价，选择最合适的节点进行探索。

具体原理如下：

1. 创建一个起点节点和一个目标节点。从起点开始探索，并将起点加入开放列表。

2. 对于当前节点，计算该节点到目标节点的估算成本（一般使用曼哈顿距离或欧几里得距离），并将其加入已探索列表。

3. 探索当前节点相邻的节点，对于每个相邻节点，计算从起点到该节点的实际成本（一般指每个节点的移动代价，也可以考虑更复杂的因素如地形、距离等），将该节点加入开放列表。

4. 对于开放列表中的节点，按照实际成本和估算成本的总和排序，选择代价最小的节点作为下一个探索的节点，并将其从开放列表中移除。

5. 重复步骤3和4，直到目标节点被加入已探索列表或开放列表为空。

6. 如果目标节点被加入已探索列表中，则路径已经找到，从目标节点出发回溯到起点即可；否则，路径不存在。

A寻路算法通过估算代价，减少了搜索的空间，大大提高了搜索效率，同时保证了找到的路径是最短的。因此在实际应用中，A寻路算法广泛应用于游戏、机器人等领域。

协程和线程是两种常见的并发编程的实现方式。它们有一些相同点和不同点，同时在实际开发中也有各自不同的用途。

相同点：

1. 协程和线程都是实现并发编程的方式，可以在程序中同时执行多个任务，提高程序的效率。
2. 协程和线程都可以让程序在等待 IO 操作时不会被阻塞，从而充分利用 CPU 资源。

不同点：

1. 协程是一种更轻量级的并发实现方式，其运行在单个线程上，协程之间的切换是由程序控制的，因此不需要操作系统的线程切换开销，性能更高。而线程的切换需要操作系统介入，开销比较大。
2. 协程之间的通信是可以通过共享内存等方式直接完成的，而线程通常需要使用锁、管道等同步机制来完成数据共享和通信。
3. 协程需要开发者手动管理协程的调度和状态，而线程的调度和状态管理由操作系统完成。
4. 协程的优点在于适用于 IO 密集型应用，而线程适用于 CPU 密集型应用。在 IO 密集型应用中，协程能够更好地利用 CPU 资源，提高程序效率。在 CPU 密集型应用中，线程能够将任务分配到不同的 CPU 核心上并行执行，提高程序效率。

用途：

1. 协程适用于需要处理大量 IO 操作的应用程序，例如网络通信、数据库、文件读写等场景。在这些场景中，程序需要等待 IO 操作的完成，协程能够使等待过程中的 CPU 时间得到充分利用，提高程序效率。
2. 线程适用于需要处理 CPU 密集型计算任务的应用程序，例如图像处理、视频编解码、数值计算等场景。在这些场景中，程序需要充分利用 CPU 资源进行并行计算，线程能够实现任务的并发执行，提高程序效率。

总的来说，协程和线程在实现并发编程时各有优缺点，在实际开发中需要根据具体应用选择合适的实现方式。