(※3月18日追記:当初「SSH公開鍵の管理機能」において、GitBucketを「×」としていましたが、SSHアクセス機能を機能を有効にすることでSSH公開鍵の管理機能も利用できるとのことで、「○」に修正しました) GitLabおよびGitBucketと、RedmineおよびTracとの大きな違いとして、フォークやマージ/プルリクエスト機能をサポートしているかどうかがある。これらの機能を利用したいのであれば、GitLabやGitBucketが候補となるだろう。 いっぽう、Redmineはカレンダー機能やガントチャートと言ったプロジェクト管理機能が充実しているのが特徴だ。また、Tracはシンプルなユーザーインターフェイスや、プラグインによるカスタマイズ性の高さがある。フォークやマージ/プルリクエスト機能を利用しないのであれば、プロジェクト管理機能が充実しているRedmineやTracは十分な
peco と alias -g で git に便利革命がおきるので、ぜひご活用ください。 記事の一番下に設定のまとめがあります。 目録 便利革命1: git commit → g c 便利革命2: git checkout feature/something-great → g o B 便利革命3: git push -u origin feature/something-great → g puu R B 便利革命4: git remote add origin git@github.com/user/repo → g r add origin H 便利革命5: git checkout -b feature/something-great remotes/origin/feature/something-great → g b LR めんどいコマンド1: git commit Befo
Gitを日常の開発に使っていても、Gitがどのように動作しているのかや、ブランチやコミットがどのような概念なのかをはっきいりと理解していない人は少なくないでしょう。今回、GitHubのJohn Britton氏がイベントの為に来日し、下北沢オープンソースカフェにてGitについての非常に細かい内容についてのセッションを行ってくれました。 動画 90分ほどのセッションが高画質で録画されています。全編英語のセッションとなっていますが画面も見やすいのでご覧になってみてください。Gitのリポジトリがどういった情報を操作しているのかなどをさまざまなコマンドの実行結果と共に解説を加えるわかりやすい内容です。 大まかな話題 Gitのリポジトリの基本概念 ツリーオブジェクト・オブジェクト ワーキングコピー、ステージング、ヒストリの違い ブランチの動き セッション中のハイライトをいくつかをツイートからご紹介し
4/20にWAVE新宿で下記の講座を開催しました。 「フロントエンド技術をたかめたい・Webクリエイターのためのgithubで始めるgit講座」 〜黒い画面を使わずに、バージョン管理の基本を学ぼう〜 今回は、コワーキングスペース茅場町 Co-Edo(コエド)、マルチメディアスクール WAVE、株式会社コンテンツワン 、L15の4社主催での開催となりました。 20人ほどの参加者で、3時間ほどやりました。最初の30分でgitとgithubに関して紹介して、残りの時間でハンズオン形式で全員がgithubにpush/pullするまで行いました。 今回は、極力詳細の説明を省略して、とにかく使えるようになるまでを資料にしました。細かい話は質問が出るたびにしていくという感じでした。質問が活発だったので楽しかったです。 GUIクライアントとして登録すれば無料で使えるSourceTreeを使い、github
半年くらい下書きフォルダーにあったGitLabのインストール記事をサルベージしました。今回は、Amazon Linux AMIと最新のGitLab 4.1系でインストールしています。が、あまりに長く面倒くさいので、三行でまとめてみました。 GitLabはGitHubのクローンで、セキュリティー・ポリシー的にGitHubがNGな会社に最適 GitLabの中身は、Git + GitoliteをラッパーしたWebインターフェース インストールが死ぬほど面倒くさいので、後でAWSのPublic AMIとして公開するよしたよ →GitLabのPublic AMIを公開しました。 以下、手順です。気が長い人は読んでください。 ライブラリのインストール 素のAmazon Linux AMIを立ち上げたら、まずライブラリをインストールしましょう。一部sudoでやっていくと詰まるところがあったので、素直にr
みなさん Github を利用していますか? 「Git がわからないから…」と、そんな理由で使わないのはもったいないです。 Webや開発に携わる人間であれば、例えプログラムを書かなくても、Github へアクセスする機会は増えているのではないでしょうか。 Webの人であれば jQueryのプラグインを探したり、サンプルコードが Github においてあったりすると思います。 しかし、いきなり使いこなすのは難しいので、まずは以下のことをはじめてみることをおすすめします。 アカウントを作る 知り合いや気になる人をフォローする 自分が利用しているリポジトリや気になるリポジトリにスターを付ける News Feed を読む 日本人がやってるネタリポジトリの Issues やPull Requestsに絡む Gitを利用しなければいけない機能はとりたててありません。(Pull Requestには突っ込
ローカルで GitHub を構築! Git リポジトリ管理ツール「GitLab」を Mac OS X にインストールしてみた GitLab とは GitLab は Git リポジトリを簡単に管理できるツール Gitolite をブラウザから管理できるようにする Ruby アプリケーションです。 GitHub のオープンソースクローンと呼ばれることから分かるように、UI が GitHub とめっちゃ似ています。 GitHub みたいなサービスを使いたい!だけど Public はアレだなということもあると思います。そんなときに便利です。 社内 GitHub として使うケースが主なユースケースだと思います。 しかもすべてローカルだけで作ることができるので、ローカルマシンにインストールすれば、構築後はネットワークなしで GitHub 的な環境を使うことができます! そんな GitLab を Mac
履歴 恥を忍んで記事を公開させていただいたおかげで、いろいろフィードバックいただきました。フィードバックを取り込んで更新を行なっています。 2012/11/16: cherry-pickしやすいように、というくだりのところは論理通ってないので削除しました。 1 pull req. 1 commitの原則をやめました。言いたいことであった「試行錯誤の過程を入れないで」を丸パクリしました! > id:kazuho その他表記修正、クリアコードさんの記事に説明丸投げなど。 まえがき gitでトラブった!という話を何度か聞いたことがあります。なんでトラブッてるんだろう…と話を聞いたところ、同一のリモートブランチに対して複数人・複数環境から操作が行われているようです。極端な例を挙げると、masterブランチしか存在しておらず、コミットログをキレイにするためと称してgit pull –rebaseを常
hubコマンドは、MacやLinuxのターミナルからGitHubの操作をおこなうためのコマンドです。通常はブラウザを通しておこなっているような操作をCLIでおこなうことができます。 これがURLを渡すだけで、利用シーンがあるので、紹介します。 インストール公式サイトを確認する限りgemでインストールするのは、動作が遅くなるので非推奨とのこと。よって、Mac環境はHomebrewかMacPortsで入れた方が良い。 gitコマンドのエイリアスとしてhubを設定してしまうことが推奨されてますが、あえて今回はしません。 MacPortsの場合 $ sudo port install hub Homebrewの場合 $ brew install hub 動作確認$ hub --version git version 1.7.12.4 hub version 1.10.2GitHubへの初回アクセス
必要になったのでそういうものを作りました。 https://github.com/kyanny/git-prune-remote-branch パスの通ったところに置いて Git のワーキングディレクトリで実行すると master と develop にすでにマージ済みのリモートブランチを全部削除します。 --noop で dry-run モードになるので実際に消す前に確認もできます。なんで master だけじゃなく develop も?というと、僕のチームで gitflow を使っているからです。 $ git clone git://github.com/kyanny/git-prune-remote-branch.git $ git-prune-remote-branch --noop $ git-prune-remote-branchgit push --mirror じゃダメなの
Pull Requestをためたりなどして、マージする競合(コンフリクト)が発生すると、GitHubでは自動マージできないためこの様な表示になる。 この様なときの解決方法は、競合が発生しているため、人間が判断して取り込む必要がある。 自分のリポジトリへマージするまず、Pull Requestを受け取ったリポジトリを最新の状態にする。 $ git clone git@github.com:hirocaster/wdpress69.git Cloning into 'wdpress69'... remote: Counting objects: 236, done. remote: Compressing objects: 100% (122/122), done. remote: Total 236 (delta 134), reused 211 (delta 111) Receiving
システムの技術的負債にどう挑むか?~『レガシーコード改善ガイド』著者マイケル・フェザーズが語る課題と解決策~
GitHubの特に重要な機能である「プルリクエスト」の活用方法についてGitHub社内でのノウハウが公式ブログの記事になっていました。GitHubが今回更新をしたAboutページの開発でも2ヶ月の間に10人のメンバーが130のコミットと91のコメントのやりとりがブランチ上で行われていました。 GitHubberによる講演などでもプリリクエストが重要な機能であると強調されているようです。 記事によるとプルリクエストは新しいアイデアについてのディスカッションを生み、協力してくれる人を見つける為のとても良い方法との事で活用するコツとして以下の3つの点を紹介しています。 プルリクエストはなるべく早く起こす プルリクエストは機能についての意見交換をする良いきっかけになります。コードの修正が終わっていなくてもなるべく早くプルリクエストをする事で、最後にまとめてフィードバックをするのではなく発展的にコメ
gitによるバージョン管理 バージョン管理システムはつかってますか? 僕は前に自分の作成したコードを元に、後輩にプログラムを作らせようとしてまずは僕のコードをコピペしろと指示したところ、コピペしかしてない(と言い張る)割にはコピペしたコードは動かず、さらに何故かコピペ元の僕のコードが滅茶苦茶に荒らされて当然のごとく動かなくなるという、なんかもう幽霊の存在を認めない限り説明がつかないような怪奇現象に遭遇したことがあります。しかもそのときはcpコマンドによるバックアップに頼っていて運悪くバックアップを忘れたために僕の貴重な1日が消え去ってしまった訳でして、それから僕はバージョン管理システムに頼ることを固く心に決めました。また僕はその目を覆いたくなるような残虐な事件以来、建設業界に見習って、IT業界でもプロジェクトキックオフ時にお祓いはすべきだと訴え続けています。 まぁそれはいいとして、いやまだ
Git/Github初心者のみなさんこんにちわ! Pull Requestを送ってみたいけど、やり方がわからない? 間違ったPull Requesするのがこわくて躊躇している? もったいない! そんなみなさんに、Pull Requestを送るための最小の手順をご紹介します。 昨日ちょうどEthnaにPull Requestを1件送ったので、これを題材にして説明します。 以下、Githubのアカウント取得、gitのインストール、SSH鍵の設定は終わっているものとして解説をすすめます。 Pull Requesを送る最小手順 1.ブラウザで本家プロジェクト画面を開きます。 例:https://github.com/ethna/ethna 2.forkボタンを押します。 3.以下、自分のPCで作業 git clone git@github.com:DQNEO/ethna.git cd ethna
プロジェクトホスティングサービス、GitHubのMac用公式クライアント。 gitはこれまでコマンドラインからカタカタと利用してきましたが、リポジトリを作成したり、履歴の確認やpush・pullが非常に簡単にできてこれから使っていきたいアプリケーションです。 GitHubによるアプリケーションですがGitHub以外にも使えます。 ダウンロードページ 始めにGitHubのアカウントセッティングと、マシン内のリポジトリのスキャニング。後から【Preferences】からスキャンできるので飛ばしても良いです。 gitで管理しているプロジェクトが一覧で表示されます。 最近あった更新やその内容を確認したりそれを適用したり。Revert、Rollbackもボタンから可能。 ブラウザからGitHub上のプロジェクトページを開いた時に、そこから簡単に git clone もできるようになっています。 新た
みなさん、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ページを開く