Git submodule の基礎 - Qiita
この記事は Git Advent Calendar 6日目の記事です！ Git submodule って最初わかりにくいと思うので、基本的な説明をしようと思います。 git submodule とは git submodule は、外部の git リポジトリを、自分の git リポジトリのサブディレクトリとして登録し、特定の commit を参照する仕組みです。 Subversion でいうところの、external と似ています。 さて、解説のため、手元に、リポジトリA (/path/to/a) とAの submodule として、よく使う例として Bootstrap (元Twitter Bootstrap) を登録してみます。 git submodule を理解するうえで重要なのは、 リポジトリAが指し示すsubmoduleとしてのBootstrapのcommit 現在のBootstr
Git vs. Mercurial: why Git? - Work Life by Atlassian
This is a guest blog post by Charles O’Farrell, a developer at Atlassian, that will focus on the reasons a team may choose Git as their DVCS of choice. Charles is focused on coding in any DVCS and has spent some time switching users over from ClearCase to Git. In our previous blog we explored why teams may choose Mercurial as their distributed version control system of choice. Now let’s explore wh
git diffで比較した差分のファイルだけを抽出するスクリプト - hogehoge foobar Blog Style Beta
HTML等をgitで管理していると、サーバーへのアップロード用のファイルとしてコミットした差分のファイルだけを抽出したい事があります。 「git diff」で差分の表示は出来るのですが、ディレクトリ構造を保持した状態でのファイル抽出みたいな事は出来ないようだったので、Perlでスクリプトを書いてみました。 ※bashとかでも書けると思いますが、なんとなくPerlで書いてみました。 「git diff --name-only」で差分のファイル名を取得 普通にgit diffを使うと・・・ gitでの差分の表示には「git diff」を使用しますが、そのまま使うとファイルの内容まで表示されてしまいます。 $ git diff HEAD^ diff --git a/bar.txt b/bar.txt new file mode 100755 index 0000000..9e74262 ---
GitHubでプルリクエスト用ブランチを保守するメモ - なんたらノート第三期ベータ
GitHubにリポジトリを置いてる人はみんなプルリクエストを待っています。けどプルリクエスト用にフォークした自分のリポジトリを保守する方法が途中でわからなくなって...という人が案外多いんじゃないかなと思ったり。なので、ちょっとメモ置いときます。って、人のためみたいな言い方ですが、まあ自分用のメモです。 まずこうしたほうがいいという原則。masterブランチはフォーク元から変更せず、かならず自分用のブランチを作る。これは、masterを作業の同期用に置いておくためです。 自分のブランチでコミットしたあと、フォーク元のmasterが進んでないかのチェックは必ずすること。 もし進んでいたら自分のmasterに元作者のコミットを取り込んで自分のGitHubでのフォークが最新と同期してる状態にしましょう。で、元作者のコミットログを確認して何が起こったのかを理解しましょう。 $ git checko
bzr-git で快適 github 生活 - methaneのブログ
Bazaar のホスティングサイトとして、 Launchpad があります。これはプロジェクトをまたぐ Issue Tracker やオンラインの翻訳システムが含まれており、 Ubuntu の開発に大活躍しています。 しかし、 Launchpad は github や BitBucket とは異なり、ユーザー主体ではなくプロジェクト主体になっています。ユーザーディレクトリ配下にブランチを作ることも可能なのですが、それだとマージリクエストなどの管理ができないので、本当に他人に使ってもらいたいならまずプロジェクトを作るところから始めないといけなくて面倒です。 その他にも、 Ubuntu の開発には Launchpad の機能が必要なんだろうけど、個人ユーザーには github の機能のほうが魅力的という場面がよくあります。 Launchpad で満足していたとしても、 github で開発され
TiDDとgit-flowを合わせた開発手法について | Technology-Gym
Redmineを使ったTiDD（チケット駆動開発）と バージョン管理システムのGitを組み合わせて、どうやって開発していくのが上手い流れを作れるのかということを考えてみました。 まずはTiDDとは何か 気になるところを取り出すと コードに触る前にチケットを切る Ticket First タスクチケットは細分化して、放置されるようなタスクのサイズにしない チケットで親子関係を作ってまとめるといい 親チケット = ストーリーカード 子チケット = タスクカード コードとチケットを関係付ける(コミットコメントにチケット番号の付加など) No Ticket, No Commit katsumic.info – WorkNote » TiDD（チケット駆動開発）でいこう と大体同じです。 次はGitとチケットについて 元々、RedmineのチケットとGitをどう連携させるのがいいのだろう? というと
GitHubでgitflowを使う - maoeのブログ
gitflowが便利で気に入っています。人のプロジェクトをforkしたときは、どういう流れで使えばいいのかまとめている文書が見つからなかったので書いておきます。 プロジェクトをfork 手元にclone upstreamの登録など git flow init git flow feature start XXXX いい感じに編集 git commit git flow feature publish XXXX GitHubのSwitch branchesからXXXXを選択 Pull requestボタンを押してリクエスト送信 レビューされる 取り込まれたらgit flow feature finish XXXX 僕は先日featureブランチをfinishしてからpull requestを送ってしまいまったんですが、GitHubのヘルプにはpull requestはトピックブランチからやれ
githubにpushしたcommitの取り消し - 七誌の開発日記
githubにpushしてからcommitが間違っていたことに気付きました。以下のようにすると取り消すことができます。 【注意】commitだけでなく変更も失われます。ローカルのソースツリーは残された最後のcommitに戻されます。変更を保存したい場合は使わないでください。コミットログの修正には git commit --amend を使用してください。 git rebase -i HEAD~2 ← エディタが開くので二行目を削除して保存する git push origin +master以下を参考にしました。 How can I remove a commit on github? id:okmount:20091021 古いコミットを書き換える： 歴史修正主義者のための git rebase -i 入門 githubだけ githubだけを取り消すには別の方法もあります。ローカルは同期
A successful Git branching modelとgit flow
参考： 見えないチカラ: A successful Git branching model を翻訳しました A successful Git branching modelの初期設定をする – tanihitoの日記 空のリモートリポジトリがあり、そこにmasterとdevelopブランチを作成し、 それをcloneしてgit flowを使用しながら開発する １．git flowの導入 https://github.com/nvie/gitflow からソースをダウンロード、コンパイル・インストール $ git clone https://github.com/nvie/gitflow.git $ cd gitflow $ sudo make install (インストール先を指定する場合はmake prefix=インストール先 install) ２．初期設定 リモートリポジトリからクロー
Germán Laullón Padilla on about.me
Germán Laullón PadillaSoftware Engineer in Madrid, Spain I am a software engineer currently living in Madrid, Spain. My interests range from photography to technology. I am also interested in programming, innovation, and video games. You can click the button above to view my portfolio. If you’d like to get in touch, feel free to say hello through any of the social links below.
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-flow によるブランチの管理
今回は分散バージョン管理システムgitと共に用いる「ブランチモデル」について紹介していただきます。gitを使ってみて、その高機能さをどう使えば良いか悩まれた方は、ぜひ本稿をご一読ください。gitそのものの使い方については解説していませんので、その際には『 実用git 』などの書籍を参考にしてください。 git-flow は Vincent Driessen 氏によって書かれた A successful Git branching model (O-Show 氏による日本語訳) というブランチモデルを補助するための git 拡張です。 git-flow を利用する前には、まずこの文章を一読することをおすすめします。 その骨子については、 Voluntas 氏のブログ が参考になります。 git を使うメリットの 1 つは、そのブランチモデルです。しかし gitを使っていると、その高い柔軟性か
【派閥別】Gitのコミットを間違えたときの対処法まとめ - 本当は怖いHPC
追記：たくさんブクマしていただいて驚いております。ブクマコメントだと、やはり git push -f は反則だろという意見がサイレントマジョリティのようですが、そこはそれ、自 己 責 任 追記２(2011/11/07)：commit messageをミスった場合について訂正しました。 git rebase -i で直近のコミットを "edit" にして修正すると、 「--amend使えや」と言われるようです。 gitのコミットをしくじった時の対処法について、一覧性の高いまとめがなかったので作りました。正確さは保証できないので、コマンド名ヒントに自分でググって下さい ほかのやり方があるよ、間違ってるよ等のご指摘歓迎です。 派閥別 gitでコミットミスった時のまとめ ｜ ├─ 一人で使ってるよ ｜ ｜ ｜ ├─ 手元に変更を取り戻したいよ(1)（そうだね、add忘れだね派） ｜ ｜
[git] 削除されたremoteブランチがローカルRepoで消えなくなったとき - satoko's blog - s21g
1 $ git push origin local_deploy #間違って作成 2 $ git branch -a 3 * master 4 origin/HEAD 5 origin/deploy 6 origin/local_deploy #ローカルにも反映されている 7 origin/master これでサーバ側は反映されました。 別のローカルリポジトリ(cloned)で削除が反映されない しかしもう一つ別のディレクトリで同じgitリポジトリをcloneしていて、そちらで削除が反映されない状況に。 下記の1.の説明にあるように、(remoteブランチの追加は自動でされるが)削除されたものはローカルで明示的に削除しないといけないようです。 Delete unneeded branch $ git clone git://git.kernel.org/.../git.git
#pyfes で git-daily について話してきました - 肉とビールとパンケーキ by @sotarok
git-daily について #pyfes で話してきました。 git-daily: git-daily #pyfes: Python Developers Festa 2011.10 を開催します - Twisted Mind Webアプリケーション開発におけるGitのブランチ運用戦略についての話です。 パッケージものの開発などと大きく異なるのはやはりリリース頻度や、リリース環境です。デプロイサーバが登場するとかもそういうことですね *1 ちなみにこのへんの、概要的な話は、GREEのころエンジニアブログにも書きましたので、そちらを参照ください。 Git で日々の共同作業やリリース作業をサポートする git-daily を作りました | GREE Engineers' Blog 発表資料 SpeakerDeck におきました (はてなに埋め込めるようにならないかなー) git-daily:
bashでgitとmercurialを使いやすくする - YAMAGUCHI::weblog
はじめに こんにちは、Python界の渡辺篤史です。@nkjm宅にて記事を書いています。 （git-core 1.7.12以降で設定が変わるので、最新版を使う場合は最後の方を参照して下さい） プロンプトにブランチ名を表示させよう 今のbashプロンプト 僕はzshを使おうと思いつつzshのdotファイルがどれに何を書けばいいのかわかりません状態が続いてずっとbashを使っています。いまのプロンプトはどこでも同じ色で表示されるように次のようなものを使っています。 PS1="\[\033[0;37m\][\[\033[0;32m\]\t \[\033[1;36m\]\u\[\033[0;37m\]@\h \[\033[0;32m\]\w\[\033[0;37m\ ]]\n\$ "こんな感じで表示されます。 gitのブランチ名の取得 MacPortsでgitをインストールしていて、bash_co
Bitbucket now rocks Git - Bitbucket
You’ve been asking for it, we’ve even joked about it – now it’s here (for real): for the one year anniversary of Bitbucket joining Atlassian, we are happy to announce Git support. All your source, all in one-place Whether you are using Hg or Git, you can now keep all of your code in one place with your preferred DVCS format. If you have existing code you would like to migrate, you can easily impor
Git管理の神ツール「Gitolite」なら、ここまでできる！
「Git」使ってますか？ 近年、分散バージョン管理システム「Git」が急速にシェアを伸ばしています。筆者は、チケットシステムやバージョン管理の勉強会などを開催したりしていますが、Gitユーザーがかなり増えてきていると感じます。 しかしながら、そのような勉強会でアンケートを取ってみると、実案件では半分以上の人がSubversionを利用しており、Gitの導入はまだまだ進んでいません。移行コストが掛かったり、プロジェクトマネージャ層への知名度がまだまだ低いというのもありますが、理由の1つとして、ユーザー管理が煩雑であったり、アクセス制御に関する情報が不足しているということもあると思います。 そういうわけで本稿では、Gitリポジトリのユーザー管理やアクセス制御を簡単に行う「Gitolite」を紹介します。 なお、本稿ではGitの利用方法については紹介しませんので、Git自身の使い方については改め
gitでアレを元に戻す108の方法 | Webシステム開発／教育ソリューションのタイムインターメディア
以前gitで一度行った変更をなかったことにする方法4つを紹介しましたが、 日常的に git を使用していると他にも様々な 「なかったことにしたい」「元に戻したい」 という状況に遭遇します。 そのひとつひとつについて対処方法を紹介していきます。 目次 問題1: ライブラリの新機能を試すためにあれこれ適当なコードを書いてみた。でももう要らない。問題2: トピックブランチをマージしたけど実はまだ不完全だった。マージをやり直したい。問題3: リリース後に発覚したバグ。原因は30日前に自分が行ったコミットだった。なかったことにしたい。問題4: 新しいコミットしようとして間違えてgit commit –amendで書き換えてしまった。元に戻したい。問題5: 色々作業していたら作業ディレクトリの内容が混沌としてきた。一度綺麗な状態にしたい。問題6: 作業ディレクトリにゴミファイルが溜まってきた。一度綺麗
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://mochizblog.heroku.com/23