Git 初心者〜中級者に向けて、目立たないけど便利なコマンドを紹介します。
今やソースコード管理システムの標準となっている「Git」(関連記事)。作者のLinus Torvalds氏から指名され、メンテナーとして責任を負っているのが現在米国のGoogle本社に勤務する濱野純氏だ。濱野氏に、メンテナーを引き継いだ経緯、Googleでの仕事などについて聞いた。 Gitコミュニティはどのように活動しているのですか。 本体の開発は、デザインからコードレビューまで、すべてGitメーリングリストで行っています。最近のリリースには、それぞれ60人から80人程による変更が入っていますが、常に活動している主要な開発コミュニティ参加者、と言えるのは10人程度です。 開発者でない人たちで#git IRCチャネルとか、stackoverflowなどでエンドユーザーのサポートをしてくれる人たちの数はもっと多いと思います。この人たちも、Gitコミュニティの重要な仲間です。 Gitコミュニティ
A free Git client for Windows and Mac Sourcetree simplifies how you interact with your Git repositories so you can focus on coding. Visualize and manage your repositories through Sourcetree's simple Git GUI. Simple for beginners Say goodbye to the command line - simplify distributed version control with a Git client and quickly bring everyone up to speed. Powerful for experts Perfect for making ad
8. コミットに入ってる情報 リビジョン (SHA-1 ハッシュ) 例: 23cdd334e6e251336ca7dd34e0f6e3ea08b5d0db Author (コミットを作成した人) 例: オープンソースプロジェクトにパッチを送った人 Committer (コミットを適用した人) 例: 受け取ったパッチを取り込んだ人 ファイルのスナップショット (tree) コミットで変更されたファイルを含むツリー(説明は省略) 1つ前のコミットのリビジョン 例: 4717e3cf182610e9e82940ac45abb0d422a76d77 9. コミットに入ってる情報 リビジョン (SHA-1 ハッシュ) 例: 23cdd334e6e251336ca7dd34e0f6e3ea08b5d0db Author (コミットを作成した人) 例: オープンソースプロジェクトにパッチを送った人 Co
GitHubのイベントである「The GitHub poweredby Agile渋谷 〜日本のSOCIAL CODINGの今を見る〜」の懇親会を受付始めました@HIROCASTERでございませう。 イベント参加者以外でも参加可能のため、イベントは補欠だったけど、どういうふうにGitHubを使っているのか聞きたい人は、ご参加ください。(イベント参加者優先で、空気読んで登録してください) イベントではGitHubの話をするので、Gitが使えることが前提になっています。 そこで、Gitの基本操作方法を学べる「githug」を紹介します。 githug Gazler/githug「githug」はgitの基本操作を実践的に学ぶための良いソフトウェアです。 特に他のバージョン管理システムを使ったことのある人がgitの基本操作だけを学ぶだけならちょうど良い。 インストールgemで公開されているのでイ
Redmineを使ったTiDD(チケット駆動開発)と バージョン管理システムのGitを組み合わせて、どうやって開発していくのが上手い流れを作れるのかということを考えてみました。 まずはTiDDとは何か 気になるところを取り出すと コードに触る前にチケットを切る Ticket First タスクチケットは細分化して、放置されるようなタスクのサイズにしない チケットで親子関係を作ってまとめるといい 親チケット = ストーリーカード 子チケット = タスクカード コードとチケットを関係付ける(コミットコメントにチケット番号の付加など) No Ticket, No Commit katsumic.info – WorkNote » TiDD(チケット駆動開発)でいこう と大体同じです。 次はGitとチケットについて 元々、RedmineのチケットとGitをどう連携させるのがいいのだろう? というと
というのを作ったました。ちょこちょこ機能改善してます。 yuroyoro/git-issue · GitHub git-issue | RubyGems.org | your community gem host 仕事では、異臭管理システムはRedmineを使っていて、作業はsshでサーバに入ってコード書いてるわけです。 で、次どのチケットやろうか、とか今やってるチケットの細かい仕様どうだっけ?みたいなときに、 いちいちブラウザに切り替えて目的のチケットを検索するのタルすぎて死ねる。 もうターミナルから離れたくないんだ俺は。 そこで、'git issue 1000'ってやると1000番のチケットを見ることができるようにした。 $ git issue 15 [open] #15 Issueをadd/updateするときに引数で全部渡すのタルい ------------------------
Some of the commands provided by Git are quite confusing and GUM project tries to address it. However it looks like most useful stuff can also be achieved through use of Git aliases: [alias] stage = !sh -c '[[ -z "$@" ]] && git add -u || git add "$@" && git add -u "$@" ' - unstage = reset HEAD -- rewind = ![[ -z "$@" ]] && git reset --hard HEAD || git checkout HEAD These aliases provide such new c
What is Easy Git (eg)? In short, Easy GIT is a single-file wrapper script for git, designed to make git easy to learn and use. (If you are not familiar with what git is, this page will make no sense to you.) In more detail: eg focuses on documentation and examples Much of the work in eg is plugging a gap in git documentation: providing simple tutorial-oriented command-specific built-in help. eg's
A free Git client for Windows and Mac Sourcetree simplifies how you interact with your Git repositories so you can focus on coding. Visualize and manage your repositories through Sourcetree's simple Git GUI. Simple for beginners Say goodbye to the command line - simplify distributed version control with a Git client and quickly bring everyone up to speed. Powerful for experts Perfect for making ad
git diffした時に、横に長い行の表示がコンソールの右につきぬけてしまって、右のほうが見えなくなってしまうんだけど、どうすればコンソールの右で折り返して表示してくれるのか誰か教えてくれませんか。MacのTerminalです。 http://twitter.com/shin1ogawa/status/13489861413 というのがあって、 git diff --color | less -Rとかで出来るっぽいという話になったんだけど、そんなのやらなくても設定でどうにかできるはずだよね、という話をhokaccha氏にしてみたら、すぐに調べて教えてくれた。ありがとうございます! $HOME/.gitconfig に、 [color] ui = auto [core] pager = less -rと書いておけばいいだけらしい。 git diffとかで表示が切れてしまうときの対象方法 -
追記:たくさんブクマしていただいて驚いております。ブクマコメントだと、やはり git push -f は反則だろという意見がサイレントマジョリティのようですが、そこはそれ、自 己 責 任 追記2(2011/11/07):commit messageをミスった場合について訂正しました。 git rebase -i で直近のコミットを "edit" にして修正すると、 「--amend使えや」と言われるようです。 gitのコミットをしくじった時の対処法について、一覧性の高いまとめがなかったので作りました。正確さは保証できないので、コマンド名ヒントに自分でググって下さい ほかのやり方があるよ、間違ってるよ等のご指摘歓迎です。 派閥別 gitでコミットミスった時のまとめ | ├─ 一人で使ってるよ | | | ├─ 手元に変更を取り戻したいよ(1)(そうだね、add忘れだね派) | |
追記[2011/09/26] git-now のurlをgistからgit-hubに変更しました。 追記[2011/10/17] ライセンスはGPLです 一時的なtmp コミットや、簡単なログメッセージのコミット(push 前にログメッセージを整えています)を作るとき、今まで↓みたいな事をしていました。 で、これを使いながら「〜〜も出来たら便利かもー」とかつぶやいていたら、隣の人が一晩で(ry と、そんな感じで出来たgit-now の紹介 簡単な実行例 コマンド $ git now これで、版管理されているファイルのtmp コミットが作成できます。 コミットメッセージ例 [from now] Tue Dec 7 23:00:24 2010 diff --git a/hello.py b/hello.py index 51cff9f..9e84b86 100644 --- a/hello.p
前回 git diff を図に書いてみたところ、自分の中で意外と整理できたので、これまたなんとなく使っていた git reset についてもまとめてみた。 とりあえず結論を先にまとめよう。 git reset とは? HEAD の位置を変更するコマンド。 オプションによってインデックス、ワーキングツリーの内容も変更できる。 git reset のオプションは? --soft、--mixed(オプションなしと同等)、--hard オプションがあり、影響度の小さい順に以下のようになる。 --soft HEAD の位置のみを変更する。インデックス、ワーキングツリーには影響なし。 --mixed (またはオプションなし) HEAD の位置とインデックスを変更する。ワーキングツリーには影響なし。 --hard HEADの位置、インデックス、ワーキングツリーをすべて変更する。 さて、git reset
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く