序言

我打算系统性整理一下这几年投学习投资理财的心得。因为一方面通过总结，可以让自己进一步加深对投资的理解。另一方面我也想分享给同样想学习理财的读者们。

我的女儿虽然还在读小学，但我也给她报了一个针对小学生的财商课。她对理财非常有兴趣，我也想通过这一系列的文章，给她分享她爸爸的理财成长经历。

这是这是本系列的第一篇，主题是每个人必须自己懂理财。

我身边的案例

我是 80 年代出生的，不得不说，我所处的是那个年代是缺乏理财和财商教育的。因此，我发现我身边的人大多不具备优秀的理财能力。

下面我举几个身边朋友的真实例子。

朋友 A：

他都把挣到的钱存银行定期或者余额宝。但是在现在这个年代，收益率是非常低的，只有一点几。但是他非常胆小，怕买其他的产品会导致亏损，所以说不敢碰。

朋友 B：

朋友 B 买了很多基金。但是他胆子很小，每个只买 1000 - 5000 块钱。然后账户里面有着几十只基金。既看不过来，也不知道应该如何操作。

唯一好的一面是：不管任何行业有行情，他都有一只基金命中。这让他的错失恐惧症（FOMO）小了很多。

朋友 C：

我这个朋友之前在快手上班，在 P2P 盛行的年代，把自己的所有积蓄都投在 P2P 上，最后爆雷，损失惨重。

朋友 D：

这个朋友通过另外一个朋友了解到有一个股票正在做庄阶段，未来会大涨，于是就听信买入，最后损失了 90%。

朋友 E：

朋友 E 的大学同学有一个在香港卖保险，于是听朋友的推荐在香港买了很多保险。但是过了 5 年，他发现收益率和最初承诺的相差非常大。这个时候看合同才发现，合同上写的收益测算并不保证。但是现在赎回的话，只能拿到非常少的本金，所以他只能继续硬着头皮每年交钱。

只有理解才能有效持有

听完上面几个朋友的故事，你身边有类似的朋友吗？

我跟一些朋友交流，我问他们，你们为什么不自己先学习投资理财的知识，之后再去做相关的操作呢？他们很多回答说，这个事情太专业了，专业的事情交给专业的人做就可以了。

当我反问他们：假如你买了一个专业人士管理的基金，那你对他的信仰来自于哪呢？你其实对他每个月发的报告并没有完全的判断能力，你只能选择相信他。

大多数时候，你其实相信的是他过去的业绩。如果它连续三年、连续五年一直都盈利，或者有超额收益，你就会持续持有它，甚至买入更多。

如果它连续几年亏损或者某一年大额亏损，你就会质疑它，甚至赎回它。

你的信心其实就是来源于过去的业绩表现。那这和散户的追涨杀跌有什么本质区别呢？

在你持仓持续下跌的那些时间，你能睡好觉吗？如果你不能理解它，那显然不能。

所以我说，每个人必须懂投资理财。

只有你深刻理解了你买入的是什么，才能在它下跌的时候有信心继续持有它，甚至抄底，才能睡得着觉。

小结

每个人都必须懂理财。因为银行的定期存款利率太低，而其他理财产品都需要深刻理解，才可能做到长期持有。

另外，社会上充斥着像 P2P 一类的产品，以及宣传这类产品的巧舌如簧的销售。他们不断地诱惑着我们，如果我们没有辨识能力，也可能将自己辛苦一辈子挣到的钱损失掉。

以上。

I've created pr-shadow with vibecoding, a tool that maintains a shadow branch for GitHub pull requests(PR) that never requires force-pushing. This addresses pain points Idescribed in Reflectionson LLVM's switch to GitHub pull requests#Patch evolution.

The problem

GitHub structures pull requests around branches, enforcing abranch-centric workflow. There are multiple problems when you force-pusha branch after a rebase:

• The UI displays "force-pushed the BB branch from X to Y". Clicking"compare" shows git diff X..Y, which includes unrelatedupstream commits—not the actual patch difference. For a project likeLLVM with 100+ commits daily, this makes the comparison essentiallyuseless.
• Inline comments may become "outdated" or misplaced after forcepushes.
• If your commit message references an issue or another PR, each forcepush creates a new link on the referenced page, cluttering it withduplicate mentions. (Adding backticks around the link text works aroundthis, but it's not ideal.)

These difficulties lead to recommendations favoring less flexibleworkflows that only append commits (including merge commits) anddiscourage rebases. However, this means working with an outdated base,and switching between the main branch and PR branches causes numerousrebuilds-especially painful for large repositories likellvm-project.

1
2
3
4
5
6
7
8
9
10
11
12
13
14

git switch main; git pull; ninja -C build

# Switching to a feature branch with an outdated base requires numerous rebuilds.
git switch feature0
git merge origin/main  # I prefer `git rebase main` to remove merge commits, which clutter the history
ninja -C out/release

# Switching to another feature branch with an outdated base requires numerous rebuilds.
git switch feature1
git merge origin/main
ninja -C out/release

# Listing fixup commits ignoring upstream merges requires the clumsy --first-parent.
git log --first-parent

In a large repository, avoiding rebases isn't realistic—other commitsfrequently modify nearby lines, and rebasing is often the only way todiscover that your patch needs adjustments due to interactions withother landed changes.

In 2022, GitHub introduced "Pull request title and description" forsquash merging. This means updating the final commit message requiresediting via the web UI. I prefer editing the local commit message andsyncing the PR description from it.

The solution

After updating my main branch, before switching to afeature branch, I always run

1

git rebase main feature

to minimize the number of modified files. To avoid the force-pushproblems, I use pr-shadow to maintain a shadow PR branch (e.g.,pr/feature) that only receives fast-forward commits(including merge commits).

I work freely on my local branch (rebase, amend, squash), then syncto the PR branch using git commit-tree to create a commitwith the same tree but parented to the previous PR HEAD.

1
2
3
4
5
6

Local branch (feature)     PR branch (pr/feature)
        A                         A (init)
        |                         |
        B (amend)                 C1 "Fix bug"
        |                         |
        C (rebase)                C2 "Address review"

Reviewers see clean diffs between C1 and C2, even though theunderlying commits were rewritten.

When a rebase is detected (git merge-base withmain/master changed), the new PR commit is created as a merge commitwith the new merge-base as the second parent. GitHub displays these as"condensed" merges, preserving the diff view for reviewers.

Usage

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

# Initialize and create PR
git switch -c feature
edit && git commit -m feature

# Set `git merge-base origin/main feature` as the initial base. Push to pr/feature and open a GitHub PR.
prs init
# Same but create a draft PR. Repeated `init`s are rejected.
prs init --draft

# Work locally (rebase, amend, etc.)
git fetch origin main:main
git rebase main
git commit --amend

# Sync to PR
prs push "Rebase and fix bug"
# Force push if remote diverged due to messing with pr/feature directly.
prs push --force "Rewrite"

# Update PR title/body from local commit message.
prs desc

# Run gh commands on the PR.
prs gh view
prs gh checks

The tool supports both fork-based workflows (pushing to your fork)and same-repo workflows (for branches likeuser/<name>/feature). It also works with GitHubEnterprise, auto-detecting the host from the repository URL.

Related work

The name "prs" is a tribute to spr, which implements asimilar shadow branch concept. However, spr pushes user branches to themain repository rather than a personal fork. While necessary for stackedpull requests, this approach is discouraged for single PRs as itclutters the upstream repository. pr-shadow avoids this by pushing toyour fork by default.

I owe an apology to folks who receiveusers/MaskRay/feature branches (if they use the defaultfetch = +refs/heads/*:refs/remotes/origin/* to receive userbranches). I had been abusing spr for a long time after LLVM'sGitHub transition to avoid unnecessary rebuilds when switchingbetween the main branch and PR branches.

Additionally, spr embeds a PR URL in commit messages (e.g.,Pull Request: https://github.com/llvm/llvm-project/pull/150816),which can cause downstream forks to add unwanted backlinks to theoriginal PR.

If I need stacked pull requests, I will probably use pr-shadow withthe base patch and just rebase stacked ones - it's unclear how sprhandles stacked PRs.