すべてのgitユーザーにおすすめのhook debuggerやconsole.logなどコミットするべきではないものをコミットすることはありませんか? もしくは他のメンバーがコミットしていてイラッとしたことはありませんか? そんな時はgitのhook(pre-commit)を使います。 以下はこのhookを使うための準備です。 gitのhooksを管理する(自分用テンプレートを使う) git hookでできること pre-commitのコードは以下の通り(ruby) checkesの内容を変えて、自分のチェックしたいコードを追加できます。 #!/usr/bin/env ruby class String # colorization # from http://stackoverflow.com/questions/1489183/colorized-ruby-output def col
今日は、Git で複数人作業を行う際に共有リポジトリから pull する際の rebase オプションの必要性について検討してみました。 タイトルで結果は想像つくような気がしますが、順を追ってみましょう。 git pull でやってること merge と rebase git pull と git pull --rebase まとめ 1. git pull でやってること git pull コマンドは、fetch, merge をまとめて実行しています。 つまり、リモートブランチの最新のコミット情報をローカルトラッキングブランチへ持ってきて(fetch)、持ってきた最新のコミット情報とローカルブランチをマージ(merge)します。 参考:3.5 Git のブランチ機能 - リモートブランチ 2. merge と rebase ブランチを統合するには、マージの他にリベースがあります。 mer
Situs Link Alternatif Inibet Slot Online Terpecaya Industri kasino online berkembang pesat setiap hari. Semakin banyak kasino online yang muncul. Namun, dengan meningkatnya jumlah kasino, jumlah kasino palsu juga meningkat. Kredibilitas kasino online adalah salah satu faktor terbesar yang perlu dipertimbangkan saat mendaftar. Sebagian besar pengguna baru jatuh ke dalam perangkap kasino yang tidak
.gitignore ファイルを手動で書くのは面倒だし、漏れもありそうです。 GitHub の人気プロジェクトの1つである github/gitignore にはさまざまなプロジェクト・環境に合わせた.gitignore ファイルのテンプレートが置いてあり、ここを参考にファイルを作る人も多いでしょう。 gitignore.io はこのプロジェクトのテンプレートを Web から見やすくした感じのサービスです。開発環境に使うものを指定すると自動で .gitignore ファイルのテンプレートを生成してくれます。 これをブラウザから使うのもいいのですが、 API が用意されているのでそこから使うこともできます。つまりターミナルから以下のようにコマンドを叩くと OSX と Linux で開発する Ruby のプロジェクトにあわせた .gitignore テンプレートを生成してくれます。 $ cur
2013-05-22 local repository をよいかんじに remote に同期させる git update git git-update というコマンドがあるわけではありません。エイリアスです github などで PR ベースのチーム開発をしていると、頻繁に branch を切り、 push し、それを誰かが master に merge し、 PR の branch を消す、という流れが発生する。 チームの規模にもよるが、小規模〜中規模なチームでも日によっては5回じゃ効かない。 これを繰替えしているとどうなるかというと、私のようにズボラな場合、 ローカルに、マージ済みの branch がたまる branch 名の補完がききにくくなり、 TAB をばかばか連打して隣の人におこられたり、キーボードがこわれて怒られたりする いつのまにか master が更新されていて、追従する
ライブラリやフレームワークなど、外部のリポジトリで管理されているソースコードをプロジェクトに取り込む際によく使われているgit submoduleを使わないほうが良いという論争が起こっています。それを受けてgit subtreeを使うべきであるというエントリがAtlassianのNicola Paolucci氏がブログに投稿しています。彼はまずgit submoduleを使うべきではないという話題が盛り上がっているという事で3つの記事を参照したあとに、git subtreeを使うべき理由と使用例を挙げています。それによるとgit subtreeを使うべき理由は以下のとおり。 ワークフローがシンプルなので管理が簡単。 古いバージョンのgitもサポートしている。(v1.5.2ですら。) サブプロジェクトのコードがcloneした直後に利用できる。 subtreeはユーザに新しい学習を要求しない。
私は Git の大ファンですが、そのためほとんどの UI (ユーザーインターフェース)、特に IDE に統合されているものに関してはそれほどの大ファンではありません。これらの UI は複雑でややこしいのです。これらはいくつかの一般「VCS」言語をコマンドにマップしようとします。または隠しすぎるので、何が起こっているのか理解しずらくしてしまいます。更にひどい場合: Tcl/Tk で書かれています… 端的に言えば、私はこれらの UI を信頼していません。 コマンドラインは私のためのものです。自分のコマンドラインは好きなので、これは素晴らしいものです。ほとんどいつでも履歴の「グラフィック」ビューを見られることや、コミットを準備している時に少し助けてもらえるのは良いことです。 tig で入力する。tig はテキストモード、 Jonas Fonseca によって書かれた git 用の ncurses
まだあわてるような時間ではございません。 インデックス 1.コミットメッセージを間違えちゃった! -- 直前のコミットのやり直し 2.そろそろブランチを整理しなきゃ! -- ブランチの名称変更と削除 3.間違ってコミットしちゃった! -- コミットを取り消す3つのリセット 4.別のブランチをプッシュしちゃった! -- リモートブランチのリセットと削除 5.コミットの順番を間違えちゃった! -- コミットログの並べ替えと削除 6.コミット細かすぎィ! -- コミットログの統合と編集 7.あのコミットさえあれば…! -- 他のブランチのコミットを適用する 8.やばい!ハードリセットしたら消えちゃった! -- 過去の状態の復元 9.masterにマージ後にバグ発生!どうする!? -- コミットを打ち消すコミット 1.コミットメッセージを間違えちゃった! -- 直前のコミットのやり直し エディタが
もう1年以上前になりますが、コミットメッセージの書き方を説明しました。ざっくりまとめると、以下のことを説明しています。 わかりやすいコミットメッセージがいかに大切か どのようなコミットメッセージがわかりやすいか(具体例付き) この説明をしてからも、日々コミットしていくなかで新たに得られた「どうすればもっとわかりやすいコミットメッセージになるか」という知見が増えていました。これは、コミットへのコメントサービスの提供を開始した1ことも影響しています。このサービスでは、コミットへコメントするときに「どうして自分は他の書き方よりもこの書き方をわかりやすいと感じるか」を説明しています。その過程で「なんとなくこっちの方がよさそう」だったものを「具体的にこういうときにこう感じるのでこっちの方がよさそう」と何かしら理由を考えるようになりました。これにより、今までそれぞれの開発者でなんとなくだった考えが共有
git push/pullは何気なく使ってるけど実はよくわかってなかった。ことのきっかけはこういう質問。 hogeというリモートブランチをローカルのhogeブランチにもってきたい hogeをローカルのmasterにはマージしたくない pullでなんかこんな感じでいけそう? $ git pull origin hoge:hogeでもこれは間違えで、なぜか今いるブランチ(master)にhogeがmergeされるし、期待してる動作じゃない。正解はこう。 $ git branch hoge origin/hogeもしくはチェックアウトも同時にするなら $ git checkout -b hoge origin/hogeこう。自分は普段後者のやり方でやってたけど、なんで上のはダメで下のが正解なのか説明できなかったのでちゃんと調べてみた。 入門Gitと実用Git、あとhelpを参考にした。 ブランチ
思い浮かんだGitのTipsを列挙してみました。 gitのコマンドをで補完する git-completion.bash を入れると、でコマンドの補完が効くようになります。 また、PS1の設定を行うと現在のブランチ名が常にbash上に表示されるようになります。 (Windowsの場合、msysgit は標準で入ってます) contrib/completion/git-completion.bash - GitHub インストール方法(引用) # To use these routines: # # 1) Copy this file to somewhere (e.g. ~/.git-completion.sh). # 2) Add the following line to your .bashrc/.zshrc: # source ~/.git-completion.sh # # 3)
SSH known_hosts and Chef A problem that the documentation for Chef's Deploy_resource talks about is a Chef run pausing while a program it runs waits for user input. One way this presents itself is with SSH's host fingerprint checking, which ensures that the host you're connecting to now is the same host you connected to earlier. When first connecting to a host with anything that runs over SSH, you
Tig の表示方法あれこれ このエントリーはGitアドベントカレンダーの十一日目です。十日目は kyanny さんの「Git における SSH オプション指定方法あれこれ」でした。タイトルは、パクr...リスペクトしました! Tigとは? Tig は ncurses ベースの Git のためのテキストユーザインタフェースです。 Gitリポジトリ内の変更内容を、Vimライクな操作で高速に閲覧することができます。 インストール Mac なら Homebrew か MacPorts でインストールできます。 あとはこちらで。 基本的な使い方 Git レポジトリ内で tig コマンドを打つと、カレントブランチの変更履歴が表示されます。 h でヘルプが見られるので、ビューの切り替え方法などの操作方法を調べることができます。 本題 tig コマンドに引数を渡す事で、開き方を変えることができます。 特定
anythingでgitリポジトリ内のファイルを列挙するなんていうのはやり尽くされている気がするけれど, きちんとやっているものは意外と少なかったので, フルスクラッチで書いた. 特徴 現在開いているファイルと同一のgitリポジトリ内のファイルを列挙する サブモジュール内のファイルも列挙できる 列挙し直さなくていい場合は前に列挙した結果を使い回す ファイルの列挙のためのgitコマンドの呼出しは非同期にやる gitコマンドのエラー処理をきちんとしている 配布場所とインストール インストールするには(helmではなく)anythingを入れた上で, anything-git-files.elをロードパスの通ったところに置く. el-getを使っている場合は以下のレシピを書いてel-get-install RET anything-git-files RETするのが簡単. (:name anyt
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く