第17回: revertの基本 — 本番で「安全に取り消す」ために履歴を壊さないという考え方
開発では、マージした変更をあとから取り消したくなることがあります。
Author
開発では、マージした変更をあとから取り消したくなることがあります。
実務では、作業中に細かくコミットを積むことがあります。
Gitの実務に少し慣れてくると、merge に加えて rebase という言葉をよく見かけます。
チームやOSSの開発では、元のリポジトリに直接書き込めないことがあります。
実務では、プルリクエストを出したあとにレビューコメントが返ってくるのが普通です。
Gitを学び始めた段階では、push までできれば十分に見えるかもしれません。しかし実務では、push は共有の入口にすぎません。
ここまで見てきたGit操作は、主に「自分の変更を安全に管理する」ためのものでした。これは土台としてとても重要です。
ここまで学んできた操作の多くは、ローカルPCの中で完結していました。しかし実務では、履歴をチームと共有する必要があります。
ブランチは作業を分けるための仕組みですが、分けたままだと本流には反映されません。