memo. 以前にちょっと調べたときに git submodule は癖がすごいようだったので後回しにしていました。
Summary GitHubでFork/cloneしたリポジトリに追従する備忘録 Fork元のリポジトリを指定 $ git remote add upstream https://github.com/caskroom/homebrew-cask.git Fork元のリポジトリを追従してoriginにpush $ git checkout master $ git pull upstream master $ git push origin master $ git checkout my_branch $ git rebase master $ git push origin my_branch -f Reference GitHubでFork/cloneしたリポジトリを本家リポジトリに追従する - Qiita http://qiita.com/xtetsuji/items/555a1e
2015年 1月 13日 Emacsのgitクライアントであるmagitの操作を画像を使って解説。 ここではローカルレポジトリで過去に遡ったcommit messageの再編集をします。結果的にはgitコマンドのrebaseを使った書き換えと同じです。 画像は上のバッファでM-x magit-statusをしたところです。 magit statusバッファで"ll”(アルファベットlを2回)を押すと上のようなcommitのlogが表示されます。 ここで、commit message "commit 4” へカーソルを持って行き、”E”を押します。 commit message "commit 4”以降のcommitの予定を設定する画面になりました。 変更したいcommit messageの上で”r”を押してrewordのマークを付けます。 古い方から2つをpickからrewordに変えまし
B! 42 0 0 0 vim-markdownをアップデート で vim-markdown をアップデートした、という話をしましたが、 このレポジトリはもともとForkしたもので、元のレポジトリの変化を追いつつ アップデートしたので(というか今回は元のレポジトリのアップデートをマージしただけ) その流れについてまとめておきます。 レポジトリ設定 Fork元のレポジトリにつなげる 元のレポジトリのアップデートをmasterにpull modをmaster(=Fork元の最新版)にrebase mergetoolでマージ originにpush 操作の取り消し等 ファイルの変更の取り消し commitの取り消し commitのやり直し rebaseを取り消す pushの取り消し レポジトリ設定 plasticboy/vim-markdown というレポジトリをForkして rcmdnk/vi
Git の diff を美しく表示するために必要なたった 1 つの設定 #git にインスパイアされて作り始めた diff-highlight にあれこれ手を入れ、1.0.0 として正式リリースしました。 diff-highlight と git-contrib/diff-highlight の違い 差分の中で +/- の行数が一致していないときのハイライトの扱い git-contrib/diff-highlight での表示 +/- の行が一致していないとハイライトされません。 diff-highlight では、マッチする行を認識してハイライトします。 +/- の行数が一致しても、文字単位でのハイライトをしてくれないケースがある git-contrib/diff-highlight での表示 差分の 1行目同士を比較しているため、pager の行がハイライトされていません。 diff-
新しい職場に入ってこちら、大量のサーバーを管理するための環境を構築することに精をだしています。 サーバーの管理のためにWindowsでいろいろなツールを使ってみた結果、VirtualBoxでLinuxを動かして使う方法がいい感じになってきたので書き残しておきます。 こんな過去を持つ人におすすめ ローカルでもLinuxコマンドに慣れよう!と思ってCygwinを入れたが結局使っていない サーバー上のエディタと操作感を統一しよう!と思ってgVimを入れたが結局sakuraエディタを使っている Git使えるエンジニアかっこいい!使ってみたい!と思ってGoogleに「Git Windows」と打ち込んだが、検索結果をしばらく眺めたあとそっと閉じた Ruby/Pythonかっこいい!使ってみたい!と思ってGoogleに、以下省略 サーバーごとにSSH、Puttyの設定も正直しんどい ※わたしです スク
アニメ化決定! すべての Vim プラグインマネージャーは道を譲れ!!!!!! #editorwar#vim 2012年 04月 01日 kana 問題 一旦Vimがメキメキと使えるようになるとプラグインもバリバリと導入したくなります。 最初は数個のプラグインを試しに使っているだけだったのが、 時を経るにつれて数多のプラグインを使うようになってくるものです。 こうなると問題になるのはプラグインの管理です。 数が増えてくると新しいものをインストールするのもインストール済みのものを新しいバージョンに更新するのも億劫になります。 そこで必要になるのが Vim プラグインを管理するためのツールです。 この手のツールは2008年8月に公開された vim-pathogen が最古だと思われますが、 とりわけ民衆に認知され始めたのは YAPC::Asia 2009 で発表 された Vimana からだと
社内向けに「こわくない 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」を初めて読んだ時、いきなり 第二章から Git の構造の説明を始めてしまう構成に「Git<の使い方>入門」じゃなくて「Git<の作り方>入門」でしたかーっ(さすがメンテナですね)、、と思ったことを覚えています。 入門Git 作者: 濱野純(Junio C Hamano)出版社/メーカー: 秀和システム発売日: 2009/09/24メディア: 単行本購入: 31人 クリック: 736回この商品を含むブログ (155件) を見る それは結構楽しい体験で、それまで全く思っても見なかった「Git作ってみたいな」という うずうずとした衝動がわたしに芽生えるきっかけでした。それ程に Git の設計はシンプルで 手に終えそうで、それでいて「うまくいく仕組み」が備わっている、興味深いものだったのです。まさにハックと呼ぶにふさわしいそれは、VCS全般に抱いていた「しっかり綿密に作りこ
最近はテキスト編集をするときにはちょこちょこVimを使っている。 その際、Vimを使いながら少し前から設定ファイルをいじり始めたが、WindowsとMacとで別のファイルを利用して編集していたため、別マシンで設定した値を他の環境で反映できていなこともよくあった。 そのため今回、Githubを使ってWindowsとMacとで設定ファイル(vimrcとgvimrc)を同期させようと、以下のエントリを参考にチャレンジしてみた。 そろそろしっかりvimを使う。dotfilesのgithub管理とvundleの導入。 - 南極の図書館 そろそろしっかりvimを使う。github+vundleを利用したWindowsとの同期。 - 南極の図書館 このとき若干つまづいたことがあったので、備忘録も兼ねてメモ。 Vundleを導入した際の.gitmodulesファイル 上記エントリのように、今回Github
github pagesとJekyllを使って個人サイト構築してみました。今ご覧のこのページがまさにそうです。 はじめに git + markdown でのサイト管理が便利そうなので、ホスティングまでできるgithub pagesを使ってみました。 ちなみにOctopress, Jekyll bootstrapを使えばもっと簡単に設置できるとみたいです(後で知った)。 [username].github.com の取得 まずは github pages のユーザーページをセットアップ。 Github の Create a New Repo へ。 Repository name に [username].github.com と入力。[username]は自分のIDです。 “username = 自分のユーザID” でない場合はドメインのルートにならず、パスを切るようです。 例えば akku
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
2013-07-14 git push 前に自動でテストを回そう git git push する前にテストを回しわすれ、 pull request が CI にはねられて悲しい思いをすることが多かったので、忘れないように自動化した。 git には pre-push hook が 1.8.2 から導入された。 以前 temporary なコミットが含まれる場合、push をやめるというのを作ってとても重宝した。 git-now したコミットの誤送信をふせぐ - tomykaira makes love with codes テストを回すのはチェックに時間がかかるけど、それで円滑な開発と綺麗なコミットグラフが促進されるなら、30秒ほどまつ価値はあると思う。 .git/hooks/pre-push の内容は次のような感じ。以前のに足したところから、関係なさそうなところを消したので、余計なものが混
0分―― 分散型バージョン管理システム「Git」とは ソフトウェア開発ではソースコードを作成しながらソフトウェアを作り上げていきますが、バグの修正や機能の追加ごとにソースコードの状態を記録し、それぞれのバージョンを管理することが必要になります。 そういったソースコードを管理するソフトウェアが「バージョン管理システム」であり、複数人でのソフトウェア開発において必要不可欠なソフトウェアとなっています。
ベーシックでは、Gitを使ったバージョン管理システムを導入しています。一部のプロジェクトでは先行して導入していたものの、全社的にはまだまだ…といったわけで、よくGitコマンドについて質問されるので、ここで軽くまとめておきたいと思います。 普段は git add / commit / push / pull しかしてない…っていう人向けです。 addしたファイルを取り消す $git reset HEAD ファイル名 更新内容自体は取り消さず、addしてインデックスに登録するのを取り消します。 更新したファイルの更新内容を取り消す $git checkout ファイル名 commitする前限定です。 他ブランチの特定のコミットだけマージしたい $git cherry-pick コミットID とても便利なコマンドですが、cherry-pickを多用するような運用スタイルになっていたら問題なので、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く