GitHubのJohn Britton氏によるGitのレッスン | Engine Yard Blog JP
Gitを日常の開発に使っていても、Gitがどのように動作しているのかや、ブランチやコミットがどのような概念なのかをはっきいりと理解していない人は少なくないでしょう。今回、GitHubのJohn Britton氏がイベントの為に来日し、下北沢オープンソースカフェにてGitについての非常に細かい内容についてのセッションを行ってくれました。 動画 90分ほどのセッションが高画質で録画されています。全編英語のセッションとなっていますが画面も見やすいのでご覧になってみてください。Gitのリポジトリがどういった情報を操作しているのかなどをさまざまなコマンドの実行結果と共に解説を加えるわかりやすい内容です。 大まかな話題 Gitのリポジトリの基本概念 ツリーオブジェクト・オブジェクト ワーキングコピー、ステージング、ヒストリの違い ブランチの動き セッション中のハイライトをいくつかをツイートからご紹介し
tig なんて目じゃない！ Git のログ系 Vim プラグイン gitv ＆ gitv をGit 統合インターフェース化する最強の設定 - 反省はしても後悔はしない
この記事は Vim Advent Calendar 2012 の 168 日目の記事です。 昨日は id:yonchu さんの accelerated-smooth-scroll という Vimプラグイン を作った (Vim Advent Calendar 2012, 167日目) - よんちゅBlog でした。 はじめに 最近、Git のログを見る系のエントリが多い気がします。今回の Vim Advent Calendar でも はじめての unite source(unite-tig) - Design x Verification vac143 - YouTube Vimでgitのログをきれいに表示する - derisの日記 という記事がありましたし、また最近 git? tig! | Atlassian Japan CUI で Git 使うなら入れておきたいツールまとめ | バシャロ
Pro Git 日本語版電子書籍公開サイト
| 書籍紹介 | サイトの目的 | ダウンロード | 更新情報 | 謝辞 | お問い合わせ | 書籍紹介 Git は、 Linux カーネル開発のために Linus Torvalds さんが2005年に公開した分散型バージョン管理システムです。スタートアップのような小規模組織からGoogle、 IBM のような巨大企業で、また数多くのオープンソースプロジェクトで利用されています。現在の Git 開発は、濱野純さんを中心としたコミュニティによって非常に活発に行われています。 本書 Pro Git は、2009年に Apress から初版が、2014年に第2版が出版された、Git の解説書です。著者の Scott Chacon さんは、GitHub 社の CIO、Git のエバンジェリストであり、Git 公式サイトの管理者でもあります。 本書の内容は、出版以降も有志により頻繁に更新されており、
既に削除したリモートブランチを一覧から削除したい - rela1470のブログ
社内でちゃんとgitを使っていると､すごくbranchの増減があり、 fetchしたタイミングによってbranchの存在情報がバンバン入っていきます。 しかし、その開発branchが削除されても、 git branch -a で削除されているはずのbranchが表示されてしまう場合があります。 これは.git/objectsフォルダにゴミオブジェクトが残っているからです。 実際はどこにもリンクしていないオブジェクトですので、まとめて削除してしまいましょう。 どこにもリンクしていないオブジェクトを全て削除する命令が「prune」です。 こんな風に使います。 git fetch --prune pruneしても通常は全く問題がないはず（どこにもリンクしていないオブジェクトを消しているだけなので）ですので、自分ではfetchする際には必ずpruneオプションをつけています。 実際、自社の開発フェ
knife-solo v0.3.0のrake installでabortedする場合 - F.Ko-Jiの「一秒後は未来」
「入門Chef Solo – Infrastructure as Code [Kindle版]」を読みつつ knife-solo の 0.3.0 をインストールしようとしたら rake aborted! になってしまった。 $ git clone git://github.com/matschaffer/knife-solo.git $ cd knife-solo $ rake install rake aborted! ERROR: While executing gem ... (Gem::InvalidSpecificationException) ["lib/knife-solo/resources/patch_cookbooks/chef-solo-search/.travis.yml", "lib/knife-solo/resources/patch_cookbooks/che
gitでアレを元に戻す108の方法 | Webシステム開発／教育ソリューションのタイムインターメディア
以前gitで一度行った変更をなかったことにする方法4つを紹介しましたが、 日常的に git を使用していると他にも様々な 「なかったことにしたい」「元に戻したい」 という状況に遭遇します。 そのひとつひとつについて対処方法を紹介していきます。 目次 問題1: ライブラリの新機能を試すためにあれこれ適当なコードを書いてみた。でももう要らない。問題2: トピックブランチをマージしたけど実はまだ不完全だった。マージをやり直したい。問題3: リリース後に発覚したバグ。原因は30日前に自分が行ったコミットだった。なかったことにしたい。問題4: 新しいコミットしようとして間違えてgit commit –amendで書き換えてしまった。元に戻したい。問題5: 色々作業していたら作業ディレクトリの内容が混沌としてきた。一度綺麗な状態にしたい。問題6: 作業ディレクトリにゴミファイルが溜まってきた。一度綺麗
transitive.info - git branch 使い方
git branch 使い方 新しいブランチを作成する ブランチ new-branch を新しく作るには git branch new-branch とする。すでに new-branch というブランチが存在しているときはエラーになる。 ブランチやコミットから新しいブランチを作成する あるコミットを指示する some-commit や他のブランチ other-branch から ブランチ new-branch を作成するには git branch new-branch some-commit git branch new-branch other-commit とする。たとえば、最新のコミットを除いて新しいブランチを作る （2つ前のコミットからブランチを作る）には git branch new-branch HEAD^ とする。 ローカルのブランチの一覧を見る git branch とする
rebase について - ぐるぐる～
rebase 便利だよ、というだけのエントリです。 AA で書いてる部分は時間があれば画像に置き換えます。 rebase とは ブランチを作成した場所を変更することと理解しています。つまり、そのブランチの「親」を変更する、ということです。 もう少し動作に踏み込むと、指定したコミットの後ろに現在のブランチで行ったコミットをリプレイするように適用します*1。単なるリプレイではなく、その過程をいじくれるのが rebase のすごいところです。 単純な rebase はたとえばこんな感じです。 以下のようなリポジトリの状態があったとして (現在チェックアウトされているブランチは dev ということを表すのに * を使っています)、 1---2---3 *dev / A---B---C---D master次のコマンドを実行します。 $ git rebase masterこれにより、リポジトリの状態
git rebaseのメモ - unpushの日記
ときどき間違うので。 大雑把に言うと、git rebase は「git reset + git cherry-pick × n回 を自動化したもの」と考えられる（適用するコミット群が少なければ、手動でreset & cherry-pickしても良いが、たくさんあるとそうもいかない） 好きな場所にresetして、好きな位置から好きな位置までのコミットを順次適用できる。 つまりコミットを並べ替えたり除外したり、「積み木を積み直す」ようなことが出来る。 git rebase ポピュラーな使い方。 現在のブランチをにreset から見て現在のブランチにだけ存在していたコミットを順に適用 適用されるコミット群は、から見て現在のブランチにだけ存在していたコミット、つまりgit log ..HEAD で出てくるコミット。 以下の例だとA、B、Cのコミットがreset後に適用される予定 A---B---C
git revert で複数コミットを打ち消す - miauのブログ
git にはコミットした内容を取り消す方法がいくつかありますが、いったんリリースしたコンテンツの公開期間が終了してその内容を取り下げたいような場合は、git revert でリリース時のコミットを打ち消すコミットを作るのがお作法です。 今回まさにそういう状況になったんですが、リリース時のコミットが複数回にまたがっており、それも 先のエントリ で書いたように他の対応と入り交じってコミットされてしまっています。 こういう場合にどう revert すればいいかという話です。 revert の基本的なところ 例えば 3a0e871f というコミットを打ち消したい場合は、 git revert 3a0e871fを実行すれば、 Revert "xxx 対応" This reverts commit 3a0e871ff60411ca89fa07c7f2b4d426fa04285d.のようなメッセージがみ
git-flow によるブランチの管理
今回は分散バージョン管理システムgitと共に用いる「ブランチモデル」について紹介していただきます。gitを使ってみて、その高機能さをどう使えば良いか悩まれた方は、ぜひ本稿をご一読ください。gitそのものの使い方については解説していませんので、その際には『 実用git 』などの書籍を参考にしてください。 git-flow は Vincent Driessen 氏によって書かれた A successful Git branching model (O-Show 氏による日本語訳) というブランチモデルを補助するための git 拡張です。 git-flow を利用する前には、まずこの文章を一読することをおすすめします。 その骨子については、 Voluntas 氏のブログ が参考になります。 git を使うメリットの 1 つは、そのブランチモデルです。しかし gitを使っていると、その高い柔軟性か
GitHub Flow – Scott Chacon
Issues with git-flow I travel all over the place teaching Git to people and nearly every class and workshop I’ve done recently has asked me what I think about git-flow. I always answer that I think that it’s great - it has taken a system (Git) that has a million possible workflows and documented a well tested, flexible workflow that works for lots of developers in a fairly straightforward manner.
Git超入門 - 猿でもできるGit rebase · DQNEO日記
むちゃくちゃわかりやすい例を考えてみた 今あなたは、羊を数えるプロジェクトをGitで開始しました。 羊を１匹数えるごとに１コミットして、３コミットまで終わりました。 ひつじが1ぴき (←1コミット目) ひつじが2ひき (←2コミット目) ひつじが3ひき (←3コミット目) masterブランチの歴史 (左から右に進みます) １ぴき ２ひき ３ひき ○ － ○ － ○ ワイルドプログラマ、wildブランチを作る ここで突然ワイルドプログラマのスギちゃんが登場します。 スギちゃんは、masterブランチをもとにwildブランチを作成して、そこで１コミットずつ発言をワイルドに変えてしまいました。 ひつじが1ぴきだぜぃ ひつじが2ひきだぜぃ ひつじが3ひきだぜぃ wildブランチの歴史 (左から右に進みます) １ぴき ２ひき ３ひき １ﾜｲﾙﾄﾞ ２ﾜｲﾙﾄﾞ ３ﾜｲﾙﾄﾞ ○ － ○ － ○ －
「git commit するまえに考えるべき10のこと」がDVCS的じゃない件 - うさぎ組
はじめに git commit するまえに考えるべき10のこと | Act as Professionalを読んでいろいろと思うことがあったので書きました。 これはSCMBootCamp主催者としてとか、Mercurialユーザーを代表してとかではありません。 僕はこう思う。ということです。 読むの面倒な人は最下部のまとめだけ読めばok。 commit != push DVCSの利点はローカルコミットという概念を持ち込んだことです。これにより、高速な履歴追加、安全なマージを手に入れることができました。 件の記事を読んでいて気になったのは、commitという単語です。 特に、 1コミットに1つの対応 コメントアウトしたコードをコミットしない テストが正常に通過したものにしてください コミットメッセージの1行目は”短い説明” コミットメッセージのスタイル コミットメッセージのボディは有意義な内
プロとしての行為 Act as Proffesional
Gitのブランチをどのタイミングで切って、マージしていくかなども非常に大切ですが、ブランチやマージをするよりも頻繁におこなうコミットについて、あらためて基本に立ち返ってみましょう。 一つ一つのコミットを綺麗に積み重ねていくことは、ブランチを切るタイミングやマージ、歴史の改編などを容易にすることができます。コミットが綺麗に積み重ねられていないとマージや歴史改変で苦労するでしょう。 Gitのベストプラクティス（原文）に乗っかるためにもgit commitする前に以下のようなことをチェックしましょう。 Gitの操作に慣れている人はPushやMergeをする前に今回紹介するようなことを元にしてコミットの歴史を綺麗に整えましょう。 1コミットに1つの対応1コミットにはあれこれ詰め込めすぎるべきではありません。例えば以下のような2つのことがあったとします。 Aの機能を追加Bの機能のバグを修正2つの対応
A successful Git branching model » nvie.com
Note of reflection (March 5, 2020) This model was conceived in 2010, now more than 10 years ago, and not very long after Git itself came into being. In those 10 years, git-flow (the branching model laid out in this article) has become hugely popular in many a software team to the point where people have started treating it like a standard of sorts — but unfortunately also as a dogma or panacea. Du
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
git-flowでもgithub flowでもない、Git本家推奨のワークフロー
gitで複数のコミットを1つにまとめる | Webシステム開発／教育ソリューションのタイムインターメディア
gitでコミットの順序を入れ替える | Webシステム開発／教育ソリューションのタイムインターメディア
error: insufficient permission for adding an object to repository database .git/objects - 604 Error Code Not Found