Create useful .gitignore files for your project by selecting from 571 Operating System, IDE, and Programming Language .gitignore templates
git commit --fixup というオプションの存在を最近知って調べた。 ヘルプとリリースノートより "git commit" learned the --fixup and --squash options to help later invocation of interactive rebase. Git v1.7.4 Release Notes --fixup=<commit> Construct a commit message for use with rebase --autosquash. The commit message will be the subject line from the specified commit with a prefix of "fixup! ". See git-rebase(1) for details. 1.7.4 から入って
Steins;GitはSteins;Gateを用いてGitを解説する薄い本です。 Steins;GitはSteins;Gateの二次創作物です。そのため貢献をする前に次に挙げるページを読み、これらに遵守した形で貢献をしていただけるようお願いします。 著作物転載ガイドライン|ニトロプラスNitroplus 二次創作活動における同人誌等の活動に関する取り扱いについて|ニトロプラスNitroplus Steins;Gitの執筆方針について Steins;Gitは「Gitの使い方を、Steins;Gateの世界観を使って説明する」書籍です。「Steins;Gateのストーリーの流れに沿って、Gitの説明をする」書籍ではありません。 簡潔に書くと「シュタゲ本」というよりは「技術書」よりです。とはいえ、なるべくSteins;Gateを絡めていきたいですし、全体の雰囲気もSteins;Gateっぽくした
「Upsource 1.0」は、VCSレポジトリ全体を閲覧可能で、社内のレポジトリとGitHubのような外部レポジトリを同様に扱える。 コードレビューツールとしては、リビジョンの判別やインラインまたは横に並べての比較、最近のコミット/ブランチ/マージの追跡、プロジェクトで何が行われてきたかを確認する機能を搭載する。また、現在作業中のコードや、もっとも最近に作業を行ったコードにすばやくアクセスでき、文字列のハイライト機能や、コード/ファイル/テキスト検索機能によって、プロジェクト全体を把握しやすくしている。 このほか、チームメイトと議論しながらコードの編集が可能で、リビジョン単位またはブランチ単位でのコードレビューの作成や、チーム全体での重要なコードベースの変更の共有ができる。さらに、リビジョン/ブランチ/コードレビュー/差分/議論/レポート/検索フィルタ/ファイルなど、コードのあらゆる箇所
ghqというレポジトリ管理ツールを使ってみた。 Installation Goがインストールされていてかつ環境変数$GOPATHが設定されている環境で、go getを使ってインストールできた。 手元の環境を調べてみると、Goのversionは1.2.1、環境変数$GOPATHは$HOME/.goに設定されていた。 $ go get github.com/motemen/ghq $ go version go version go1.2.1 darwin/amd64 $ echo $GOPATH /Users/r7kamura/.go $ cat /Users/r7kamura/.zshrc.local | grep GO export GOPATH=$HOME/.go export PATH=$PATH:$GOPATH/bin $ which ghq /Users/r7kamura/.go
pecoというインタラクティブに入力をフィルタして出力するコマンドがあって、使い始めてからシェルの操作方法が大幅にかわり、だいぶライフチェンジングだった。 最近このへんが流行ってるのでやたら記事あるけど、せっかくなので僕も使い道を紹介しようと思う。 pecoをzshで使う 1. peco ghq ghqを使ったローカルリポジトリの統一的・効率的な管理についてのこと。 僕も$GOPATHは$HOMEにしていて、今のところ別に困ることはない。 go getしたりghq getしたりして美しくディレクトリ切った上で、pecoに割り当てておいたC-sですぐ目的のディレクトリ開けるようにしてあるので、めちゃくちゃソース管理が楽になった。 function peco-src() { local selected_dir=$(ghq list | peco --query "$LBUFFER") if
GitHubの2段階認証を有効にしたところ、httpsなURLのリモート・リポジトリへのpushが弾かれるようになった。ちゃんと記事読んだらトークンで認証させろと書いてあった……。指示に従ってアカウント設定のApplicationsからPersonal Access Tokenを発行し、パスワードの代わりにそれを使うようにしたところ、httpsでも元通り自動認証でpushできるようになったようだ。 "GitHub 2段階認証 https"で検索して見つかるGithubの2段階認証を有効にしてgitからの認証が弾かれる時の話には「毎回トークンを入力する必要があります」と書いてあるが、credential.helperを設定しているならそんなことはない。単純に今までのパスワードの代わりに発行したトークンを入力して、ヘルパー・アプリケーションに覚えさせれば二度と聞かれなくなる。 credenti
最近、HTML,CSS,JavaScript を記述するのに、Jade,Sass,LESS,Stylus,CoffeeScript などのプリプロセッサが便利で使っていますが、CSSFrameworkを利用することもありファイルが複数に分かれていることが多くなってきました。 grunt に限らず自動化処理を実行して、本番環境用に結合( concat )・圧縮(minify) して複数あるファイルを1つにまとめてアップロードする方も多いと思います。 しかし、HTML内で CSS( meta link=~ ) JavaScript (script src=~) は 本番環境では minifyファイルを、開発環境では元々の複数にわかれたファイルのパスを設定することになります。 (Sassのinclude 等を使えば最終的には1ファイルに纏まりますが、CSSファイルのみの構成などもあるので・・・・
既に多くのチームは git への移行を済ませており、また更に多くのチームが現在その移行段階にあります。一人のデベロッパーを訓練して、採用の支援として チャンピオン を任命することは重要です。それに加え、物事をあまり複雑にしない、シンプルで扱いやすい、コードコラボレーションのプラクティスを選ぶ事が肝要です。git であれば、非常に複雑なワークフローであっても魔法のようにシンプルにできます。私は実際にそれを目の当たりにしたので、間違いありません。 ワークフローに関するマニュアルは git にインストールされてはいません。しかし、このトピックに関して多くの人が質問を抱えている事を考慮すれば、インストールされているべきかもしれません。それでもご安心下さい。我々は役に立つ資料を作るべく、現在奮闘中です。 ワークフローに関する最近のウェビナーおよびガイド キレイな写真や、文字を読むのが好きな方には、我
SaaSのCIと言えばTravis CIやCircle CIといったサービスが有名ですが、いずれにしてもプライベートリポジトリを使う場合は有料なのです。しょうがないよね、商売だもんね。でもCI入れたいなぁ。 そんな中、GithubだろうがBitbucketだろうがプライベートリポジトリでも無料で使っていいよ!というβ期間中のCI、Werckerが僕の周辺で話題になっていたので、触ってみました。画面もスゲー使いやすい上に、ハマりどころもなく、これはひょっとしてひょっとするんじゃないの?という期待を込めて、rails newからRailsアプリをHerokuにデプロイするまえのチュートリアルを作ってみました。みなさんもこの記事を参考に、ぜひ使ってみてください。 この記事のゴール Githubにpushしたら自動的にWercker上でRSpecのテストが動くこと Werckerでのテストに成功し
前回の記事でGitHubとJenkinsを用いた自動デプロイ環境の概要をご説明しました。 GitHubやJenkinsと連携した開発環境作成でのrsyncとの出会い 今回は、その環境を実現するための設定手順を書いて行きたいと思います。 大きく4つの手順があります。 Jenkinsのインストール Apacheの設定 JenkinsとGitHubの連携 自動デプロイ設定 開発環境 ・CentOS 6.2 ・Apache がインストール済み Jenkinsのインストール まずは、Jenkinsのインストール 通常ならば、運用するサーバとJenkinsが動いているサーバを分けるべきですが、サーバコストの都合などで今回は同一サーバ上で動かすことにします。 ApacheサーバとJenkinsサーバが同じport80で待つことはできないので、jenkinsをport:8080で動かすことにします。 また
今日は、Git で複数人作業を行う際に共有リポジトリから pull する際の rebase オプションの必要性について検討してみました。 タイトルで結果は想像つくような気がしますが、順を追ってみましょう。 git pull でやってること merge と rebase git pull と git pull --rebase まとめ 1. git pull でやってること git pull コマンドは、fetch, merge をまとめて実行しています。 つまり、リモートブランチの最新のコミット情報をローカルトラッキングブランチへ持ってきて(fetch)、持ってきた最新のコミット情報とローカルブランチをマージ(merge)します。 参考:3.5 Git のブランチ機能 - リモートブランチ 2. merge と rebase ブランチを統合するには、マージの他にリベースがあります。 mer
みなさん、Git使ってますか?僕はまだメインのVCSがSubversionなのもあって、なかなか慣れません。せっかくGitを使っているのに、ちょっと不便なSubversionくらいの位置づけです。でも、同じような理解度の人って多いんじゃないでしょうか。 一方で、最近はGitHub管理のオープンソースプロジェクトが増えてきました。バグレポートを送るにしてもpull request*1が前提のような空気があり、Git初心者には少し敷居が高い印象があります。 そんな僕も先日初pull requestをしてみたんですが、色々な失敗の積み重ねで残念なpull requestになってしまいました。その反省を元に、本稿ではpull requestする際のベストプラクティスを紹介します。これは「Git Workflow」をベースにコマンド例などを加筆したものです。 概要 pull requestする際は、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く