Gitのリポジトリを分かりやすく可視化し、高速かつ直感的にGitリポジトリを操作できる、Mac用のGitクライアント「GitUp」が公開されています。現在プレリリース中につき無料で利用可能で、ユーザー登録すると、全機能がアンロックされるシステムとなっています。 分かりやすくかつ高速 GitUpの第1の特徴は、わかりづらくなりがちなGitリポジトリの迷宮的な履歴を分かりやすく表示できることで、GitUp外部で行った操作がリアルタイムに反映されることで、混乱を招かないように工夫されています。 また、プロが使うためのツールとして高速性にも配慮されており、Gitバイナリツールをバイパスし、リポジトリのデータベースに直接アクセスすることで、40,000コミットを超える、公式Gitリポジトリ全体を1秒以内にロードし、描画することが可能になっています。 値段は不明 GitUpは現在プレリリース期間なので
対象 開発フローの中でコードレビューを実施しているひと git add -p や git rebase -i でコミットの分割や統合ができるひと レビュー無しにマージしてもらうために同僚をいかに抱き込むか。 という話ではなく、レビュワーの コードレビューの負荷を下げる ことを意図しています。 無視できるコミットを増やす どうすればレビュワーがより短時間で自分の書いたコードをレビューできるか。この問に対して、レビューの妨げとなるものを排除する、というアプローチがあると思っています。そのための良い方針だと考えている 無視できるコミットを増やすこと について書きます。 前提 コミット どのコミットにおいてもテストが通るようにする コミットメッセージ ちゃんと Git のスタイルで記述する (Gitのコミットメッセージの書き方 の原則を守る) Git の操作 雑にコミットしても、後できれいにコミッ
(追記) この記事は公開から時間が経っており、内容が古くなっています。 本稿では、すでにプライベートなWebサーバを運用している人向けにGitサーバの構築方法を説明します。ひと手間をかけるだけでGitサーバを構成できます。Webサーバがない人はGitHubでプライベートリポジトリを作った方が早くて安くて旨いかもしれません。 要件 以下の要件を考えてみます。 SSHでGitリポジトリにアクセスしたい。 HTTPSでGitリポジトリにアクセスしたい。 Webブラウザでリポジトリを閲覧したい。 Gitリポジトリには機密性の高い情報を格納する可能性がある。 具体的には、 git clone git@git.example.com:/something.git とか、 git clone https://myname@git.example.com/something.git とかしたいです。 Gi
オペレーションとかインフラ系のエンジニアリングからは少々離れそうなので、個人的な備忘録がてら、Gitのブランチモデルについて。淡々と書くよ。 見えないチカラ: A successful Git branching model を翻訳しました 基本的に、このA successful Git branching model(上記は翻訳記事)を参考にしています。ですが、完全ではありません。運用しながら都合よく省略していますし、悪く言えば曲解もしています。あくまで、わたしが都合良く解釈して取り回した結果と考えてください。 さて、このようなドッシリとしたブランチモデルが、あらゆる規模のプロジェクトに対して有効であるかといえば、もちろんそうではありません。コツコツ個人で開発しているライブラリなどは、ブランチを使わなくても良いケースがあるでしょうし、作ってもバージョン番号ブランチぐらいのケースだってザラ
Gitポケットリファレンス 下記3つはいずれもcommitの修正ですが、違いが分からない人は Gitポケットリファレンスを読むことをオススメします。(答えはGitポケットリファレンスに書いてあります。) 以前書いたとおり社内SubversionリポジトリをGitHubへの移行中で GitHubへの本格移行する前に、「運用ルール決め」と「意識合わせ」の意味で 社内のインフラ系エンジニア向けに「Git、GitHub講習会」と銘打って勉強会を開催。 個人的にはGitHubも活用してて、Git自体も理解しているつもりだったんですが、 人に説明していると、理解があやふやな点が結構あることがわかったので、 先日発売されて、周りの評判も上々なGitポケットリファレンスを購入。 Gitの概念について説明している書籍は多数発売されていますが、本書はGitの一つ一つのコマンドについて 見やすく説明されているの
注意: バズってますが、これははてなダイアリーからはてなブログの自動マイグレーションに失敗してたものを復旧させたもので、書かれたのは2012年です。 - 最近流行っているGit初心者向け記事は、「僕らが本当に知りたかったこと」が欠けているようにしか思えません。 そこで、本当のGitの使い方を僕が皆さんに伝授しようと思いました。 なにはともかく使ってみよう 前提として、皆様のお手元にはすでにGitがインストールされているものとします。 今回はエディタとしてDungeonCrawl StoneSoupを使います。 Downloads « Dungeon Crawl Stone Soup http://crawl.develz.org/wordpress/downloads Dungeon Crwal Stone Soup は今一番ホットなオープンソースのローグライクです。風来のシレンやトルネコ
時代がWindowsハッカーに追いついてきた。 GitHub for Windows sync Stay in sync The sync button turns the complex workflow of pulling and pushing into a single op... http://windows.github.com/ GitHub for Windows - GitHub Ever wish there was an easy way to get up and running with Git and GitHub on your Windows computer? ... https://github.com/blog/1127-github-for-windows 待ってたよ。 ダウンロードしてインストールしてみた。 この後、PC内から存在するリポジトリを
コミットメッセージの書き方ではコミットをわかりやすくするためには以下の2つの条件を満たす必要があると書きました。 コミットの内容が分かりやすく説明されていること コミットの内容が小さくまとまっていること このうち「コミットの内容が分かりやすく説明されていること」についてはすでに説明済みです。今回は「コミットの内容が小さくまとまっていること」について説明します。 めざすところ 単純にコミットの内容を小さくするだけではわかりやすくなりません。それでは、どのような基準で小さくすればよいのでしょうか。 よく言われることは1つのコミットには1つの小さな論理的にまとまった変更だけにする、というものです。たしかにこれは重要です。しかし、これだけを基準とすると、人によっては大きめなコミットになってしまいます。人それぞれで論理的なまとまりの大きさが異なるからです。 1つのコミットでどうすればよいかを考えるの
GitStatsはGitリポジトリを解析して静的なHTMLファイルとグラフを出力するソフトウェアです。 Gitにaddしてcommit、addしてcommit…そんな日々の努力の結果をビジュアル化してくれるソフトウェアがGitStatsです。社内プロジェクトで使ってみても面白そうです。 supybotのGitリポジトリから作られたHTMLです。 アクティビティです。コミット数などをグラフ化しています。 時間数が出たりするのも面白いです。 コミット数を見ればプロジェクトの栄枯盛衰が分かります。 タイムゾーンごとのコミット数もユニークです。 開発者の一覧です。 ファイル数のカウントです。 拡張子ごとというのも面白いです。 コードの行数です。 タグ一覧です。 GitStatsはアクティビティ、ファイル数、コード数、タグ、開発者と言ったデータをリポジトリから抽出してグラフ化します。静的なHTMLで
新サービスが続々登場してアツい! 「GitHub」とは 皆さんは「GitHub」を活用しているでしょうか? 「GitHub」(ギットハブ)はソースコード管理用の分散型バージョン管理システム「Git」を使ったホスティングサービスです。 Gitの特徴は、作業用として自分のコンピュータ上にあるローカルリポジトリがあれば、ネットワークに接続できない状態だったとしても、ソースコードの更新や、履歴を調べたりできる点にあります。その特徴はGitHubにも生かされていて、オープンソースとして公開中の既存のコードを分岐(fork)して、新しいプロジェクトとして開発できます。 また、自分が手元のローカル環境でバグ修正したり、拡張したソースコードを本家のオープンソースプロジェクトに取り込んで(pull)もらうことも手軽にお願いできます。 さらに、READMEテキストファイル(README.md)などを独特のマー
gitの勉強をしつつ取ったノートを記事化しました。一応これを読めばざっくりとした導入やSVNとの違いが分かってもらえるように書いたつもりです。svnを使った経験があることを前提に進めていきます。 svnの場合、一つのレポジトリに対して認証のあるユーザが変更を報告していくユースケースをとっています。gitの場合は、個々のローカルマシンにリポジトリが分散されて配置され、お互いに変更を報告しあうユースケース。これはLinuxの伝統的なバザール方式の開発を想定しています。そのため例えばカフェや電車で開発したり、マスターはgithubやgitfarm(Git Hosting参照)にしておいて時々ローカルの変更を報告することも可能です。 目次 インストール 基本操作 Gitリポジトリの作成 ブランチの作成。 タグ ファイルを無視する 索引の理解 取り消し 導入 --hardと--softの違い 一個の
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く