納品を行った後、修正依頼が来て修正対応後 納品する際に「差分ファイルと差分情報が欲しい」と言われることも多々あると思います。 この場合に手動でチマチマやっていると時間がかかりますが、Gitだと簡単に情報がまとめられるとのことなのでそれらの情報をメモしてみます。 やりたいことの流れ 初回納品 納品バージョンのタグを付ける 全てのファイルをZIPにする 修正依頼が来てファイルを修正する 修正バージョンのタグを付ける 差分ファイルをZIPにする 差分情報をメモする 初回納品/全てのファイルをZIPにする まずは納品したいブランチでタグを付ける。納品用ブランチを作っておくとよいと思う。 例としてtag名はv1.0 注釈付きタグ名付与

案件で「作業の差分を納品してくれ」とか言われることってよくあります。 今までは手作業でディレクトリ作って、ファイルをコピーしてましたが、 もう、そんなうんざりする作業とはおさらばできそうです。 git archive と git diff の合わせ技で差分を出力できる事がわかったからです。 例えば、一個前のコミットから現在のコミットまでの差分を取り出したい時は、 git archive --format=zip --prefix=root/ HEAD `git diff --diff-filter=d --name-only HEAD^ HEAD` -o archive.zip まずは、git archive について。 --format=zip を付けるとzipで固めてくれます。 --prefix=root/ は抽出したファイルをrootディレクトリに入れた状態にしてくれます。 -o a

2014-05-17 JenkinsでFTPサーバーにデプロイする方法 Jenkins 開発環境 普段は Git に Push すると自動でデプロイサーバーに公開されるシステムを利用して開発をしています。すべての案件をこのシステム上で開発できれば快適なのですが、クライアントのサーバーで開発しなければならないケースも多々あります。そしてそのサーバーはFTPかSFTPによるパスワード認証方式のサーバーだったりします（いわゆる heteml とか普通の共用サーバー）。 自分はかなりのものぐさな性格なので、昔ながらのFTPクライアントソフトを使って手動でサーバーにアップロードする方法があまり好きではありません。アップロード漏れも頻発します。ここのアップロード作業を Jenkins に任せることはできないかと考えました。 SCP とか rsync とか使うのかなあ、と当初思ってましたが、Jenkin

あるときgit diffでコードの差分を見ているとき 変更箇所の改行に「M」とついているのを発見した。 これは気持ち悪い。 最初に疑ったのはテキストエディタ Sublime Text 2 を使っているのだけど、最近設定をいじった覚えはない。 ※ちなみに設定はLFになっている 規約通りにしているのになぜ。。。 調べた結果 前に 【git】aliasを使ってコマンドを短くする - 旅するえんじにあ - Engineers to travel - で記述した [color] diff = auto status = auto branch = auto ここのdiff = autoが悪さをしているとのこと。 対応策としてwhitespaceに行末のキャリッジリターンを許容すると解決できるようです。 ということで コマンドからの場合は git config --global core.whites

追記(2014/05/25) 調べた情報が古かったみたいで、GitLabも今は1〜5分でインストールできるらしい。 GitBucketがとても手軽なのは変わらないけど、GitLabのほうが高機能ではある。 GitHubクローンのGitLabを５分でインストールした - アルパカDiary GitHubクローンのGitLabを1分で使えるようにする - Webtech Walker 開発用Gitサーバが先日の社内インフラダウンで巻き添えになって､ 業務にむっちゃ影響が出た｡ で､これを機にクラウド上にGitを移行しようと､ GitHubやらBitBucketやら調べてたんだけど､ どうもうちの会社の運用のままだと､ リポジトリ数やユーザ数が多くて結構なお値段が掛かりそうなことがわかった｡ 業務上全部プライベートリポジトリにしないといけないし､欲を言えばユーザもリポジトリも数制限かけられたくな

前回 git diff を図に書いてみたところ、自分の中で意外と整理できたので、これまたなんとなく使っていた git reset についてもまとめてみた。 とりあえず結論を先にまとめよう。 git reset とは？ HEAD の位置を変更するコマンド。 オプションによってインデックス、ワーキングツリーの内容も変更できる。 git reset のオプションは？ --soft、--mixed(オプションなしと同等)、--hard オプションがあり、影響度の小さい順に以下のようになる。 --soft HEAD の位置のみを変更する。インデックス、ワーキングツリーには影響なし。 --mixed (またはオプションなし) HEAD の位置とインデックスを変更する。ワーキングツリーには影響なし。 --hard HEADの位置、インデックス、ワーキングツリーをすべて変更する。 さて、git reset

はじめに リポジトリを共有モードにするのを忘れていてトラブったので、解決した際の方法を紹介します。 今回は、 ssh経由でアクセスことが前提です。 http/https を利用する場合は別途手順がありますので、機会があれば後日紹介します。 解決方法 まず、 Git リポジトリをチームで共有する際には、 --shared オプションを付与し、リポジトリを初期化します。次に、チームのメンバーの umask を 002 もしくは 007 に変更します。 手順さえ間違えなければ、リポジトリの共有は簡単です。 --shared を忘れた場合はどうなるのかというと、正しく共有できる状態となっていないため、Permission denied が発生します。 この状態は、次の手順で解消できます。 $ cd /your/git/repository $ git config core.sharedRepos

システム開発を行う上でバージョン管理の必要性はもはや言うまでもないだろう。数年前であればSubversionが主流だったが、最近ではGitが利用されることも増えている。が、Gitにはちょうどいいフロントエンドがなかった。Subversionには有名なTortoiseSVNがあるというのに。 エクスプローラにGit！ このフロントエンドの存在がSubversionの普及に一役も二役も買ったのは間違いない。だがWindowsにもついに実用的なフロントエンドが登場した。 今回紹介するオープンソース・ソフトウェアはGit Extensions、エクスプローラとも統合されるGitフロントエンドだ。 Git Extensionsは管理インタフェースであるGit Extensions、msysGit、KDiffなどを一括でインストールするソフトウェアだ。新しいリポジトリの作成や既存リポジトリのクローンは

例えばgit-resetなどをする時などにHEADの2世代前のコミットにHEADを移す場合は HEAD^^としたりHEAD~2としたり。でもHEAD^2という指定もあります。そのへんのまとめ 題材としてアイドルマスターシンデレラガールズ(以下モバマス)で考えます。 まず、適当にリモートリポジトリを作った後git-cloneして最初のgit-commitを行います。 その後、運営の犬であるちひろさんを追加します。ここまでは共通作業ですのでm@sterブランチで行います モバマスはキュート、クール、パッションの3属性があるので3属性分のブランチを作ります。 次に、いわゆる2コスと呼ばれている各属性のコスト2アイドルを追加していきましょう。 キュート:島村卯月 クール:渋谷凛 パッション:本多未央 キュートブランチ $ git co master $ git co -b cute 島村卯月はノー

復習 Git: GitHub のブランチを削除する． 手が滑って test-2 なんて情けない名前のブランチを GitHub に push してしまった． とりあえず，ローカルの test-2 ブランチは， $ git branch -D test-2 で消えた．あとは GitHub の test-2 ブランチを消すだけだ． GitHub でブランチを削除するボタンを探してみたのだが，．．． 見つからない．どうしよう． git push でリモートのブランチを更新git push はリモートリポジトリに変更を反映させるときによく使うコマンドだ． 通常は， $ git push だけでコマンドを実行するが，これは， $ git push プッシュ先リポジトリ ローカルのブランチ名:リモートのブランチ名 を省略した形だ．git push とだけ実行したときのデフォルト値は， $ git pus

『リポジトリ作成した時点で余分なファイルもコミットしてたよ。』 『まぁいいよね、みんな余分なファイルごと持っていくといいよ！』 良くないよ。 胸張っているけど全然良くないよ。さっさと削除してください。 では.gitignoreではなくリポジトリに対してrmコマンドで対象のファイルを削除しましょう。 >> git rm hoge.txtディレクトリ配下ごと削除したい場合は-rオプションを指定します。 >> git rm -r hoge/bin/リポジトリから削除したら監視対象から外すように忘れずに.gitignoreへ追記しておこう なお、上記のコマンドだとワーキングディレクトリからも削除してしまいますが、 リポジトリには含めたくないだけでローカルには残しておきたい場合は--cachedオプションを指定します。 >> git rm --cached hoge.txt

gitignore-boilerplates（長いので以後giboと呼びます）という便利なツールを紹介します。これは.gitignoreのひな形を作ってくれるものです。 https://github.com/simonwhitaker/gitignore-boilerplates もう少し詳しく説明すると、giboは様々なOS・エディタ・言語・フレームワークなどに特化したファイルの情報を利用して、複数環境を考慮した.gitignoreを作ってくれます。 .gitignoreに入れたいファイルは環境ごとに変わってくるわけですが、各人がcommitしたくないファイルの存在に気づくたびにチマチマ.gitignoreに追記していくのって本当に無駄だと思うんですよね。giboはそれを自動化してくれるというわけです。 例えば、WindowsとMacOSXの2環境、Emacsとvimの2エディタを使う人

世間的に「Gitはコミットログを書き換えられてキモい」と言われ、肩身が狭いので git-rebase の説明を書いてみた。 git help から引用 まずは基本に忠実に、ヘルプを読みましょう。 git help rebase SYNOPSIS git rebase [-i | --interactive] [options] [--onto <newbase>] <upstream> [<branch>] git rebase [-i | --interactive] [options] --onto <newbase> --root [<branch>] git rebase --continue | --skip | --abort DESCRIPTION If <branch> is specified, git rebase will perform an automatic g

「マージがなんとなく怖い」「リベースするなって怒られて怖い」「エラーが出て怖い」 Git 入門者にありがちな「Git 怖い」を解消するため、Git のお仕事（コミット、ブランチ、マージ、リベース）について解説します。Read less

ようこそ、サル先生のGit入門へ。 Gitをつかってバージョン管理ができるようになるために一緒に勉強していきましょう！ コースは4つ。Git初心者の方は「入門編」からどうぞ。Gitを使った事がある方は「発展編」がおすすめです。さらに「プルリクエスト編」では、コードレビューする文化をチームに根付かせましょう。 「あれ？何だっけ…？」という時は「逆引きGit」で調べて見てくださいね。