Pro Git 日本語版電子書籍公開サイト
| 書籍紹介 | サイトの目的 | ダウンロード | 更新情報 | 謝辞 | お問い合わせ | 書籍紹介 Git は、 Linux カーネル開発のために Linus Torvalds さんが2005年に公開した分散型バージョン管理システムです。スタートアップのような小規模組織からGoogle、 IBM のような巨大企業で、また数多くのオープンソースプロジェクトで利用されています。現在の Git 開発は、濱野純さんを中心としたコミュニティによって非常に活発に行われています。 本書 Pro Git は、2009年に Apress から初版が、2014年に第2版が出版された、Git の解説書です。著者の Scott Chacon さんは、GitHub 社の CIO、Git のエバンジェリストであり、Git 公式サイトの管理者でもあります。 本書の内容は、出版以降も有志により頻繁に更新されており、
「こわくない Git」というスライドを発表しました - kotas.tech
社内向けに「こわくない 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 Tips
Mislav Marohnićさんの "A few git tips you didn't know about" を翻訳しました。 元記事はこちら： http://mislav.uniqpath.com/2010/07/git-tips/ （翻訳の公開は本人より許諾済みです） 翻訳の間違い等があれば遠慮なくご指摘ください。 あなたの知らないGit Tips注意：いくつかのコマンドやオプションは Git の version 1.7.2 以降が必要です。 OS Xでは、 Homebrew で簡単にアップグレードできます： brew install git git log でブランチとタグも見る$ git log --oneline --decorate 7466000 (HEAD, mislav/master, mislav) fix test that fails if current d
マージ後のreset HEAD^は危険だった - unpushの日記
直前のマージを取り消す場合は、 × git reset --hard HEAD^ではなく、 ○ git reset --hard ORIG_HEADとしないと危ない、という話。 「マージ後にgit reset --hard HEAD^で取り消し」は去年の日記でもけっこう使ってるけど、たまたま上手くいっていたからよかったが、ORIG_HEADが正しい指定方法だった。場合によってはちょっと危ない。 マージコミットは複数のparentが記録されるが、mergeコマンドによって先端を移動するブランチ（＝カレントのブランチ）を１番目の親としてマージコミットが作成される。 例えば topicブランチで git merge master とした場合に作成されるコミットオブジェクトは、１番目のparentはtopicブランチのハッシュ値で、２番目はmasterブランチのハッシュ値となる。 なので、その後t
「Pull Request」 はオープンソースに限らず使える優れた開発フローだ - 肉とビールとパンケーキ by @sotarok
チーム開発において、「チケット/Issue」「TDD」「コードレビュー」など、ソースコードの変更に対する効果的な開発フローについてよく考えるのだけど、なんにしてもこのあたりは非常に課題が多く、各社各コミュニティで色々なやり方が模索されているポイントだと思う。 で、まぁご多分に漏れず僕もよく考えるわけだけど、現状その過程で Pull Request こそが非常に効果的なのではないか、と思うので、ちょっとまとめてみようかと思う。 もちろん、言うまでもないようなことだよ、という人もいるかもしれないけど、そういう人がたくさんいると、非常に喜ばしいことだね。 Pull Request とは GitHub でこう呼ばれているので、こう呼ぶことにするが、ここでは、複数のリポジトリ/ブランチ間でのオープンな patch のやりとりのことだと考える。 あと、自分が使っているのが Git なので、ここでは G
gitでアレを元に戻す108の方法 | Webシステム開発／教育ソリューションのタイムインターメディア
以前gitで一度行った変更をなかったことにする方法4つを紹介しましたが、 日常的に git を使用していると他にも様々な 「なかったことにしたい」「元に戻したい」 という状況に遭遇します。 そのひとつひとつについて対処方法を紹介していきます。 目次 問題1: ライブラリの新機能を試すためにあれこれ適当なコードを書いてみた。でももう要らない。問題2: トピックブランチをマージしたけど実はまだ不完全だった。マージをやり直したい。問題3: リリース後に発覚したバグ。原因は30日前に自分が行ったコミットだった。なかったことにしたい。問題4: 新しいコミットしようとして間違えてgit commit –amendで書き換えてしまった。元に戻したい。問題5: 色々作業していたら作業ディレクトリの内容が混沌としてきた。一度綺麗な状態にしたい。問題6: 作業ディレクトリにゴミファイルが溜まってきた。一度綺麗
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へpull requestする際のベストプラクティス - hnwの日記
みなさん、Git使ってますか？僕はまだメインのVCSがSubversionなのもあって、なかなか慣れません。せっかくGitを使っているのに、ちょっと不便なSubversionくらいの位置づけです。でも、同じような理解度の人って多いんじゃないでしょうか。 一方で、最近はGitHub管理のオープンソースプロジェクトが増えてきました。バグレポートを送るにしてもpull request*1が前提のような空気があり、Git初心者には少し敷居が高い印象があります。 そんな僕も先日初pull requestをしてみたんですが、色々な失敗の積み重ねで残念なpull requestになってしまいました。その反省を元に、本稿ではpull requestする際のベストプラクティスを紹介します。これは「Git Workflow」をベースにコマンド例などを加筆したものです。 概要 pull requestする際は、
Accueil
Les Sociétés Civiles de Placement Immobilier (SCPI) se sont imposées comme une solution d'investissement de choix, attirant un nombre croissant d'investisseurs en quête de diversification et de rendements potentiellement plus élevés. Dans un contexte économique en constante évolution, où les investisseurs cherchent à optimiser leur portefeuille tout en minimisant les risques, les SCPI représentent
git - 簡単ガイド
アッド & コミット 変更されたファイルを選択します。 git add <filename> git add * を実行するとIndexに追加されます。 これは基本的な作業の一つです。 変更を実際に適用するには git commit -m "Commit message" を実行します。 変更がHEADに入りましたが、 リモートリポジトリには未だ入っていません。 変更のプッシュ この時点で、変更がローカルリポジトリのHEADに適用されました。この変更をリモートリポジトリに適用するには git push origin master を実行し、masterの代わりに適用のブランチ名を入れます。 もし既存リポジトリをクローンせずに使用した場合 git remote add origin <server> を実行すると、リモートリポジトリを登録する事が可能です。 これで変更を特定なリモートリポジト
あまり知られていないGitのTips - アジャイルSEを目指すブログ
思い浮かんだ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)
Git初心者が絶対に覚えておくべきコマンド - idesaku blog
Gitの使い方を覚えるにあたって、まず知っておきたいのは――git-cloneだのgit-commitだのは当然として――「操作をミスったときにどのように回復するか」である。それを実現するのは、次の３つのコマンドだ。 git-commit --amend git-reset git-reflog git-commit --amend あるファイルをコミットしたとしよう。 $ (edit...) $ git commit -am 'メッセージ生成処理を実装したよ。'しかし、しばらくして彼は気づいた。 def create_massage(param) ...typoしてる！massageじゃない、messageだ！マッサージを作ってどうする！ 慌てるな。まずは直してステージに上げるんだ*1。 def create_message(param) ...$ git add .そして…。 $ gi
ホームディレクトリをGitで簡単に管理するための.gitignore活用法
さて、まったくブログを更新していないtfmagicianです。 こんにちは。 先月は1記事しか書いてないですね。今年は月10記事以上を目標に、楽しみながら書いていきます。 今日は、Gitをネタに取り上げます。 前回はプロジェクトに関するGitネタでしたが、今回は個人的なモノ。 Gitと一緒にCakePHPを楽しむ – CakePHP Advent Calendar 2010 6日目 あなたの宝物が詰まったホームディレクトリをGitで管理してみます。 ホームディレクトリの”なに”を管理するか これは人によって異なります。 例えば、あなたがMac使いで、Mac上でGitを使うというなら、ドキュメントも管理したくなるかもしれない。 例えば、あたながLinux使いなら、設定ファイルだけGitで管理出来れば良いかもしれない。 .gitignoreをうまく設定出来れば、どちらのパターンも対応出
jmblog.jp – さくらの VPS に node.js + npm + Socket.IO をインストールする手順
さくらのVPS（というか、CentOS）に node.js と Socket.IO をインストールしてみたので、備忘録として手順をまとめておきます。 環境と各バージョン VPS の OS CentOS 5.5 x86_64（標準OS） node.js v0.3.1-pre npm 0.2.7-2 Socket.IO 0.6.1 git のインストール RPMForgeをyumリポジトリに追加します。/etc/yum.repo.d/rpmforge.repo を以下の内容で作成。 $ sudo vim /etc/yum.repo.d/rpmforge.repo [rpmforge] name = Red Hat Enterprise $releasever - RPMforge.net - dag mirrorlist = http://apt.sw.be/redhat/el5/en/mir
Git入門 ゼロから始めるGitドリル
gitの勉強をしつつ取ったノートを記事化しました。一応これを読めばざっくりとした導入やSVNとの違いが分かってもらえるように書いたつもりです。svnを使った経験があることを前提に進めていきます。 svnの場合、一つのレポジトリに対して認証のあるユーザが変更を報告していくユースケースをとっています。gitの場合は、個々のローカルマシンにリポジトリが分散されて配置され、お互いに変更を報告しあうユースケース。これはLinuxの伝統的なバザール方式の開発を想定しています。そのため例えばカフェや電車で開発したり、マスターはgithubやgitfarm（Git Hosting参照）にしておいて時々ローカルの変更を報告することも可能です。 目次 インストール 基本操作 Gitリポジトリの作成 ブランチの作成。 タグ ファイルを無視する 索引の理解 取り消し 導入 --hardと--softの違い 一個の
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Gitでリモートの共有リポジトリにあるブランチを消す時のメモ - longkey1's blog