Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?
一年くらい前から git を使い始め、ここ半年くらいは毎日の開発に git を使っています。昨日 git stash という機能を使っている時に失敗してしまい、何人かの方にアドバイスいただくことによって無事回復することが出来たので、感謝の印として、そして運悪く同じ問題に遭遇してしまった人たち(私もまたやるかも)へのメモとして記しておきます。 御託はいいから、早く回復法を知りたい人のためのまとめ $ git fsck | awk '/dangling commit/ {print $3}' 候補の sha1 がいくつか出てくる(長く開発していると、結構多く候補が出てきます) $ git show --summary 候補のsha1 一つ一つの sha1 の内容を確認 $ git cherry-pick -n -m1 見つけたsha1 いきさつ 私の作業のやりかたでは、 タスク毎にブランチを切
The entire Pro Git book, written by Scott Chacon and Ben Straub and published by Apress, is available here. All content is licensed under the Creative Commons Attribution Non Commercial Share Alike 3.0 license. Print versions of the book are available on Amazon.com. The version found here has been updated with corrections and additions from hundreds of contributors. If you see an error or have a s
1. 使い始める 1.1 バージョン管理に関して 1.2 Git略史 1.3 Gitの基本 1.4 コマンドライン 1.5 Gitのインストール 1.6 最初のGitの構成 1.7 ヘルプを見る 1.8 まとめ 2. Git の基本 2.1 Git リポジトリの取得 2.2 変更内容のリポジトリへの記録 2.3 コミット履歴の閲覧 2.4 作業のやり直し 2.5 リモートでの作業 2.6 タグ 2.7 Git エイリアス 2.8 まとめ 3. Git のブランチ機能 3.1 ブランチとは 3.2 ブランチとマージの基本 3.3 ブランチの管理 3.4 ブランチでの作業の流れ 3.5 リモートブランチ 3.6 リベース 3.7 まとめ 4. Gitサーバー 4.1 プロトコル 4.2 サーバー用の Git の取得 4.3 SSH 公開鍵の作成 4.4 サーバーのセットアップ 4.5 Git
An interactive Git visualization tool to educate and challenge!
以前gitで一度行った変更をなかったことにする方法4つを紹介しましたが、 日常的に git を使用していると他にも様々な 「なかったことにしたい」「元に戻したい」 という状況に遭遇します。 そのひとつひとつについて対処方法を紹介していきます。 目次 問題1: ライブラリの新機能を試すためにあれこれ適当なコードを書いてみた。でももう要らない。問題2: トピックブランチをマージしたけど実はまだ不完全だった。マージをやり直したい。問題3: リリース後に発覚したバグ。原因は30日前に自分が行ったコミットだった。なかったことにしたい。問題4: 新しいコミットしようとして間違えてgit commit –amendで書き換えてしまった。元に戻したい。問題5: 色々作業していたら作業ディレクトリの内容が混沌としてきた。一度綺麗な状態にしたい。問題6: 作業ディレクトリにゴミファイルが溜まってきた。一度綺麗
大分前にこんな感じの事をしたので、その時の覚え書き。githubで管理されているOSSなんかでは良く、下記のようなURLでドキュメントを公開しているプロジェクトがありますよね。 http://[account_name].github.com/[repository_name]/ account_name(アカウント名)がサブドメイン repository_nameが対象のリポジトリ名 これどうやってんだろう？と思ってたのがきっかけです。以下手順を見てみましょう。前提として既にgithub上にリポジトリを持っていることとします。 GitHub Pagesを用意する そもそも、上のURL体系でページが参照できるのは、Github Pagesのおかげのようなので、まずはこれを用意します。Github Pagesを利用していないリポジトリで上のようなURLにアクセスすると、ご丁寧にページの作り方
前回 git diff を図に書いてみたところ、自分の中で意外と整理できたので、これまたなんとなく使っていた git reset についてもまとめてみた。 とりあえず結論を先にまとめよう。 git reset とは？ HEAD の位置を変更するコマンド。 オプションによってインデックス、ワーキングツリーの内容も変更できる。 git reset のオプションは？ --soft、--mixed(オプションなしと同等)、--hard オプションがあり、影響度の小さい順に以下のようになる。 --soft HEAD の位置のみを変更する。インデックス、ワーキングツリーには影響なし。 --mixed (またはオプションなし) HEAD の位置とインデックスを変更する。ワーキングツリーには影響なし。 --hard HEADの位置、インデックス、ワーキングツリーをすべて変更する。 さて、git reset
社内向けに「こわくない Git」というタイトルのスライドを作って発表しました。 対象者は「マージがなんとなく怖い」「エラーが怖い」「リベース使うなって言われて怖い」と、Git が怖いと思っている人です！ こわくない Git from Kota Saito 発表中に出た質問など 補足も兼ねて、上のスライドを発表した際に出た質疑応答などをここに書いておきます。 Q: 常に Non Fast-Forward (--no-ff) でいいのでは、と思えるけど git merge がデフォルトだと Fast-Foward or Non Fast-Forward (--ff) なのはなぜ？ A1: Non Fast-Forward だと、確かにメリットが多いのですが、1点だけデメリットがあります。特に差分が無い状態で git merge --no-ff すると、空のマージコミットが作られてしまうのです。
オペレーションとかインフラ系のエンジニアリングからは少々離れそうなので、個人的な備忘録がてら、Gitのブランチモデルについて。淡々と書くよ。 見えないチカラ: A successful Git branching model を翻訳しました 基本的に、このA successful Git branching model（上記は翻訳記事）を参考にしています。ですが、完全ではありません。運用しながら都合よく省略していますし、悪く言えば曲解もしています。あくまで、わたしが都合良く解釈して取り回した結果と考えてください。 さて、このようなドッシリとしたブランチモデルが、あらゆる規模のプロジェクトに対して有効であるかといえば、もちろんそうではありません。コツコツ個人で開発しているライブラリなどは、ブランチを使わなくても良いケースがあるでしょうし、作ってもバージョン番号ブランチぐらいのケースだってザラ
git先日、msysGit（Git for Windows）がいよいよ公式に UTF-8 をサポート！ という記事で「UTF-8 対応のコードがコミットされた」ことをお伝えしましたが、ついに、UTF-8 対応の新バージョン、msysGit 1.7.10 がリリースされました。いよいよ Windows でも日本語ファイル名を扱えるようになったので、「git では "詳細設計所仕様書.xlsx" をコミットできないんでしょ？」とブーブーいってた人を説得できる材料はそろいました!!!!それを記念して、この記事では UTF-8 対応の msysGit 1.7.10 を試してみた ブーブーいう人を黙らせるための「GUI で git する Windows 向けツール」まとめの2本立てでお送りしたいと思います。UTF-8 対応の msysGit 1.7.10 を試してみたさっそく Google Code
エンジニアgithubを使ってみたいWindowsユーザでTortoise大好きっこのアナタに！TortoiseGitからgithubを使ってみましょう。 全体の流れ とっても優しい github の使い方 - ¬¬日常日記こちらのサイトに沿っていきます。ただしクライアントはWindowsのTortoiseGitになります。実用レベルに達したWindows向けGitクライアント「TortoiseGit」でGitを始めよう - SourceForge.JP Magazine : オープンソースの話題満載TortoiseGitについてはこちらのサイトを参照します。 いちおうTortoiseSVNの経験があるとわかりやすいと思います。 githubアカウント作成Secure source code hosting and collaborative development - GitHub公式サ
Vincent Driessenさんの "A successful Git branching model" を翻訳しました。 元記事はこちら： http://nvie.com/posts/a-successful-git-branching-model/ （翻訳の公開と画像の利用は本人より許諾済みです） このブランチモデルの導入を補助してくれる、git-flowというGit用プラグインがあるそうです。 翻訳の間違い等があれば遠慮なくご指摘ください。 A successful Git branching model この記事では、私のいくつかのプロジェクト（仕事でもプライベートでも）で約一年ほど導入して、とてもうまくいくことがわかった開発モデルを紹介する。しばらく前からこれについて書くつもりだったんだが、今まですっかりその時間を見つけられずにいた。ここでは私のプロジェクトの詳細については書
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く