new page: fwrite.md

[rotarymars]

確認お願いします。

[github-actions]

⚡ プレビュー (HTML) (更新時刻: 2025-09-05 21:38:02 JST)

• ⫯ Commit: b0cdd5c
• プレビューの生成には時間がかかります (3～5分)。進捗状況はこちらをご確認ください。

変更記事一覧

5件の記事が変更されました。

• 📝 reference/cstdio
• 📝 reference/cstdio/fgets
• 📝 reference/cstdio/fputs
• 📝 reference/cstdio/fread
• 📝 reference/cstdio/fwrite ✨

※ソース (.md) に直接変更のあった記事を列挙しています。グローバル修飾や変換規則の変更による変化は考慮していません。

[akinomyoga]

ありがとうございます!

[rotarymars]

すみません、最近ずっと見ることができていませんでした。
ありがとうございました。

[akinomyoga]

LGTM

[rotarymars]

ありがとうございます。マージします。

[yohhoy]

@rotarymars
マージ済みissueに対してのコメントで恐縮ですが、 master(main) ブランチ から pull request ブランチへは merge ではなく rebase 頂いた方が、git history上もすっきりすると思います...
（コミット b0cdd5c 時点での操作の話です）

[akinomyoga]

私も前々から思っていたのですが…後の集計が大変になるので squash merge にして一つにした方が良いです (今回の場合は commit f596c4c だけは性質が違うので、この commit だけは別 commit に分けておいても良いと思いますが)。

もしかしたら貢献ポイントが「変更をまとめない」ことの動機づけ要因になっているかもしれませんが、以下の規則がありますのでポイントにカウントするべきかは微妙です。

site/start_editing.md

Lines 315 to 319 in 76555be

	- 同年内の当人による同ページへの複数の修正は、貢献ポイントをまとめる場合がある
	- 連続した作業が複数コミットになった場合などにまとめる
	- 複数の仕様変更による複数の修正の場合などはまとめない
	- 同ページ内に対する複数の修正は、大きい貢献ポイントにまとめる場合がある
	- リンク追加・修正を含む説明修正は、fixmやfixlなどにまとめる

この規則は、ミスをすればするほど貢献ポイントが高くなるみたいな状況を避けるために導入されたもので、例えばレビューで指摘されたミスを貢献ポイントに計上するのは如何だろう、というような背景があることと思います。

[rotarymars]

すみません。
Gitの履歴のことや年度末の貢献度のポイントの集計のことなどのことはあまり考えずに作業していました。
今後はなるべく1コミットで1機能、ログもあまり複雑に交差しすぎないように気をつけます。