Go Nishiduka underground0930

エンジニアのための法律勉強会#1『受託開発における契約時の注意事項』参加メモ

http://coedo-dev.doorkeeper.jp/events/20181
講師: 野島梨恵氏（東京山王法律事務所）
2015-02-10 19:15-20:45
Co-Edo

前提

システム開発そのものは素人だけど、裁判にはクライアント/開発側の両方で関わったことがある。
裁判官はもっとシステム開発については分かってない。

tag作成

# アノテーションなしでタグ作成
$ git tag v1.0.0
# アノテーション付きでタグ作成
$ git tag -a v1.0.0 -m "message"

tagをpush

Git ファイルの履歴を完全に削除する

秘密鍵など誤ってコミットしてしまった場合に履歴を完全に削除する手順
参考:6.4 Git のさまざまなツール - 歴史の書き換え

動作確認用にブランチを作成して試す

$ git checkout -b clean-key-file

動作確認用にブランチでgit filter-branchを実行

GitHub Flow

Scott Chacon on the Interwebs

31 Aug 2011

git-flowの問題点 (Issues with git-flow)

私は人々にGitを教えるためにあちこちを飛び回っているが、最近のほぼすべてのクラスやワークショップで git-flow についてどう思うかを尋ねられた。私はいつも、git-flowは素晴らしいと思うと答えている。何百万ものワークフローを持ったシステム（Git）を提供し、ドキュメントもあるし、よくテストされている。フレキシブルなワークフローは、実に容易なやり方で多くの開発者の役に立つ。標準的なものになりつつあり、開発者はプロジェクトや企業の間を移動しつつこの標準的なワークフローに馴染むことができる。

	以下の実現したいことに基づいて、この機能を実現する関数の正しさを検証するための網羅的なテストケースをVitestで生成しテストファイルを作成・更新してください。テストコードや実装コードはまだ書かず、テストケースのみを出力してください。エッジケースや制約条件がしっかりテストされているか確認できるように、各テストメソッドには意図がわかるコメントを添えてください。もし、仕様やデータフローが不明瞭であれば都度ユーザに聞いて下さい。

	[出力要件]
	実際のテストロジック（arrangeやモックの実装など）は絶対に書かないでください。
	代わりに Vitest の describe と it.todo を使用して、テストの階層構造とケース名のみを定義してください。
	テストケース名（it.todoの引数）は、それ自体が「生きたドキュメント（仕様書）」となるよう、「〜の時、〜であること」と振る舞いが明確にわかる日本語で記述してください。
	モック利用を前提としたテストケースは作らないこと


	[実現したいこと]