Gitでやらかした時に使える19個の奥義 - Qiitaタイトルは大目に見てください><。 本内容は危険な操作を伴うのでくれぐれも自己責任でお願いします。 間違いもあったら指摘ください。 ローカル編 自分のローカル環境だけで閉じていて、他の人への影響がない場合に有効です。 リモートにプッシュしちゃってる時は、他人への影響が発生するので危険です。 やらかし１：コミットメッセージに禁止ワード入ってて人生やめたい時 コミットメッセージを修正するのは簡単です。 ファイルの追加なんかもできちゃいます
スッキリ！ Git Commit Log - Qiita
以下のような人向けの記事です コミット履歴がスッキリしていないと気になって仕方がないという人 1つのコミットは1つの修正(typo修正、バグ修正、機能追加)に対応していないと落ち着かないという人 けどわりとよくルールを無視した修正やコミットをしてしまい後で直したくなる人 注意点 下記文中ではコミットログの改変を行なっています 複数人で共有リポジトリを使っている場合、共有済みのコミットログに対する改変は行わないようにしましょう まだ共有リポジトリにpushしていなければOK! 途中でgit rebaseを利用している箇所がありますが、rebaseそのものついての説明は省略しています 今の作業を一時的に中断して別の作業をやりたい 機能追加の修正を行なっている最中にtypoを見つけてしまったけど、機能追加が終わるのを待ってたら忘れてしまうかもしれないし・・・というようなケースの場合。 git s
How can I fix the Git error "object file ... is empty"?
When I try to commit changes, I get this error: error: object file .git/objects/31/65329bb680e30595f242b7c4d8406ca63eeab0 is empty fatal: loose object 3165329bb680e30595f242b7c4d8406ca63eeab0 (stored in .git/objects/31/65329bb680e30595f242b7c4d8406ca63eeab0) is corrupt I tried git fsck I've got: error: object file .git/objects/03/dfd60a4809a3ba7023cbf098eb322d08630b71 is empty fatal: loose object
tigから git rebase -i したらいろいろ捗った - くりにっき
git dtコマンド - razokulover publog を見て自分もgitのコマンドをカスタマイズしてるのを思い出したので普段よく使っているのを紹介します。 対象者 作業途中はtmpコミットをたくさん作って、最後に git rebase -i でコミットを整えている人 前置き gitのタイプ数を減らす gitコマンドを使う時に毎回 git と3文字タイプするのは時間の無駄なのでエイリアスつけるのをおすすめします ~/.bash_profile とか ~/.bashrc 辺りに下記を書きます。 alias g='git' これで g だけでgitコマンドが使えます git-now iwata/git-now tmp コミットのための独自サブコマンド git-now - アジャイルSEを目指すブログ 最速でtmpコミットするためのコマンド。Macなら brew install git-
ghq: リモートリポジトリのローカルクローンをシンプルに管理する - 詩と創作・思索のひろば
以前紹介したghqというツールで GitHub のリポジトリを手元に簡単クローンしてたのを、環境が新しくなったついでに Go で書き直し、完全リニューアルしました。（前は zsh だったのでなんだかなーと思ってた。） そもそも何をするツールか GitHub や Google Code Project でホストされている Git、Mercurial のリポジトリを手元にクローンすることができます。リポジトリは設定したルート（デフォルトで ~/.ghq）以下に、以下のようなパスで置かれます。 ~/.ghq/github.com/motemen/ghq go get と似てますね。同じような感じで ghq get <URL> します。 % ghq get https://github.com/motemen/ghq clone https://github.com/motemen/ghq ->
ghqを使ったローカルリポジトリの統一的・効率的な管理について - Kentaro Kuribayashi's blog
GitなどのVCSからcloneしたローカルリポジトリをどう管理するのがいい感じなのか、よくわからない。なんとなく自己流でやっているが、もっといい方法を知りたい。 tl;dr - ディレクトリレイアウトをgolangの作法に合わせ、すべてのリモートリポジトリをghqを使ってcloneし、percolを使って簡単に検索できるようにしましょう。 追記: いまならpercolの代わりにpecoというツールを使うのもよいでしょう。というか、僕はそうしています。設定方法はこのエントリとほぼ同様の内容でいけると思います。 背景 そんな課題を抱えつつも、特になにかをするわけでもなく日々暮らしていた折、Rebuild: 42: When in Golang, Do as the Gophers Do (lestrrat)で@lestrratさんが、Goのお作法に、他の言語のリポジトリも含め、すべてあわせる
GitHubユーザーのためのhubコマンド - Qiita
ちなみにプロンプトにブランチ名を表示している場合は，プロンプト表示速度の低下を避けるために以下の設定を忘れずに． hubコマンドを利用&&プロンプトにgitのブランチ等を表示している人向けのzsh高速化 - Qiita よく使うコマンド hub browse [user/repo] hub browseでいまいるレポジトリのgithubページを開く．hub browse defunkt/hubみたいにレポジトリ指定もできる． browseは打ちにくすぎるので，seeにエイリアスしてる hub clone user/repo git clone https://github.com/rails/rails.gitと同じことをhub clone rails/railsでできる．ちょっと便利． gemのcloneならgem-browseコマンドを入れるともっと便利． 参考: gem の gith
Gitを使った分散開発管理12 – プロジェクトの共有 | DevelopersIO
複数人でGitを使用した作業 いままでのgit作業はずっと同一マシン上で、１人で作業をおこなってきました。 しかしある程度の規模になると、複数人での作業は当たり前になります。 そのような場合には、共有サーバー上にリポジトリを作成し、そこから個々の環境へリポジトリをコピーする方式が一般的です。 今回はリモートでGitを使用する方法について説明します。 リモートリポジトリとやり取りするためのプロトコル Gitではリモートリポジトリとやりとりするため、下記のプロトコルを使用することができます。 local git ssh http/https localプロトコル localプロトコルはリモートリポジトリを別のディレクトリに置く形式です。 例えば、全員がアクセスできるNFSやSMBなどの共有ファイルシステムがある場合に使用されることがあります。 下記のようにしてリモートリポジトリから取得すること
gitshでgitのタイプ数を減らす
gitshでgitのタイプ数を減らす gitはサブコマンドやオプションが多い．だからshellのaliasやらgitのaliasで頑張ってコマンドのタイプ数を減らす．Thoughbotの@georgebrockさんのgitshを使えばもっとコマンドのタイプ数を減らすことができる． 例えば以下はよく打つコマンド．gitって打ち過ぎ． $ git status $ git add -u $ git commit -m "Commit message" $ git push gitshを使うと専用のモードへのアタッチが始まり，gitを打たずサブコマンドだけを打てばよくなる． $ gitsh gitsh@ status gitsh@ add -u gitsh@ commit -m "Commit message" gitsh@ push gitsh@ :exit gitのaliasも引き継がれるの
GitHubをさらに便利に使う、hubコマンドを活用しよう！ | Act as Professional
hubコマンドは、MacやLinuxのターミナルからGitHubの操作をおこなうためのコマンドです。通常はブラウザを通しておこなっているような操作をCLIでおこなうことができます。 これがURLを渡すだけで、利用シーンがあるので、紹介します。 インストール公式サイトを確認する限りgemでインストールするのは、動作が遅くなるので非推奨とのこと。よって、Mac環境はHomebrewかMacPortsで入れた方が良い。 gitコマンドのエイリアスとしてhubを設定してしまうことが推奨されてますが、あえて今回はしません。 MacPortsの場合 $ sudo port install hub Homebrewの場合 $ brew install hub 動作確認$ hub --version git version 1.7.12.4 hub version 1.10.2GitHubへの初回アクセス
gitのdiff, status, logを極限までコンパクト化＋便利化する - Qiita
git diffを見やすくする git diff --color-words で差分を小さく表示する 通常のgit diffは行単位なので、例えば変数名を一括変更した場合見づらいです。 --color-wordsを指定すると記号やスペースで区切られた単語単位でのdiffを表示できます。gitの設定は不要です。 より細かな表示のカスタマイズも可能です。man git-diffで--word-diffを検索してみてください。 ※ただし、変更が複雑な場合は、通常のgit diffのほうが見やすいこともあります。 .gitattributesを設置してもっと小さく表示する .gitattributesファイルを設置することで、言語文法に基づいて変数名、関数名といった単位でdiffを表示できます ファイル設置後にgit diff --color-wordsとすると、下記のようにさらに小さく表示できま
fugitive.vim をもっと使いこなす - 反省はしても後悔はしない
この記事は Vim Advent Calendar 2013 の 16 日目の記事です。 昨日は id:deris さんの Vimmerなら2013年中に試しておきたい海外産Vim plugin 8選 - derisの日記 でした。知らないプラグインあったので時間ができたら試してみたいですね。 進捗ダメです すみません。本当は自作プラグインを大々的に紹介するつもりだったのですが、進捗ダメでした。今日は fugitive.vim の小ネタについて書きます。 次回作にご期待ください。 fugitive.vim について Vim から Git を便利に使うプラグインです。詳しくは VimmerなGit使いはfugitive.vimを今すぐ入れたほうがいい - SELECT * FROM life; fugitive.vim が便利すぎたのでメモ - 反省はしても後悔はしない (ステマ) みたいな
わかりやすいコミットメッセージの書き方 - 2013-04-24 - ククログ
もう1年以上前になりますが、コミットメッセージの書き方を説明しました。ざっくりまとめると、以下のことを説明しています。 わかりやすいコミットメッセージがいかに大切か どのようなコミットメッセージがわかりやすいか（具体例付き） この説明をしてからも、日々コミットしていくなかで新たに得られた「どうすればもっとわかりやすいコミットメッセージになるか」という知見が増えていました。これは、コミットへのコメントサービスの提供を開始した1ことも影響しています。このサービスでは、コミットへコメントするときに「どうして自分は他の書き方よりもこの書き方をわかりやすいと感じるか」を説明しています。その過程で「なんとなくこっちの方がよさそう」だったものを「具体的にこういうときにこう感じるのでこっちの方がよさそう」と何かしら理由を考えるようになりました。これにより、今までそれぞれの開発者でなんとなくだった考えが共有
コミットメッセージの作法 - Qiita
gitプロジェクトのガイドラインを参考にまとめました。この作法は英語で書くことが前提となっています。 1. コミットメッセージの1行目は短い説明文(50文字以内) モジュールについての修正の場合、モジュール名: ではじめる 説明文は小文字ではじめる 説明文のピリオド(句点)を省く 2. 2行目は空行にする そうすることで、例えばコミットした内容を E-Mail に変更するツールにて、 Subjectに最初の行を使用し、残りの行を本文にすることができる。 3. 本文には意味ある内容を含める 問題点: 修正した問題点について説明する 妥当性: 行った修正について、「なぜその方法がより良いのか」を説明する 代替案: もし、他の修正方法を検討したのなら、それらについて説明する 4. 変更は命令形で表現する まるであなたがコードベースに変更を命令じているかのように書く。 [bad] "This pa
Rails で、Controller に定義されている action を一度に取得する方法はありますか？ - QA@IT
平素よりQA＠ITをご利用いただき、誠にありがとうございます。 QA＠ITは「質問や回答を『共有』し『編集』していくことでベストなQAを蓄積できる、ITエンジニアのための問題解決コミュニティー」として約7年間運営をしてきました。これまでサービスを続けることができたのは、QA＠ITのコンセプトに共感をいただき、適切な質問や回答をお寄せいただいた皆さまのご支援があったからこそと考えております。重ねて御礼申し上げます。 しかしながら、エンジニアの情報入手方法の多様化やQAサービス市場の状況、＠ITの今後のメディア運営方針などを検討した結果、2020年2月28日（金）15:00をもちましてQA＠ITのサービスを終了することにしました。 これまでご利用をいただきました皆さまには残念なお知らせとなり、誠に心苦しく思っております。何とぞ、ご理解をいただけますと幸いです。 QA＠ITの7年間で皆さまの知識
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Git・GitHubに隠された便利な機能 | GitHub Cheat Sheet（日本語訳） - Qiita
YAPC::Asia 2014 で「Git によるツール開発」というタイトルで話しました #yapcasia - 詩と創作・思索のひろば
Git でマージ済みのブランチを一括削除する - Qiita
gitでpecoを使ってチェックアウトする - ぼっち勉強会
git-now, git-masterのインストール方法 — mistilteinn 0.1.0 documentation