Oh Shit, Git!?!
Gitって難しい。簡単にぐちゃぐちゃの状態になっちゃうし、失敗を直す方法を知ろうとしたところでまじくそ不可能。Gitのドキュメンテーションって卵とニワトリの問題みたいなところがあって、ハマりから抜け出すために知ってないといけない事柄の名前をあらかじめ知っていないと、どうやって問題を解決したらいいのか検索することすらできないんだよね。 だからここに、私が遭遇したことのあるよろしくない状況から、最終的にどうやって抜け出したかをフツーの日本語で書いていこうと思う。 くっそー、超絶やらかした。お願い、Gitには魔法のタイムマシンがあるって言って？ git reflog # こうすると、Gitでやったことがすべてのブランチに渡って全部見えるよ！ # どのブランチにも HEAD@{index} ってインデックスがあるはずだから # やらかす前のやつを見つけて git reset HEAD@{index
よいコミットメッセージを書くために心がけていること - くりにっき
よいコミットメッセージとはどういうものだろう？ - chiastolite’s blog に対するアンサーソングです chiastolite.hatenablog.com 必要であればWhyを補足するためのContextを書く 元エントリだとコミットメッセージの話だったけど僕はPRで実践してもいいと思います。*1 起点となるURLを明記する レビューで指摘されたのであればPRのコメントのURL issueのURL アプリケーションエラーであればSentryなどのエラートラッキングシステムのURL GitHub外のタスク管理ツール（例：redmineやBacklogやTrelloなど）に修正概要が書かれているのであればそのURL チャットのやり取りが起因ならSlackなどのパーマリンク 公式ドキュメントのURL CIがコケているのであればCIのビルドのURL チーム開発していればコミットやP
git-bugでWebサービスに依存せず、Gitリポジトリだけでバグレポートを管理する | DevelopersIO
git-bugはGitに直接組み込むバグレポートツールです。 レポートそのものをGitリポジトリで管理するところが最大の特徴です。 レポートの作成、編集、コメント、検索などが行えます。 また、インタラクティブなターミナルのインターフェースや、Web UI**[WIP]**が用意されています。 はじめに 本記事で紹介させていただくgit-bugは、2018年9月30日時点でまだ ? This is for now a proof of concept. Expect dragons and unfinished business. ? です。が、仕組み&思想が面白いと思ったのと、今後の流れが楽しみなので記事にさせていただきました。 アプリケーションとタスク管理の関連について アプリケーションに関するタスクの管理にWebサービスを利用するのはかなり一般的になってきたように思います。 この時、パ
git reset がわからない - Qiita
git reset がわからないので図をかいた 以前のコミットへ戻るとき 現在の HEAD へ戻るとき 現在の HEAD へ戻る という日本語はおかしかった。 reset は HEAD の位置を変更する。 オプションとしてステージ上、ワーキングツリーのファイルを削除したり残したりできる。 HEAD へ reset するということは HEAD の位置がかわらない reset --soft はステージにもワーキングツリーにもなにもしない、のでなにもおこらない reset はステージ上からファイルを降ろすので、add の取り消しになる reset --hard はワーキングツリーへの変更も削除してしまう。コミットしていない作業は消える。 メモ ステージ と index は同じもの unstage はステージから削除されるということ HEAD^ は HEAD の一つ前のコミット ローカルファイルを
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
