Git は紛らわしいという評判です。用語や言い回しが意味するものと、そこから想像する挙動が違ってユーザーが混乱すると言われます。これは、git cherry-pick や git rebase のような「履歴を書き換える」コマンドに最も顕著です。私の経験では、この混乱の根本的な原因は、コミットは 差分 であり順番を入れ替えることができるという解釈にあります。しかし、コミットはスナップショットであって、差分ではありません! Git がリポジトリデータをどのように保存しているかを見てみると、Git を理解しやすくなります。このモデルを調べた後に、この新しい視点が git cherry-pick や git rebase のようなコマンドを理解するのにどのように役立つのかを探っていきます。 本当に深く 掘り下げたいのであれば、Pro Git という書籍の Git Internals の章を読むと
今回は、Windows PCをGitのリモートリポジトリとして使用する方法を紹介する。 Gitとは、プログラムのソースコードなどの変更履歴を記録・追跡するための分散型バージョン管理システムである。 故障率を抑えるため、通常はサーバマシンのLinux上に構築したGitをリモートリポジトリとして使用することが多いと思われる。 しかし、あるプロジェクトで機器調達の遅れから、ノートPCのWindows7上にGitを構築し、リモートリポジトリとして利用することとなった。 今回は、その時に調査した内容をまとめたものである。 注意 今回紹介する方法は、安全なLAN内にあり、かつLANにアクセスできる人間が悪意を持たないことを前提とした方法であり、最低限のセキュリティも確保されていない事を十分に留意して頂きたい。 <関連ソフトのバージョン> Gitサーバを構築するノートPCのOS：Windows 7 Ho
はじめに 会社や研究室でGitを使ったバージョン管理システムを構築したいというニーズが少なからずあると思います。言うまでもなく、ソースコードやそれに付随する書類を管理する上で、手作業でそれを行うのは非常に非効率だからです。 今回は、Linuxサーバを持っておらず、Windows OSの入ったパソコンしか使えない場合を想定して、Windows10パソコン上にGitサーバをたてる方法について説明します。 WindowsパソコンにGitサーバを立てることはまずやらないためか、ネット上での情報が少なく、公開されている情報も断片的だと感じたので、今回私なりにまとめてみることにしました。 実行環境 Gitサーバ (Windows10 Pro) Gitクライアント (Windows10 Pro) Gitのインストール（サーバ・クライアント共通） サーバ（Windows10）とクライアント側（Window
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 概要 みなさん、Git使ってますか？ もしくは、使いこなしていますか？ 独習Gitを読んで、思いの外Gitコマンドが多かったので、 タイトルの通り、Gitコマンドで100本ノックをまとめてみました。 Gitの環境構築が終わっている状態からを想定しています。 git initでローカルにリポジトリを用意してください。 問題に対して、直後に回答を載せる形式にしています。 Git初心者の方も、目を通して知らないオプションをググれば勉強になると思います。 参考文献 独習Git 100本ノック Gitに馴染む 1. メールアドレスをGitのグロー
ソースコードの変更管理ツールを使いこなすことはエンジニアにとって重要なスキルです。これまで、バージョン管理といえばSubversionがよく利用されていましたが、最近ではGitが人気を集めています。最新版のVisual StudioにおいてもGitが標準でサポートされるようになり、MicrosoftもASP.NETや.NET Core Frameworkの開発をGitHubで行っています。そこで本稿では、Visual StudioでGitを使用する方法についてチュートリアル形式で解説します。 クライアントツールとして「Visual Studio Express 2013」を、Gitのリモートリポジトリとして「Visual Studio Online」を使うことで、無料で簡単にGitの使い方を学ぶことができます。 Gitについて Git（ギット）とは、Linuxで有名なリーナス・トーバルズ氏
Git ローカルリポジトリを Visual Studio 2015 から Git リモートリポジトリにプッシュする方法メモ 流れ リモートリポジトリ作成 Visual Studio プロジェクトにリモートリポジトリ設定 プッシュ 前提・例として使うもの Visual Studio 2015 のプロジェクトはすでに Git ローカルリポジトリで管理しているものとする。 Git ローカルリポジトリ管理下にある Visual Studio プロジェクト名: Test Git リモートリポジトリ名: Test Git リモートリポジトリ作成 # cd /var/git # mkdir Test # cd Test # git --bare init --shared Initialized empty shared Git repository in /var/git/Test/ # cd ..
私はコミットログの書き方に悩む英語の苦手な人間である。実際、似たような人は世の中に結構いるようで、頻出単語を集計したりまとめたものは既にあって役に立つのだけれど、これらはあくまで単語の話であり、具体的な文を構成する過程でやっぱり困る部分がかなりあった。 要するに、どういう時にどういう文が使われているのか、ということを示した例文集が欲しいのである。ググると他にも「例文集があればいいのに」みたいな声はあるくせして、しかし誰も作ろうとしない。何なんだお前ら。それじゃ私が楽できないじゃないか。 仕方なく自分でまとめたので、増田に垂れ流しておく。 はじめにここで挙げているコミットログは全て実際のコミットログからの転載である。当然ながら各コミットログの著作権はそれぞれの書き手にある。いずれも各英文でググれば出てくるし、フェアユースの範囲なら許してくれるだろうと考え名前とプロジェクト名は割愛したが、ここ
前に社内チャットで流れてて初めて知った。 他人の変更を上書きするおそれのある git push --force でなく、最後に fetch したタイミング以降に他人が push していたら失敗する git push --force-with-lease を使う方が良い。 --force considered harmful; understanding git's --force-with-lease - Atlassian Developers Quipper では GitHub flow のような開発フローを採用している。 各開発者が feature branch を作成し、master / develop branch へ pull request を作る流れだ。 他人と修正箇所が重なってコンフリクトした際には rebase が必要で、 rebase 後の内容を push する際には
いままでなんとなく使ってきたけど、ようやく使い方が分かったような気がするのでメモ。 前提知識 インデックスとワーキングツリーが理解できていること HEAD が何か分かっていること git diff ワーキングツリーとインデックスの差分を表示。 git add した後にさらに修正したけど、そういえばどの時点で git add したのかなー、というときに使う？ git add したらすぐにコミットする自分には関係なさそう。 git diff --cached HEAD とインデックスの差分を表示。 git add して、コミットする前に差分を確認したい時に使うんだと思う。 自分は git diff よりもこっちの方をよく使う。 git diff HEAD HEAD とワーキングツリーの差分を表示。 前にコミットした時からどれくらい編集したか確認したい時に使う。 HEAD の部分はコミット(HE
git-merge の--ff, --no-ff, --squashの違いをまとめてみた。 git helpから引用 まずは、git helpを読みましょう git merge --helpから引用（抜粋） NAME git-merge - Join two or more development histories together SYNOPSIS git merge [-n] [--stat] [--no-commit] [--squash] [-s <strategy>] [-X <strategy-option>] [--[no-]rerere-autoupdate] [-m <msg>] <commit>... git merge <msg> HEAD <commit>... git merge --abort OPTIONS --ff, --no-ff Do not gene
Git(GitHub)おじさん 何かを布教することをネットの一部では「**おじさん」というみたいです。最近、あまり得意ではないのですが、色々な事情で仕事でソフトをつくることが多くなり、その関係で何周か遅れでGitとGitHubを使うようになりました。そして、今頃その素晴らしさに感動して打ち震えている（大げさ）ので、私もGit(GitHub)おじさんになってみようかと思います。 といっても、私が今更Git(GitHub)の何が素晴しいかを語ったところで…というのもあるのと、何よりうまく伝えられる気がしないです。何故ならそもそも自分がまだそんなにわかってないし使いこなせてない。なので、今回はGit(GitHub)を少し使ってどのようなことが変わった（良いことがあった）のかという具体例をGit使用前(Before Git)、Git使用後(After Git)として列挙した後、オススメのサイトをま
![Git(GitHub)おじさんに俺はなるBefore Git, After Git - karaage. [からあげ]](https://cdn-ak-scissors.b.st-hatena.com/image/square/296468c2cb54689350de2513c32be9f914a99613/height=288;version=1;width=512/https%3A%2F%2Fsiteproxy.ruqli.workers.dev%3A443%2Fhttps%2Fcdn.image.st-hatena.com%2Fimage%2Fscale%2F5be5fe7e227e8b4aae97613b55c06b01e0fb0464%2Fbackend%3Dimagemagick%3Bversion%3D1%3Bwidth%3D1300%2Fhttp%253A%252F%252Fecx.images-amazon.com%252Fimages%252FI%252F51PjpAUHZBL.jpg)
アッド & コミット 変更されたファイルを選択します。 git add <filename> git add * を実行するとIndexに追加されます。 これは基本的な作業の一つです。 変更を実際に適用するには git commit -m "Commit message" を実行します。 変更がHEADに入りましたが、 リモートリポジトリには未だ入っていません。 変更のプッシュ この時点で、変更がローカルリポジトリのHEADに適用されました。この変更をリモートリポジトリに適用するには git push origin master を実行し、masterの代わりに適用のブランチ名を入れます。 もし既存リポジトリをクローンせずに使用した場合 git remote add origin <server> を実行すると、リモートリポジトリを登録する事が可能です。 これで変更を特定なリモートリポジト
こんにちは、中川です。 Gitを使い始めてから、Subversionを使う機会がめっきり減ったこの頃です。 Gitだとローカルだけで簡単に使い始められるのもいいですが、気軽につくれるbranchや、mergeのしやすさがたまりませんね。 インストール直後の状態でも普通に利用できますが、 ちょっとした設定でさらに使いやすくなる方法をご紹介したいと思います。 ※今回ご紹介する内容はいずれも私のMacBook上での動作確認となり、Windows環境は考慮していませんがご容赦ください。 ■ユーザー名とE-mailアドレスの設定 まずは、最初にユーザ名と、メールアドレスを設定してしまいましょう。 $ git config --global user.name "yoshiki" $ git config --global user.email "[email protected]"
[2016/12/19追記]「「MBAでスクリプトを書き、リモートサーバ上で実行する」をGitで実現する - Qiita」を公開しました。ここと同じ仕組みでWordpressでなくRubyスクリプトを管理する方法です。 「ベアリポジトリとノンベアリポジトリ：理論編〜GitでWordpressのテーマを管理」の続き、実践編です。 本番環境にいきなりやるのは怖すぎるので、以下の様な環境を作ってやってみます。 リモートサーバ上のGit（bare）「更新管理用Git」 172.16.151.129:~/test.remote.git/ リモートサーバ上のGit（non-bare）「本番環境Git」 172.16.151.129:~/test.local.git/ ローカルマシンのVirtualBox上のGit（non-bare）「テスト環境Git」 192.168.56.101:~/work.lo
[2016/12/19追記]「「MBAでスクリプトを書き、リモートサーバ上で実行する」をGitで実現する - Qiita」を公開しました。ここと同じ仕組みでWordpressでなくRubyスクリプトを管理する方法です。 早く公開したかったのに思いのほかハマってちょー頑張った@nekotricolorです。 「バージョン管理システムとは何か〜GitとSubversionの違い」からの「VirtualBox上にインストールしたUbuntuにSSHで接続する」の続きです。 この記事には理屈しか書いていませんので、実際の設定は「ベアリポジトリとノンベアリポジトリ：実践編〜GitでWordpressのテーマを管理」を参照ください。 お題：「Gitを使って、本番環境のWordpressのテーマを、複数のPC上にあるローカルのテスト環境で確認してから更新できるようにする」 ノンベア（non-bare）リ
gitによるバージョン管理 バージョン管理システムはつかってますか？ 僕は前に自分の作成したコードを元に、後輩にプログラムを作らせようとしてまずは僕のコードをコピペしろと指示したところ、コピペしかしてない(と言い張る)割にはコピペしたコードは動かず、さらに何故かコピペ元の僕のコードが滅茶苦茶に荒らされて当然のごとく動かなくなるという、なんかもう幽霊の存在を認めない限り説明がつかないような怪奇現象に遭遇したことがあります。しかもそのときはcpコマンドによるバックアップに頼っていて運悪くバックアップを忘れたために僕の貴重な１日が消え去ってしまった訳でして、それから僕はバージョン管理システムに頼ることを固く心に決めました。また僕はその目を覆いたくなるような残虐な事件以来、建設業界に見習って、IT業界でもプロジェクトキックオフ時にお祓いはすべきだと訴え続けています。 まぁそれはいいとして、いやまだ
git先日、msysGit（Git for Windows）がいよいよ公式に UTF-8 をサポート！ という記事で「UTF-8 対応のコードがコミットされた」ことをお伝えしましたが、ついに、UTF-8 対応の新バージョン、msysGit 1.7.10 がリリースされました。いよいよ Windows でも日本語ファイル名を扱えるようになったので、「git では "詳細設計所仕様書.xlsx" をコミットできないんでしょ？」とブーブーいってた人を説得できる材料はそろいました!!!!それを記念して、この記事では UTF-8 対応の msysGit 1.7.10 を試してみた ブーブーいう人を黙らせるための「GUI で git する Windows 向けツール」まとめの2本立てでお送りしたいと思います。UTF-8 対応の msysGit 1.7.10 を試してみたさっそく Google Code
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Gistで書いたコードを行番号つきでBloggerに埋め込む
