概要 例えば、webページを作っている「project A」「project B」があるとします。 全く別のプロジェクトですがCSSだけは同じものを使いたい。 どんどんアップデートしてCSSを充実させたい。 そして新しく「project C」を作るときもこのCSSを使いたい。 これを叶える仕組みがgitには標準で備わっています。 「subtree」という仕組みです。 上記の図の様にgitで管理している「project A」の中でまた別のgitリポジトリ「CSS」も管理しています。 「CSS」に機能を追加してCSSリポジトリにPUSHしたら「project B」でも機能追加したCSSを使うことができます。 もちろん逆も可能です。 参考サイト git subtreeの練習 - Weblog - Hail2u.net git subtree使ってみた - Qiita 上記のサイトにも書いてあるん
The Basics of a 401(k) Retirement Plan Understanding the Concept of a Gold IRA Key Advantages of Including Gold in Your Retirement Portfolio Exploring the Relationship Between 401(k)s and Gold Investing How to Move Your 401(k) to Gold Without a Penalty Avoiding Tax Penalties: Tips for 401k to Gold IRA Rollovers Differentiating Direct and Indirect Rollovers for a Gold 401k Pros of Moving Your 401(k
Gitのリポジトリの中で、いろいろ試してみたけど、結局は元の状態に戻したくなることがあって、その方法を調べたのでメモメモ。 まず最初に、リポジトリ内でaddをしてステージングエリアに追加したファイルがある場合は、それを元の状態に戻しておきます。 $ git reset HEAD 次に、元々リポジトリ内にあった（追跡していた）ファイルやディレクトリで、変更を加えたものを元の状態に戻します。 $ git checkout . 上記の2つの手順を一度に行いたい場合は、以下のコマンドで済ませることができます。 $ git reset --hard HEAD 最後に、元々リポジトリ内になかった（追跡していない）ファイルやディレクトリがある場合はそれを削除します。 $ git clean -fd これで元通りになったはず。
皆さん、tigコマンドを活用していますか？ tigは、コンソール上で使えるgitブラウザです。実はずっと、ただのきれいなgit logだと思っていたのですが、本当はそんなことはありません。かなり使えるやつなのです。 インストール ソースコード: https://github.com/jonas/tig インストール方法: https://github.com/jonas/tig/blob/master/INSTALL.adoc この辺りを参考にしてみてください。詳細は割愛します。 基本の使い方 この状態の差分を扱っていきます。いつものこれだとこんな感じ。 git logが素敵にビジュアライズされてます。この画面をmain viewといいます。 ここでエンターを押すと、下半分に差分の詳細（diff view）が表示されます。 下矢印で、Unstaged changesの差分を見てみるとこんな
最近ソース管理にGitを使うプロジェクトがかなり増えてきました。ソース管理はSVNで十分と思っているユーザもプロジェクトの方針としてGitになった場合、最低限の操作を覚えないと作業に支障をきたしてしまいます。その際にコマンドラインで操作しても良いのですが、今までSVNでSubversiveとかSubclipseなどを使ってきたEclipseユーザは、EclipseからGitを操作したいところです。 そこでEGitを使おうと思ってもEGit自体はそこそこ歴史がある割に意外と情報が少なくて困ってしまった人もいるのではないでしょうか？。 今回はプロジェクトで使うに当たって、最低限知っておけばどうにかなりそうな操作をまとめてみることにしました。構成としては利用者側としてGitを利用することを想定してみました。実際、作業して順番とは違うのでファイルに一部矛盾するところがありますが気にしないでください
SourceTree でフォースプッシュできないことだけ不便だなーと思ってたけど、Mac 版ではいつのまにか実装されてた件。 リリース日は 2013年9月18日 SourceTree for Mac 1.7 – Now Available! ・Force push supported as a checkbox if enabled from preferences 設定 デフォルトでは無効になってるので、環境設定＞全般の最下部付近の項目にチェックをいれる。 upstream に force push するのは暴挙なので、UI 的に正しいと思う。force push は自分専用のリポジトリ（フォークしたリポジトリ含む）に対してだけ行うべき。 プッシュのとき そうするとプッシュのタイミングでチェックボックスが現れる。 翻訳が変だけど。 （追記1） 2014-10-07 にリリースされた So
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
2014.02.07 ちょっと待った! Railsのgitリポジトリから Gemfile.lockとdb/schema.rbを除外してはいけない こんにちは、hachi8833です。 Railsをgitで管理するのであれば、ログファイルや、パスワード入りdatabase.ymlなどの登録したくないファイルを.gitignoreに記載してリポジトリから除外するのが普通です。しかし実際の案件では、除外すべきでないファイルが除外されていることがたまにあります。言うまでもないような話ですが、心当たりのある方は念のためチェックしてみましょう。 gitリポジトリから除外すべきでないファイル 以下では、誤ってgitリポジトリから除外されがちなGemfile.lockとdb/schema.rbについて説明します。代表的なものであり、すべてを網羅しているわけではないのでご注意ください。 Gemfile.lo
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? これは Git (や Subversion などのバージョン管理システム) にコミットする時により良いコミットメッセージを書くための提言です。この提言は特にメッセージの一行目だけを対象とします。せめて最も重要な一行目だけでも良いメッセージを書いて欲しいからです。提言をズバリ一言で表すと 一行目には要求仕様を書け です。 背景 プロジェクトによっていろいろ慣習の差はあるものの、一般的には「コミットメッセージの一行目は変更内容の要約を簡潔に書け」とされます。特に Git は、各コミットメッセージの一行目だけを取り出してそれを一覧表示するなど
2019/12/11 分かりやすいサイトへのリンクを追加しました hub コマンドの hub fork について追加しました 2013/04/11 興味深い手法があれば随時追加していきます ネットを検索すると、色々な手法が出てきますが、自分としては「WEB+DB PRESS plus 開発ツール徹底攻略」p.71 に載っていた以下の手法がシンプルで良く理解できました。 本家リモート upstream を追加する方法 本家リポジトリの例として、実際にGitHubに存在する練習用リポジトリ git@github.com:DQNEO/Renshu.git を使います あなた (youraccount) が既にForkしているRenshuリポジトリをcloneします。 $ git clone git@github.com:youraccount/Renshu.git Cloning into 'R
2013/10/16: Githubのhelp「Remove sensitive data」について追記 先日、初めて知ったのですが、GithubのプルリクをCloseは出来ても、削除は出来ない。(*1) 普段使う上では困らないのですが、パスワードなどの公開すべきでない情報がプルリクに含まれると、結構ヤバい事になる。 結論 結論を先に書くと「リポジトリを作り直すしかない」 試したこと プルリクしてるブランチを上書きする パスワードなどの情報をコミットから(rebase -iなどで)消してからブランチを上書きしてみた。 $ git push -f origin topic_branch プルリクに上書き前後の履歴が全て表示される... プルリクエストしたブランチを削除する 実はGithubでプルリク中のブランチを削除すると、自動的にプルリクがCloseになる。 Closeになるだけだった..
ここでは大変人気のある分散型バージョン管理システム Git でソースコードの管理を行う方法について説明します。 Git とはなにか？ とか、 Git の基本的なことについては Linux 入門 - Git を参考にしてください。 また Eclipse から Git を使うために EGit というプラグインを利用していますが、そのインストール方法も "Eclipse で使うプラグイン EGit - インストールと初期設定" を参考にしてください。 ここでは Eclipse に EGit がインストールされているものとして、説明します。 既存のプロジェクトからリポジトリを作成する 既存のプロジェクトからリポジトリを作成する場合は、 Team » Share Project... を選択します。 Git を選択します。 プロジェクトとパスを選択して、 Create Repository をクリッ
Git に同梱されている contrib/diff-highlight を使います。 あとは README に書いてあることの引き写しですが、PATH の通ったディレクトリに置いて、~/.gitconfig に以下のように設定を書く。 [pager] log = diff-highlight | less show = diff-highlight | less diff = diff-highlight | less すると、対応するコマンドの出力がこんな風になります。 行レベルの diff に加えて、単語レベルでの diff もハイライトされ、GitHub での diff のように描画されました。 組み込みのオプションで --color-words というのがありますが、こちらを使うと行レベルの diff 情報が失われるので、少し不便だったわけですね。とすべて README に書いてあ
１億行のファイルに１行追記するだけでレポジトリ容量が２倍になった 以前の記事「Gitレポジトリはパッチの集積ではなくてスナップショットの集積である。」を確認するために、１億行のファイルを作って実験してみました。 結果は、なんと１行追記しただけでレポジトリ容量が200MB増加し、サイズが２倍になりました。 実験手順 空のレポジトリを作る １億行のファイルを作ってgit addしてgit commit コミットする そのファイルに１行だけ追記してgit addして git commitする 空のレポジトリを作る $ git init １億行のファイルを作る １億行のファイル(１から1億までの数字が書かれたファイル)を作ります。 $ seq 1 100000000 > numbers.txt この時点で、ワーキングツリーとレポジトリ容量を調べてみます。 $ ls -lh 合計 848M -rw-
はじめに-時間をこえてメモした部分があるので繋がりは悪いかもしれません>
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
