此时 RxJava 没有改变线程，是因为 subscribeOn() 方法已经完成了工作，订阅已经在其他线程上进行了。这时，没有理由 RxJava 会再次更改线程。所以，会看到上述的运行结果。 二....当我们的 subject 发射第一个值时，第一个观察者已经被订阅。由于订阅代码在我们调用 onNext() 时已经完成，因此订阅调度程序没有任何作用。...在这种情况下，当我们调用 onNext() 它类似于 PublishSubject 的工作方式。 第二和第三个观察者都在初始 onNext() 之后订阅。...所有后续的发射的值都发生在订阅之后，因此，值再次与 onNext() 在同一线程上发出，类似于 PublishSubject 的工作方式。...本文介绍了几种方式，RxJava 即使调用了 subscribeOn() 方法，线程切换也不会起作用。任何细微使用线程切换的地方，都需要非常注意。
某个crontab的定时任务没有按照我们预期的执行，我们要做的故障排查步骤如下：查看日志：首先，查看crontab执行的相关日志，可以使用命令 grep CRON /var/log/syslog 来查看...cron的日志记录。...如果没有找到相关日志，可以尝试查看 /var/log/cron 或 /var/log/messages。检查crontab文件：检查crontab文件的路径和内容是否正确。...cron任务的执行时间依赖于系统时间，因此如果服务器时间错误，可能会导致cron任务未按预期执行。检查其他系统资源：确认系统资源是否足够。...如果服务器的CPU、内存或磁盘空间资源不足，可能会导致cron任务未能正常执行。日志调试：在crontab中增加输出日志，以便更详细地了解任务的执行情况。
前言 一直在使用git做版本控制，也一直工作很顺利，直到和别人发生冲突的时候。这才注意到git 工作流并不是那么简单。比如，之前遇到的清理历史。...学习git工作流 1....但我们应该知道使用revert而不是reset. 但revert只能回滚指定的commit，或者连续的commit，而且revert不能revert merge操作。...2.10 新的merge方式： rebase 通过开始的普通流程发现，每次merge的时候，都会多出一条新的提交信息，这让历史看起来很奇怪。...按照前几次的做法，E和F交叉在本地提交，每次commit的时间戳也是交叉，最终合并到master的时候，历史并没有被拆散。而是像我们期待的一样，顺序下来。这才是我们想要的。
本文首发于政采云前端团队博客：我在工作中是如何使用 Git 的 https://www.zoo.team/article/how-to-use-git image.png 前言 最近在网上有个真实发生的案例比较火...莫慌，按照下面我讲的四个步骤走，保证你可以顺利使用 Git 进行拉取代码！ 下载 Git 下载地址 (https://git-scm.com/downloads) ，选择自己系统对应的版本下载即可。...，Revert 开头，后面跟撤回的 commit-msg 信息之前的 commit 记录并没有消失，此时也达到了代码回退的效果 ?...回滚我们的提交有二种方式，一种是上文提到的git revert命令外，还可以使用 git reset 命令，那么它们两者有什么区别呢？...目前我们的工作区是很干净的，没有任何修改的操作，此时，修改一下代码再次查看状态，可以看到，1.js 这个文件被修改了。 ?
千万不要说：“没有人比我更懂我的度量值命名方式……” ? 其实呢，这种数据集一般还都工作得很好，通常也是由专业的 BI 开发人员构建的，但这些命名方式，简直是今后维护中的噩梦。...从最开始学习并使用PowerBI，我就受困于这个问题，其实一直到现在我都并没有真正实践最优的命名方式，几年之前使用数据库时面对的问题，如今在powerbi中仍然遇到。...所以我个人的建议是在搭建模型的最初就想好命名方式，并将其作为一个贯穿始终的重要工作。...我觉得可以从以下这几个方面出发： 按照人类正常逻辑能够读懂的词语，而不是任何类型的技术命名或者自创的简写命名，尽量写全单词，单词之间用空格。...如果你的命名方式并不规范，那么你在视觉对象中使用这些列和度量值时必须重命名列和度量值，你一定懂我在说什么，想想浪费了多少时间吧。 说的差不多了。
Git Commit 规范可能并没有那么夸张，但如果你在版本回退的时候看到一大段糟心的 Commit，恐怕会懊恼不已吧。所以，严格遵守规范，利人利己。...git reflog—— 显示本地代码库 HEAD 的更改日志。这个命令很适合查找丢失的工作。 用 Git 进行检查并不麻烦。相比之下，Git 中有不少删除和撤销提交以及文件改动的操作。...git reset 和 git checkout 既可用于提交也可用于单个文件的修改，而 git revert 只能用在提交层面。...如果你只需要处理尚未合并到协作远程工作的本地提交，你可以使用这三者中任何一条命令。如果是协同工作且需要撤销远程分支中的提交，那么就用 git revert。...git revert my commit—— 撤销 my_commit 中的更改。 当用 revert 撤销改动时，它会产生新的提交。
git revert commit git revert是提交一个新的版本，将需要revert的版本的内容再反向修改回去， 版本会递增，不影响之前提交的内容 `git revert` 和 `git reset...git reset 是把HEAD向后移动了一下，而git revert是HEAD继续前进，只是新的commit的内容和要revert的内容正好相反，能够抵消要被revert的内容。...而按照 Git 的默认策略，如果远程分支和本地分支之间的提交线图有分叉的话（即不是 fast-forwarded），Git 会执行一次 merge 操作，因此产生一次没意义的提交记录，从而造成了像上图那样的混乱...不过，如果你对使用 git 还不是十分熟练的话，我的建议是 git pull --rebase多练习几次之后再使用，因为 rebase 在 git 中，算得上是『危险行为』。...另外，还需注意的是，使用 git pull --rebase比直接 pull 容易导致冲突的产生，如果预期冲突比较多的话，建议还是直接 pull。
基于命令行 1.1 工作区的代码想撤销 可能有一天我正在写代码，写了很久发现写错了，想恢复到一开始的状态，一个笨办法就是把刚刚写的代码一行一行的删除，不过这种方式成本太高，我们可以通过git checkout...git status 命令，此时工作区的状态已经发生变化，然后我们执行了 git checkout -- git01.txt 命令，表示撤销之前的操作，让 git01.txt 恢复到之前的状态，该命令执行成功之后...2.1 未提交就撤销 对于第一小节的前两种撤销操作，即修改的文件还没 commit，此时想要撤销，方式很简单，点击 IDEA 右上角的撤销按钮： 如果你修改了文件，无论有没有执行 git add 命令...我电脑上的 IDEA 在这块操作中有个偶发性问题，就是撤销掉 commit 之后，IDEA 检测不到文件处于未提交状态，需要我把 IDEA 关掉重新打开，IDEA 就能发现文件处于未提交状态了，此时就可以按照...操作方式如下： 找到需要回滚的地方，右键单击，选择 Revert Commit： 此时会弹出来一个提交的对话框，就是一个普普通通的 commit 对话框，如下： commit 之后，可以看到内容已经撤销了
或许只是你的预期不对。本文通过讲解三向合并和 Git 的合并策略，step by step 介绍 Git 是怎么做一个合并的，让大家对 Git 的合并结果有一个准确的预期，并且避免发生合并事故。...他又得重新做了一下 revert，并且迷茫的怀疑是 Git 的 bug。...如下图 很明显答案是不能，如上图的例子，Git 没法确定这一行代码是我修改的，还是对方修改的，或者之前就没有这行代码，是我们俩同时新增的。此时 Git 没办法帮我们做自动合并。...（这句话的理解需要这篇文章的基础知识） 对于合并时候要使用 git merge 还是 git rebase 的争论，我个人的看法是没有银弹，根据团队和项目习惯选择就可以。...这个例子理解原理之后解决方法有很多，这里简单带过两个方法：1. revert 节点 E'之后，此时的 dev 分支要抛弃删除掉，重新从 E'节点拉出分支继续工作，而不是在原 dev 分支上继续开发节点
id 来标识工作区的变更与改动。...实践出真理 为了直接明白的了解其原理，我这里在 github 上创建一个空白的仓库，按照上图创建三次提交： commit b0ef8f9125226af8f06ff1aba7c1f1fc83adea9b...，目前我们是使用 git reset --hard 的方式，其实这里存在着三种方式，TODO 下一篇 git 操作讲一下。.../demo.git + b98f95e...6b166ed master -> master (forced update) github 此时我们可以看到远程也没有了我们之前提交的三次记录而是只有第一次的提交记录...总结 git reset和git revert都是属于重新恢复工作区以及远程提交的方式，但这两种操作有着截然不同的结果： git reset是将之前的提交记录全部抹去，将 HEAD 指向自己重置的提交记录
前言 从接触编程就开始使用 Git 进行代码管理，先是自己玩 Github，又在工作中使用 Gitlab，虽然使用时间挺长，可是也只进行一些常用操作，如推拉代码、提交、合并等，更复杂的操作没有使用过...出来混总是要还的，前些天就遇到了 Git 里一种十分糟心的场景，并为之前没有深入理解 Git 命令付出了一下午时间的代价。...”利益于”我们不太干净的提交记录，要完成从 C 版本到 N 版本的 revert，我需要倒序执行 revert 操作几十次，如果其中顺序错了一次，最终结果可能就是不对的。...遗憾的是，当天我并没有理解到 rebase 的这种思想，又由于试了几个方法都不行太过于慌乱，在 rebase 完成后，向主分支合并被拒之后对这些方式的可行性产生了怀疑，又加上有同事提出听起来更可行的方式...为了让我的五个小时不白费，复盘一下当时的场景，学习并总结一下四种代码回退的方式： revert 适合需要回退的历史提交不多，且无合并冲突的情景。
前言 ---- 从接触编程就开始使用 Git 进行代码管理，先是自己玩 Github，又在工作中使用 Gitlab，虽然使用时间挺长，可是也只进行一些常用操作，如推拉代码、提交、合并等，更复杂的操作没有使用过...出来混总是要还的，前些天就遇到了 Git 里一种十分糟心的场景，并为之前没有深入理解 Git 命令付出了一下午时间的代价。...利益于”我们不太干净的提交记录，要完成从 C 版本到 N 版本的 revert，我需要倒序执行 revert 操作几十次，如果其中顺序错了一次，最终结果可能就是不对的。...遗憾的是，当天我并没有理解到 rebase 的这种思想，又由于试了几个方法都不行太过于慌乱，在 rebase 完成后，向主分支合并被拒之后对这些方式的可行性产生了怀疑，又加上有同事提出听起来更可行的方式...为了让我的五个小时不白费，复盘一下当时的场景，学习并总结一下四种代码回退的方式： revert 适合需要回退的历史提交不多，且无合并冲突的情景。
出来混总是要还的，前些天就遇到了 Git 里一种十分糟心的场景，并为之前没有深入理解 Git 命令付出了一下午时间的代价。...利益于” 我们不太干净的提交记录，要完成从 C 版本到 N 版本的 revert，我需要倒序执行 revert 操作几十次，如果其中顺序错了一次，最终结果可能就是不对的。...遗憾的是，当天我并没有理解到 rebase 的这种思想，又由于试了几个方法都不行太过于慌乱，在 rebase 完成后，向主分支合并被拒之后对这些方式的可行性产生了怀疑，又加上有同事提出听起来更可行的方式...在从文件管理系统内，将 bak 文件夹下 除了 .git 文件夹下的所有内容复制粘贴到原项目目录下。git 会纯从文件级别识别到变更，然后更新工作区。...为了让我的五个小时不白费，复盘一下当时的场景，学习并总结一下四种代码回退的方式： revert 适合需要回退的历史提交不多，且无合并冲突的情景。
我在使用Git时，就处于这种知其然而不知其所以然的状态。现在，再来补补课。...Git并不保存文件前后变化的差异数据，更像是把变化的文件做一个快照，然后记录在一个微型的文件系统中。每次提交更新时，会比较这个快照。若文件没有变化，Git则只对上次保存的快照作一个链接。...然而，这并不足以说明一个文件在不同的工作区域所展现的状态。我认为两种状态足以表达Git中的文件，即：未跟踪（Untracked）和已跟踪（Tracked）。...例如： git commit -m "first commit" 有时候，我们希望取消已暂存的文件。例如说，我在工作目录中增加了两个文件，然后暂存了它们。...由于Git的提交记录是由HEAD指针指向当前分支。重置就是搬动这个指针到指定的snapshot。如果说revert是一种安全的撤销方式，则reset就是一种危险的撤销方式。
git stash | git stash pop 暂存工作内容，然后再切换到 hotfix 第二种方式较第一种还好很多，可是面对下面这些场景，stash 依旧不是很好的解决方案 我们面对的场景 正在...： 用简单的话来解释 git-worktree 的作用就是： 仅需维护一个 repo，又可以同时在多个 branch 上工作，互不影响 上面红色框线命令有很多，我们常用的其实只有下面这四个： git.../JIRAID-Title, hotfix/JIRAID-Title, 如果仅仅按照上面命令新建 worktree，分支名称中的 / 会被当成文件目录来处理 git worktree add .....文件是没有用的，为了保持清洁，我们还需要进一步清理 git worktree prune 这个命令就是清洁的兜底操作，可以让我们的工作始终保持整洁 总结 到这里，你应该理解，整个 git-worktree...只维护一个 repo，创建多个 worktree，操作间行云流水 我的实践：通常使用 git worktree，我会统一目录结构，比如 feature 目录下存放所有 feature 的worktree
使用git作为代码版本管理，早已是现在开发者必备的技能，但是大多数的开发者还是只会最基本的保存，拉去，推送，遇到一些commit管理的问题就束手无策，或者用一些不优雅的方式解决。...下面分享一些在开发工作中实践过的实用命令，这些都能够大大提交工作效率，还能解决不少疑难场景。...revert描述：给定一个或多个现有提交，恢复相关提交引入的更改，并记录一些这些更改的新提交，这就要求你的工作树是干净的（没有来自头部的修改）。将现有的提交还原，恢复提交的内容，并生成一条还原记录。...revert合并提交后，再次合并分支会失效还是上面的场景，在master分支revert合并提交后，然后切到v2.0分支修复好bug，再合并到master分支时，会发现之前被revert的修改内容没有重新合并进来...设置git短命令对于我这种喜欢桥命令行而不用图形化工具的爱好者来说，设置短命令可以很好的提高效率，下面介绍两种设置短命令的方式。
可大多数工程师还是只会最基本的保存、拉取、推送，遇到一些commit管理的问题就束手无策，或者用一些不优雅的方式解决。 本文分享我在开发工作中实践过的实用命令。...该命令将保存本地修改，并恢复工作目录以匹配头部提交。 stash 命令能够将还未 commit 的代码存起来，让你的工作目录变得干净。 应用场景 我猜你心里一定在想：为什么要变干净？...cherry-pick 描述 给定一个或多个现有提交，应用每个提交引入的更改，为每个提交记录一个新的提交。这需要您的工作树清洁（没有从头提交的修改）。...revert 描述 给定一个或多个现有提交，恢复相关提交引入的更改，并记录一些这些更改的新提交。这就要求你的工作树是干净的（没有来自头部的修改）。...设置 Git 短命令 对我这种喜欢敲命令而不用图形化工具的爱好者来说，设置短命令可以很好的提高效率。下面介绍两种设置短命令的方式。
可大多数工程师还是只会最基本的保存、拉取、推送，遇到一些commit管理的问题就束手无策，或者用一些不优雅的方式解决。 本文分享我在开发工作中实践过的实用命令。...stash 命令能够将还未 commit 的代码存起来，让你的工作目录变得干净。 应用场景 我猜你心里一定在想：为什么要变干净？...cherry-pick 描述 给定一个或多个现有提交，应用每个提交引入的更改，为每个提交记录一个新的提交。这需要您的工作树清洁（没有从头提交的修改）。...revert 描述 给定一个或多个现有提交，恢复相关提交引入的更改，并记录一些这些更改的新提交。这就要求你的工作树是干净的（没有来自头部的修改）。...设置 Git 短命令 对我这种喜欢敲命令而不用图形化工具的爱好者来说，设置短命令可以很好的提高效率。下面介绍两种设置短命令的方式。
俗话说，老虎也有打盹的时候。我们提交代码，也会有出错的时候。 我今天不小心把不该提交的文件给提交了。...为了搞清楚原理，我画流程图，找到了一个好的工具：https://www.draw.io/ git的工作流 工作区：即自己当前分支所修改的代码，git add xx 之前的！...revert # 撤销指定的版本，撤销也会作为一次提交进行保存 3） git revert 和 git reset的区别 git revert 用一次新的commit来回滚之前的...： 场景一： 糟了，我刚把不想要的代码，commit到本地仓库中了，但是还没有做push操作！...情况二：删除最后一次远程提交 方式一：使用revert git revert HEAD git push origin master 方式二：使用reset git reset --hard HEAD
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
即时通信 IM
ICP备案
云直播
实时音视频
