gitの小ネタ - blog.niw.at
gitの小ネタSausalitoでBostonからのゲストを迎えておいしいお寿司を食べてきました。 ま、全然それは関係ないんですが、久しぶりのブログとして軽くgitの小ネタ的なものを。 gitのコマンドショートカットgit commitとか長いですよね。そういう場合は、~/.gitconfigに次のように書き足しましょう。 [alias] ci = commit これでgit ciでgit commitと同様の動きをします。 カラフルに生のgitは地味ですよね。そういう場合はこうします。 [color] diff = auto status = auto branch = auto あのマージのグラフが見たい…いくつかのGUIツールだと、綺麗なマージ状況を表示する機能があって羨ましいですよね。そういう場合はこうします。 [alias] gr = log --graph --date=sho
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
tmp コミットのための独自サブコマンド git-now - アジャイルSEを目指すブログ
追記[2011/09/26] git-now のurlをgistからgit-hubに変更しました。 追記[2011/10/17] ライセンスはGPLです 一時的なtmp コミットや、簡単なログメッセージのコミット（push 前にログメッセージを整えています）を作るとき、今まで↓みたいな事をしていました。 で、これを使いながら「〜〜も出来たら便利かもー」とかつぶやいていたら、隣の人が一晩で（ｒｙ と、そんな感じで出来た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-svn 利用時にトピックブランチを master へマージするときどの方法が一番良いのか - @kyanny's blog
最近社内に OSQA が導入されて (hiboma++) そこでも聞いてみたんだけどたぶん将来そこに書いたことを忘れると思うのでこっちにも書いておく。コメントもらえたらうれしいです。 git-svn 使っててリモートブランチと対応してるローカルブランチ（git svn info --url で branches/foobar とか出るやつのこと、正式名称わからん）を master にマージするときは --no-ff をつけろ、というのはぐぐるとよくでてくる（--no-ff しない == fast forward してしまうと master の remote url が trunk でなくなってしまうから） しかしふつうのトピックブランチの場合は remote url は trunk のままなので --no-ff をつける必要はない。必要はないがそのかわりに選択しなければならない。どのように
gitでアレを元に戻す108の方法 | Webシステム開発／教育ソリューションのタイムインターメディア
以前gitで一度行った変更をなかったことにする方法4つを紹介しましたが、 日常的に git を使用していると他にも様々な 「なかったことにしたい」「元に戻したい」 という状況に遭遇します。 そのひとつひとつについて対処方法を紹介していきます。 目次 問題1: ライブラリの新機能を試すためにあれこれ適当なコードを書いてみた。でももう要らない。問題2: トピックブランチをマージしたけど実はまだ不完全だった。マージをやり直したい。問題3: リリース後に発覚したバグ。原因は30日前に自分が行ったコミットだった。なかったことにしたい。問題4: 新しいコミットしようとして間違えてgit commit –amendで書き換えてしまった。元に戻したい。問題5: 色々作業していたら作業ディレクトリの内容が混沌としてきた。一度綺麗な状態にしたい。問題6: 作業ディレクトリにゴミファイルが溜まってきた。一度綺麗
GitHubへpull requestする際のベストプラクティス - hnwの日記
みなさん、Git使ってますか？僕はまだメインのVCSがSubversionなのもあって、なかなか慣れません。せっかくGitを使っているのに、ちょっと不便なSubversionくらいの位置づけです。でも、同じような理解度の人って多いんじゃないでしょうか。 一方で、最近はGitHub管理のオープンソースプロジェクトが増えてきました。バグレポートを送るにしてもpull request*1が前提のような空気があり、Git初心者には少し敷居が高い印象があります。 そんな僕も先日初pull requestをしてみたんですが、色々な失敗の積み重ねで残念なpull requestになってしまいました。その反省を元に、本稿ではpull requestする際のベストプラクティスを紹介します。これは「Git Workflow」をベースにコマンド例などを加筆したものです。 概要 pull requestする際は、
【翻訳】Gitをボトムアップから理解する
John Wiegleyさんの "Git from the bottom up" を翻訳しました。 元PDFはこちらからダウンロードできます： http://newartisans.com/2008/04/git-from-the-bottom-up/ 元記事のライセンスがクリエイティブコモンズのBY-SAであったため、この翻訳もBY-SAとなります。 ライセンスを守って自由にご利用ください。（詳しくは記事内の最初にも書いてあります） 翻訳ミスの指摘や改善の提案等があればブログコメントやTwitter(@oshow)などで遠慮なくどうぞ。 Git をボトムアップから理解する Wed, 2 Dec 2009 by John Wiegley 私が Git を理解しようと調査した時、高級なコマンドの視点から眺めるよりボトムアップ式に理解することが役立った。そしてボトムアップ視点で見る Git が
Git で日々の共同作業やリリース作業をサポートする git-daily を作りました | GREE Engineering
こんにちは。インフラの sotarok です。 先日から Git 関連の話をしている通りですが、社内で Git を使い始めています。 今日は、Git を使った日々の開発〜リリースまでのフローや、そうしたものの運用と、それをサポートするために作ったツール git-daily の紹介をしたいと思います。 ソフトウェア開発とウェブ開発の違い いやウェブ開発も広義のソフトウェア開発なのですが、ここでいうソフトウェア開発とは、クライアントアプリケーションやライブラリのようなものを指すと思ってください。 実際、ウェブ開発をしている方は感じていることだとは思いますが、両者の開発フローはかなり異なるものです。もちろん社風や開発の方針等によって色々あるとは思いますが、主に次のような特徴が挙げられると思います： ソフトウェア開発 アプリケーションはクライアントで動作する リリース間隔は比較的長く、次のバージョ
remote に branch を push し、remote から clone したリポジトリの branch を変更して push する - basyura's blog
ローカルで作成した branch は remote に push しないと他の人から見えない。remote から clone したリポジトリは何もしなければ master ブランチしか見えない(ように見える)。 remote に branch を push し、remote から clone したリポジトリの branch を変更して push するまでの操作。 ローカルにリポジトリを作成する $ mkdir sandbox $ cd sandbox/ $ git init Initialized empty Git repository in /repos/sandbox/.git/ $ touch README $ git add . $ git commit -m "first commit" [master (root-commit) d31404a] first commit 0
Gitで共有リポジトリを作るならgitosisが便利 - Pixel Pedals of Tomakomai
ちょろっと渡邉さんのエントリに補足を。 実用Git 吉藤 英明 (監訳) ちなみに、本には直接関係ありませんが、この本の翻訳もGitを使って進められました。 共訳させていただいた「実用Git」が発売になります 原稿はGitで管理しようと言う話は最初から訳者3人の間で出ていたのですが、原稿を管理するとなると当然read権限も含めたパーミッションの管理が必要でした。3人がgit-daemonを立ててお互いにpullしようかとも思ったのですが、git-daemonを使うと匿名で誰でも読めるリポジトリとなってしまいます。HTTP経由だとWEBサーバによってアクセスコントロールはできますが、速度に不安が残ります。ということでsshがベストなんでしょうが、gitのためだけに3人分のアカウントを作るのはちょっと気が引けました。 そこで、今回使ったのがgitosisです。gitosisについては入門git
gitでマージとかdiffとかコミットまとめてpushするとか - ikeike443のブログ
今までもgithubにpushするためだけにgitは使ってたんだけど、最近他人と共同作業するようになって、真面目にgitを学び始めた。 とりあえず今日わかったこと。 困ったら git reflog しろ！ ということで終わりなんだけど、一応以下にメモ的に書いておく。 ツッコミ大歓迎というか、いろいろ教えて欲しいのでむしろツッコンでください。。 自分の作業はこまめにcommitしたいけど、共同リポジトリには意味のある単位でpushしたい こんな風にやればいいのかなという感触を持った。 作業ブランチ（branch1）を作る。 $ git branch branch1 ブランチを切り替える $ git checkout branch1 で、作業ブランチでいろいろ作業してコミットを積み重ねた後、 master に切り替える $ git checkout master 作業ブランチの変更をマージする
git-fixup - Humanity
コミット後に間違いに気付くってことが多いので git の amend は助かる。 2011-01-05 10:41:25 via web これ見てふと思い出した。 前id:kanaさんがtwitterでつぶやいてたgit-fixupってaliasが便利です。 エディタを立ち上げる必要がないので一瞬で終わります。 [alias] fixup = commit --amend -C HEAD コマンドラインで設定するなら git config --global alias.fixup 'commit --amend -C HEAD' 使い方 $ git add ... # 変更を追加 $ git fixup # 前回のコミット(HEAD)に今追加した変更を追加 $ git fixup -a # 現在の全ての変更をHEADに追加 というかこのalias id:thincaさんがはてダで言ってた気
Git ソースコードの鳥瞰図
新しい開発者にとっては Git のソースコードの構成を理解するのは必ずしも 容易ではないでしょう。このセクションでは、どこから開始したら良いかを 示す小さなガイダンスです。 手始めとして良い場所は、初期コミットの内容を見ることです。次のように取得します： 初期コミットには現在の git のほとんど全ての基礎ができていますが、 ざっと読みとおすのには十分な小ささです。 現在ではこのリビジョンの頃から用語が変更されています。例えば、 このリビジョンの README では現在 コミット と呼んでいる ものを "チェンジセット" と呼んでいます。 また、現在は "キャッシュ" という言い方はせず それどころか"索引(index)" と呼んでいますが、 ファイルは今も cache.h です。(注釈：Not much reason to change it now, especially since
プロジェクト内のファイルを絞り込んで操作するanything-git-project.el - yaotti's diary
今まであるプロジェクト内の別ファイルへの移動にはanything-project.elというのを使っていたのですが， ファイルが多いプロジェクトだとちょっと遅い .gitignoreで指定しているファイルも表示される もうちょっといい感じに表示してほしい バージョン管理システムの情報を使っていい感じに並べてほしい という不満があったのでgit用の同じようなものを書きました． List up all files under the control of git and do something (open/view/delete/etc) with them — Gist Modified filesとUntracked filesは毎回更新してるので，ネットワーク越しとかだと重いかもしれません． git使ってる人なら普通に便利だと思います．どうぞ．
Tower Git Client - Tower — The most powerful Git client for Mac and Windows
Version 11.0 was released on May 7, 2024 Version 7.0 was released on May 7, 2024 Read Blog Post Release Notes Git Made Easy Drag and Drop • Undo everything • A unique Conflict Wizard • File history • Extensive documentation • Great customer support Learn More All of Git's Power (And None of the Pain) Pull Requests • Single-line staging • Interactive Rebase • Submodules • Git LFS • Git-Flow • File
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
Git入門 ゼロから始めるGitドリル
gitの勉強をしつつ取ったノートを記事化しました。一応これを読めばざっくりとした導入やSVNとの違いが分かってもらえるように書いたつもりです。svnを使った経験があることを前提に進めていきます。 svnの場合、一つのレポジトリに対して認証のあるユーザが変更を報告していくユースケースをとっています。gitの場合は、個々のローカルマシンにリポジトリが分散されて配置され、お互いに変更を報告しあうユースケース。これはLinuxの伝統的なバザール方式の開発を想定しています。そのため例えばカフェや電車で開発したり、マスターはgithubやgitfarm（Git Hosting参照）にしておいて時々ローカルの変更を報告することも可能です。 目次 インストール 基本操作 Gitリポジトリの作成 ブランチの作成。 タグ ファイルを無視する 索引の理解 取り消し 導入 --hardと--softの違い 一個の
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
はてなブログ | 無料ブログを作成しよう
http://blog.yuku-t.com/entry/20110427/1303868482
submoduleの削除 - 呆備録
