Redirecting to the Git for Windows homepage If you are not redirected automatically, please click here.
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
先の投稿でも書いたとおり、6月7〜8日開催されたWordCamp Kansai 2014に参加し、公募枠で登壇してきました。 セッションを聞いてくださった皆様、ありがとうございました。 セッションのタイトルは「WordPressサイト制作におけるデプロイメントを考える〜Gitとデプロイメントサービスの活用〜」です。概要はというと、WordCamp Kansaiのサイトからの引用になりますが: 現在WordPressサイトの構築や更新には、FTPもしくはSFTPソフトを利用したデプロイメントが主流です。サイト全体の引っ越しであれば、あるいはrsyncやscpといったコマンドを使う場合もあるでしょう。しかし手動で行う作業や、不慣れなコマンドを使うことにより、ミスしたり、時間が掛かったりしませんか? 一方で、最近は開発にGitを用いたVCを実践している、あるいは検討、勉強しているという方も少しず
GitHub User Group主催のGitHub Kaigiが6月1日、都内で開催されました。GitHubを利用した開発は、スタートアップやオンラインサービス系の企業などを中心に広まりつつあり、いままさに数多くのノウハウの交換が求められているツールでもあります。 本記事ではGitHub Kaigiの最初のセッションとなった大塚弘記氏の「GitHub実践入門 ─ Pull Requestによる開発の変革」の内容をダイジェストで紹介します。 GitHub実践入門 ─ Pull Requestによる開発の変革 大塚弘記といいます。会社でもリアルでもほとんど@hirocasterと呼ばれています。 今日はメッセージを3つ持ってきました。まず、GitHubを使っている世界と使っていない世界についての話を少し。次に、GitHubを使っているけれど、十分に使っているかどうか、という話をして、最後に本
Yosuke Furukawa @yosuke_furukawa @sonots masterは絶対に安定して動作させたいとかそういう思想だよね。developブランチ、 develop で安定してきたらmasterにmergeするって思想だけど、僕も最近作ってない… 2014-05-30 11:16:02 そのっつ (Naotoshi Seo) @sonots @yosuke_furukawa master ブランチが絶対安定してるなら、今度は release ブランチいらない感ある。で、どちらかというと release ブランチを安定させて master ブランチで開発すれば良い。そのほうが github とも親和性高い感ある。 2014-05-30 11:38:51
これは Git (や Subversion などのバージョン管理システム) にコミットする時により良いコミットメッセージを書くための提言です。この提言は特にメッセージの一行目だけを対象とします。せめて最も重要な一行目だけでも良いメッセージを書いて欲しいからです。提言をズバリ一言で表すと 一行目には要求仕様を書け です。 背景 プロジェクトによっていろいろ慣習の差はあるものの、一般的には「コミットメッセージの一行目は変更内容の要約を簡潔に書け」とされます。特に Git は、各コミットメッセージの一行目だけを取り出してそれを一覧表示するなど、一行目を特別に処理する機能が多いので、一行目にできるだけ多くの情報を凝縮させることは重要です。またメッセージを一行しか書かない不届きな慣習のプロジェクトでは、十分な情報を持たないメッセージは無用の長物と化します。 良くないコミットメッセージ しかし私は、情
GitHub on steroids Browser extension that enhances GitHub code review and exploration. Features * Fast IDE-like code tree * Quick search in tree format * Bookmark repos, issues, PRs, files * Support GitHub themes * Support private repositories * High performance, working with repositories of any size PRO features * File icon themes * Code font settings * Quick PR navigation * Unlimited bookmarks *
(3/22/16更新: 似たような記事が多かったので「移行応援」タグをつけた(宣伝乙) 10.9時点の記事ですが、10.11(El Capitan)でもほぼ同様にできるハズです。ただEl Capitanのrootless/SIPの影響でHomebrewのインストールではまる可能性があります。以下の2記事が詳しいです: http://qiita.com/riocampos/items/525ec4b35744ad586c5a http://qiita.com/aoioooii/items/c14922eede6a83a750da 本文/画像はほぼ最初期のものから変わっていません) 目的 クリーンな状態から、 最速で 、かつ GUIツールを使って Ruby on Railsの開発環境+Gitでのバージョン管理の環境を整える。 コマンドラインでやる方法は山ほど書かれてきました。それでも初めての人
テスト駆動開発(TDD)の一般化とGitHubの登場によって、機能追加の際にコードとテストを同時に実装する(そして、両者を一括してmasterにmergeする)という開発手法が一般化してきました。 しかし、「良いプログラム」の要素を構成するのは、コードとテストのみではありません。動作するコードと、その品質を担保するためのテストがあったとしても、適切なドキュメントがなければ、ユーザーはそのプログラムをどうやって使ったら良いかわかりません。 つまり、ユーザーに使いやすいプログラムを継続的に開発/提供しようと思うと、 コード テスト ドキュメント の3点セットを提供する必要があるのです注1。 今日のJSXが抱えている最大の課題は、ドキュメントが不足しているという点にあります。その原因は、「機能追加」の際にコードとテストのみを実装してmasterにmergeすることを繰り返す一方で、ドキュメントは
Development (開発の進め方) GitHub Flow の利用 レビューの実施 Testing (テスト) Deployment (リリースの仕方) Releases (リリース後の記録) References(参考文献) Appendix(付録) Release's notes の作成方法 History(更新履歴) 2014/03/15 Development (開発の進め方) GitHub Flow の利用 masterブランチは常にデプロイ可能な状態としなければならない テストが失敗する状態の場合、直ちに修正するべきである テストが失敗する状態の場合、デプロイすることは許されない 「新しい何か」に取り組む際は、 pull request を用いるべきである ブランチは master から作成し、ブランチ名は説明的な名前とすべきである(例: new-oauth2-scope
morimorihogeです。残暑やばい。 ※元々は2014年に書いた記事ですが、2020年になっていろいろと事情も変わっているので2020年revise版として更新しました。 弊社ではバージョン管理システムにGitを使っています。 数ヶ月以上一緒にやっているある程度ツーカーなメンバーだけのプロジェクトなら問題無いのですが、案件によっては協力会社の方が一時的にJOINしたり、新規参入メンバーの参加などで、これまでGitを使ったことがない、または本格的なチーム開発でGitを使ったことがない人が参加することもあります。 ※2020年現在では流石に全くGitを使ったことのない開発者というのはほぼ見なくなりましたが、チーム開発できちんと運用に乗せて使ったことがない、という所は今でもそこそこあるようです。 Gitは自由度の高いシステムですが、その分概念を覚えることが必要なため、導入の敷居が高い方だと
[English version] はじめまして、LINE技術戦略室のhayaishiです。 趣味は自転車と言っていますが最近は全く乗っていません。 この記事では、LINEのiOSアプリ開発に関することをいくつかご紹介させていただこうと思います。 LINEのiOSアプリ開発環境 ソースコード管理 ソースコードはgitで管理しています。gitのリポジトリブラウザとしてGithub Enterpriseを利用しており、Githubでお馴染みのPull Requestなどを活用して開発を進めています。 また、LINEのiOSアプリのタスクについてはGithub Enterpriseとは別のチケット管理システムを利用しておりそちらのステータスと連携して開発者、QA、プランナー間の開発状況の共有を行っています。 Gitでの開発フローについて LINEのiOSアプリはgithub-flowの様に
なんとなく最近どんな感じでGitを使っているか、適当にリストアップしてみた。 よく使うやつ git status git status --branch --short にしている。変更されたファイルが出る。とりあえず何をしたかざっくり把握する用。sにエイリアスしている。一日100回くらい実行しているのではないか。 git diff 特にオプションは指定していない。何をしたかしっかり把握する用。dにエイリアスしている。一日50回くらい実行しているのではないか。 git grep バージョン管理しているファイルから渡した単語を含む行を検索、表示。関数の検索などあらゆる場面で超便利。オプションは --line-number --show-function --color --heading --break がオススメ。 git ls-files バージョン管理しているファイルのファイルパスを表
いままでAppleにアプリを申請するタイミングでタグを打っていて、 その後にリジェクトされると以下のようなタグが残ることがありました。 非常にダサいですね。 1.0.0 1.0.0-2 1.0.0-3 最近は少し学習して、QAに入る段階でrelease/1.0.0といったブランチを切るようにしました。 審査に出した段階ではまだタグは打たず、もしもリジェクトされた場合は引き続きrelease/1.0.0を更新します。 審査を通過した場合はそこでタグを打って、release/1.0.0をmasterにマージします。 以下の図のようなイメージです。 このように運用することで、余計なタグが打たれることはありませんし、審査中のバージョンを見失うこともありません。 もしかしたら普通のiOSデベロッパーは当たり前のように実践していることなのかもしれませんが、 自分は最近までダサいタグを打ったり、タグを打
今回はJenkinsとBitbucket の連携をします。 Bitbucket はプライベートリポジトリを何個でも作れて、5人までなら無料で使えるという優れもの。少人数開発ならこれを使わない手はないです。 Github Enterprise だとお金かかる部分が浮きます。 さらに! Wiki 機能もあり、今回はここに自動生成したドキュメントを反映できるようにします。 またJenkinsはどっかのリモートに置くとそれだけでお金がかかるし、無料のJenkins ホスティングサービスは柔軟性が無いので使いません。その代わりにしばらくはMacのローカルでJenkinsサーバを立てて運用していきます。 ローカルでJenkinsを立てると、Bitbucketへのフックができなくなるので、git push した瞬間にJenkinsを走らせる、みたいなことはできないのでご注意を。 やりたいこと Git p
おお、これは企業で使えそうですよ! 企業によっては外部にソースコードを預けられないため、自社でGitサーバを構えているところも多いでしょう。しかしそうなると管理画面が欲しくなります。GitHubの管理画面は優秀で、ああいったWebブラウザ上でリポジトリの情報を見たいと思うはずです。 そこで使ってみて欲しいのがGitonomyです。デザインの格好いい、Gitリポジトリマネージャです。 Gitonomyの使い方 GitonomyはPHP + Symfonyの組み合わせで作られていて、Webブラウザ上でGitリポジトリの操作が一通りできるようになっています。ユーザはプロジェクト単位にグループに入り、そこで権限管理される仕組みです。 ソーシャル機能はありませんが、企業ユースであれば十分ではないでしょうか。社内でGitサーバを立てている場合はぜひ導入を検討してみてください。 GitonomyはPHP
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く