[翻訳] GitTorrentを発表 - 分散型GitHub -
How will you describe my blog? Please tell me on twitter or email. ヤク中 この投稿はChris Ball氏による次の投稿を翻訳したものです。 Chris Ball » Announcing GitTorrent: A Decentralized GitHub すべての権利は彼に帰属します。あと私はまだ大学生なのでちょっと翻訳が汚いです。 原文より口調が強いといったこともあるかもしれません。まあこまけえことは気にせず読みな！ 本文 (この投稿は2015年の5月にData Terra Nemoのカンファレンスで行ったトーク の意欲に溢れた原稿です。私が実際に行ったものと同じトークをよりゆっくりと話したものの動画が 近いうちに公開されます。) 私は分散型GitHubの構築に取り組んでいるのですが、このことが何を意味し、なぜ重要な
オレ流 Pull Request 作業フロー - 詩と創作・思索のひろば
チームで作業する同じリポジトリの中で Pull Request を送り合うのではなく、オープンソースプロジェクトに外部から PR がやってくる場合の話です。 最近のフロー 送られてきた PR に対しては、大まかには仕様の話、実装方針の話、具体的な実装の話を詰めながらマージできるように持っていくわけだけれど、それがほとんど満足いく状態になっていてマージしたいと思うタイミングになっても、変数の名前付けだとか、ちょっとした処理の書き方だとかで、相手にお願いするよりは自分で手を加えてからマージした方が手っ取り早いことがある。そういう時は PR 元のブランチを手元にチェックアウトして、そのブランチを自分の変更で進めた上で master にマージするようにすると、push 時に PR も閉じられて便利です。 motemen/lgtm.sh#1 の例。分かりにくいれど、PR にさらに 1 コミット足して
複数のgitリポジトリの中に共通のライブラリを入れるベスト・プラクティスを教えて下さい。
例えばAとBというgitリポジトリの中に共通のライブラリ等があって、 それをシンボリックリンクでワンソースで管理したいという要件があるとします。 ディレクトリ例 A/.git /lib -> ../lib B/.git /lib -> ../lib lib/ しかし、このような場合にA・Bでcommitするとシンボリックリンクはファイルとして扱われてしまいますので、そこからさらにpushした時にlib以下のファイルの実体まではpushされないかと思います。 これは、例えばアプリサーバーと管理画面サーバーでサーバーを分けてて中では所々同じソースを使っている環境なんかにこのような事が発生すると思うのですが、こういった場合の最適解を教えて頂きたく存じます。
master への push を禁止するローカル git hook の正しい書き方 - 永遠に未完成
GitHub などで Pull Request ベースで開発をしていると、master には間違っても push したくないわけです。 GitHub 側には残念ながら master への push を禁止するような設定はできないので、仕方ないのでクライアント側の Hook で対応しようってことになり、この方法についてググるとこことかこことか、いくつか方法を紹介しているページが出てくるんですが、どれもやり方が間違っている*1ので、正しい方法を紹介。 何がまずいのか 上記に挙げた方法では、細かい部分は違ってたりするけど、git symbolic-ref HEAD を使って現在ブランチを見て、master だったら push を禁止する、という方法を取っている。 しかし、push はカレントブランチから行われるとは限らない。dev ブランチにいるときに git push origin maste
`git push -u` オプションの意味 - Qiita
-u, --set-upstream For every branch that is up to date or successfully pushed, add upstream (tracking) reference, used by argument-less git-pull(1) and other commands. For more information, see branch.<name>.merge in git-config(1). 全く何を言ってるのかわからない！ 答え ネットで検索してみたら答えがわかった。 git push -u origin master とすると次回から git push だけで勝手に origin master で push してくれる。 ちなみに git push とかの マニュアルは全て man git-push とか man gi
私の使うGitコマンドまとめ 基本コマンド編 - What is it, naokirin?
独りAdvent Calendarへの挑戦の一発目として、私がよく使うGitのコマンドをまとめていくことにします。 あまり使いこんではいないので役に立つかわかりませんが書いていきます。 git init (リポジトリの作成) git add (管理するファイルの指定) git rm (ファイルの削除) git mv (ファイルの移動・リネーム) git commit (コミット) git init (リポジトリの作成) cd path/to/repo git initで path/to/repo ディレクトリにGitのリポジトリの作成を行います。 リポジトリの作成の際に行われることはディレクトリ下に ls -a . .. .gitのように.gitディレクトリを作成することです。 この.gitディレクトリにGitの管理ファイルが格納されます。 つまり通常、このディレクトリ下を触ることはありま
Gitでブランチを統合する方法 — 裏紙
#!/bin/sh rm -fr .git *.txt .gitignore git init echo init.sh>.gitignore && git add .gitignore && git commit -m "Initial Commit" echo b>b.txt && git add b.txt && git commit -m "master 1" git branch other echo c>c.txt && git add c.txt && git commit -m "master 2" echo d>d.txt && git add d.txt && git commit -m "master 3" git checkout other echo e>e.txt && git add e.txt && git commit -m "other 1" echo
つるはしで過去を発掘する - Qiita
この記事はGit Advent Calendar / Jun.27日目の記事です！ 26日目はhoshina85@githubさんの横着で神経質な私とあなたに贈るgit add -pでした。「Adventってなんなの？」って方は、Wikipediaの解説をご覧下さい。 特定の文字列を変更したコミットを探し出す テンプレの張りつけが終わったところで改めましてこんにちわ、実用Gitの訳者の一人、hirataraです。 7/1の江頭2:50さんの降誕を待ち望むAdventの期間も残り4日間となりました(残り3日間の担当者募集中です！)。今日はGitでつるはしを使って過去の遺物を掘り起こす話を書こうと思います。 つるはしとはpickaxeのことです。pickaxeはgitのサブコマンドではありませんが、gitglossaryやgitdiffcoreのドキュメント中で言及されていたり、diffcor
git diff の使い方がほんの少し理解できた - murankの日記
いままでなんとなく使ってきたけど、ようやく使い方が分かったような気がするのでメモ。 前提知識 インデックスとワーキングツリーが理解できていること HEAD が何か分かっていること git diff ワーキングツリーとインデックスの差分を表示。 git add した後にさらに修正したけど、そういえばどの時点で git add したのかなー、というときに使う？ git add したらすぐにコミットする自分には関係なさそう。 git diff --cached HEAD とインデックスの差分を表示。 git add して、コミットする前に差分を確認したい時に使うんだと思う。 自分は git diff よりもこっちの方をよく使う。 git diff HEAD HEAD とワーキングツリーの差分を表示。 前にコミットした時からどれくらい編集したか確認したい時に使う。 HEAD の部分はコミット(HE
View differences of branches with meld?
I know that I can view the difference between HEAD and current state with meld .. But how can I view the differences between branches, for example master and devel with meld? At the moment I do the following steps: Rename folder of working copy For example mv /projectA /projectA_master) Clone the project again git clone url Switch to devel branch cd projectA && git -b devel origin/devel View diffe
巨大なリポジトリ を Git で上手く扱う方法 | Atlassian Japan 公式ブログ | アトラシアン株式会社
git は、コードベースの発展過程を記録し、開発者間の協同作業を効率化する強力なツールです。でも、記録対象のリポジトリがとてつもなく巨大なものになったときは何が起こるのでしょうか？ この記事では、いくつかの異なる意味での巨大化に正しく対処するためのアイデアと手法を少し紹介してみたいと思います。 二種類の 巨大なリポジトリ よく考えてみると 巨大なリポジトリ が生ずる理由はおおまかに言って二つあります: 非常に長い期間にわたって履歴が積み上げられた (プロジェクトが非常に長い期間継続的に拡大を続けたために開発成果が積み重なった) 場合 巨大でしかも履歴の記録が必要なバイナリ データが存在し、それがコードに反映される場合 その両方の場合 即ち、リポジトリの巨大化は二つの異なる方向に向かって起こることになります。それは、作業ディレクトリのサイズ (即ち直近のコミットのサイズ) の問題と全体の履歴
アホみたいにでかいgit repositoryを上手く扱う方法 - Qiita
gitが大きくなると時間かかってしゃーないと思っていたら、ちょうどatlassianのブログにこんな記事があった。 How to handle big repositories with git - Atlassian Blogs 巨大なリポジトリ を Git で上手く扱う方法 直訳ではなく、読んだことを参考に自分用にメモを記す。これは本当にメモ代わりなので原文を参照した方がいいと思う。 gitが重くなる原因は、「長い歴史」と「デカいファイル」の2つがある。その2つの対処法。 長い歴史に対処する shallow cloneを使う gitのhistoryが積み重なると、git cloneに時間がかかる。そのときはshallow cloneを使って、深さを限定してcloneする。 git clone --depth depth remote-url 手元の環境だと23sくらいかかっていたのでも
git diff で Office ファイルの差分を見る - Qiita
入れたくないとは思っていても、止むに止まれぬ事情で Word, Excel, PowerPoint などのファイルを git レポジトリの中で管理することはありませんか？この記事では、Mac で Office ファイルの diff を取る方法を紹介します。Linux でも多分動くはず。 textconv 普通、バイナリファイルを git diff しても、変更内容がわかりません。ところが、git には textconv という、バイナリファイル（別にバイナリじゃなくてもいいんですが）をコマンドに渡した結果を diff に使う機能があります。ドキュメントには、JPEG の Exif 情報の diff を取る例等が載っています。 Office ファイルからのテキスト抽出 では、Office ファイルからテキストを抽出するにはどうすればいいでしょう？Windows の msysgit には as
カレントディレクトリがGitリポジトリ下か否か判定する - すぎゃーんメモ
カレントディレクトリがGitリポジトリ管理下か否か、ってどうやって判定するのが良いのだろう 2012-03-23 12:52:55 via Twitter for Mac @sugyan 僕はこうしています。ご参考までに。 URL 2012-03-23 13:01:51 via web to @sugyan @Cside_ ありがとうございます、やっぱりそんな感じですかねー！ 2012-03-23 14:06:12 via Twitter for Mac to @Cside_ @sugyan もしzshでならこんな感じでできます． URL 2012-03-23 14:16:21 via YoruFukurou to @sugyan @yaotti ありがとうございます、vcs_infoは便利ですよねー。シェルスクリプト内で判定つかいたいなーと思ったのですが、vcs_infoの中ではgit
GitLab魔改造カンファレンスで発表してきました - catatsuyとは
2/6(Thu) に株式会社ドリコムとピクシブ株式会社の合同で GitLab 魔改造カンファレンスが行われました 会場はドリコムさんのオフィスでとてもおしゃれな感じでした ドリコム攻めに来ました— 麺類 (@catatsuy) February 6, 2014 ドリコム綺麗すぎて圧倒されてる— 麺類 (@catatsuy) February 6, 2014 ドリコムさんから 3 人，ピクシブからも私を含めて 3 人が発表しました 私が発表した理由として，ピクシブでは一部のサーバーを除いてサーバーの root をインフラの人間しか持てません なので GitLab など新しいツールを使うにはインフラの協力が不可欠なのですが，私が GitLab 導入を提案した一人だったので成り行きで GitLab 導入やその後の運用を適当な感じでやっていました そんな中，魔改造カンファレンスの話が回ってきたので
gitでアレを元に戻す108の方法 | Webシステム開発／教育ソリューションのタイムインターメディア
以前gitで一度行った変更をなかったことにする方法4つを紹介しましたが、 日常的に git を使用していると他にも様々な 「なかったことにしたい」「元に戻したい」 という状況に遭遇します。 そのひとつひとつについて対処方法を紹介していきます。 目次 問題1: ライブラリの新機能を試すためにあれこれ適当なコードを書いてみた。でももう要らない。問題2: トピックブランチをマージしたけど実はまだ不完全だった。マージをやり直したい。問題3: リリース後に発覚したバグ。原因は30日前に自分が行ったコミットだった。なかったことにしたい。問題4: 新しいコミットしようとして間違えてgit commit –amendで書き換えてしまった。元に戻したい。問題5: 色々作業していたら作業ディレクトリの内容が混沌としてきた。一度綺麗な状態にしたい。問題6: 作業ディレクトリにゴミファイルが溜まってきた。一度綺麗
【旧版】git入門 (全22回) - プログラミングならドットインストール
旧版のレッスンは更新を終了しており、現状と異なる場合があります。サポートも終了しておりますので、最新版への移行をお願いします。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
すごいGit楽しく学ぼう
Make it a true gitk replacement · Issue #5 · gregsexton/gitv
いつやるの？Git入門