会社関係の勉強会向けに作った資料です。 パラパラマンガ調のためページ数は多いですが、内容は基礎的なものです。 このスライドを読み終わった人にオススメ: 「図解gitworkflows(7)」 資料一覧: https://docs.google.com/spreadsheets/d/1VZMz_31Z7FQBnK139o8yMqzwrTJgZWtPqgoG-mx1zh0/edit?usp=sharing
対象 開発フローの中でコードレビューを実施しているひと git add -p や git rebase -i でコミットの分割や統合ができるひと コードレビューさせない レビュー無しにマージしてもらうために同僚をいかに抱き込むか。 という話ではなく、レビュワーの コードレビューの負荷を下げる ことを意図しています。 無視できるコミットを増やす どうすればレビュワーがより短時間で自分の書いたコードをレビューできるか。この問に対して、レビューの妨げとなるものを排除する、というアプローチがあると思っています。そのための良い方針だと考えている 無視できるコミットを増やすこと について書きます。 前提 コミット どのコミットにおいてもテストが通るようにする コミットメッセージ ちゃんと Git のスタイルで記述する (Gitのコミットメッセージの書き方 の原則を守る) Git の操作 雑にコミットし
この記事はGit Advent Calendar 2014の6日目の記事です! (更新がお昼になってしまいました、ごめんなさい><) みなさん! Gitの-pオプション使ってますか? 今日は便利な-pオプションを使えるコマンドと、使いどころをご紹介します! 紹介する内容 git add -p git stash -p git log -p git stash show -p git checkout -p git add -p きっとこれが一番有名ですね! 追加したい変更を、ファイル単位ではなく差分のブロックごとに追加していくことができます。 Git管理されているindex.htmlに、以下の修正を加えたとしましょう。 ヘッダーのメニューの文字を小文字から大文字に変更 Contactに新しいリンクを追加 このまま両方まとめてコミットしてコミットメッセージに両方の内容を書いておくというのもひ
技術部のid:gfxです。iOSアプリ開発に欠かせないパッケージ管理ツールといえばCocoaPodsですが、これはPrivate Podsを作って社内ライブラリ専用のSpecs(private Specs)を管理することができます。 ※ 2014/12/22追記 CocoaPods 0.35.0 でpod lintの--only-errorsが廃止されて--allow-warningsになったのでそのように変更しました private SpecsがなくてもGit URLを指定することで社内用podspecを開発・管理することはできますが、private SpecsがあるとURL指定を簡略化したり依存関係の解決が簡単になるというメリットがあります。クックパッドでもすでに十数個のprivate podspecが登録されており、CookpadUIやAPI clientなどはpodspecとしてp
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに RubyのコミッターでもありRailsなどの多くのOSSで活躍されているMarc-André Lafortune さんのブログに面白い記事があったので筆を取りました. (許可は取りましたヨ) Why I Won't Squash My Commits *注釈 [...] で記された文章は原文には存在しない私の注釈であるので留意されたいです. 翻訳に至らない所があれば編集リクエスト待ってます. 要約 PR,feature単位でcommitをまとめるかどうかでRailsのプロジェクト上などで揉めた. それぞれのcommitは独立し
GitってなんかコワいっていうデザイナーもGitがいまいち使いこなせていないコーダーもOK! Gitを危なげなく、しっかりと使うための知識とノウハウを学べる「Web制作者のためのGit入門」を紹介します。 よしっGitをはじめる! もっと便利に使いこなしたい! 効率のよいWeb制作の環境に取り組もうとしている人にオススメの本です。実務に必要なノウハウを知ることで、安心してプロジェクトを進めることができるようになります。 Git本は何冊かでていますが本書の大きな特徴は、二人の著者によって書かれていること。入門編と実践編で別々の人が担当されています。 1章は入門編。Gitの基礎知識からインストールや基本操作まで、新人教育を担当していたディレクターの方が初心者に必要なポイントを丁寧に分かりやすく解説しています。新人教育を担当する人の目で読んでも参考になると思います。 2章はGitの実践編。フロン
pull requestの作り方について 作業途中でもpull request作ったほうがいい。 作業途中だと分かるようにwantedlyだと、[WIP]とかタイトルの最初につけてる タイトルに書くこと 作業の内容が分かるタイトル descriptionに書くこと WHY WHATを必ず書く Viewに変更がある場合は、スクリーンショットを貼る 関連のissueやpull reqeustへのリンクがあれば書く コードだけで分かりにくい箇所の説明(できるだけコードだけで分かるほうがいいけど) イメージは、初めてpull requestを見る人がmergeする上で必要な判断ができる情報があること。 どの作業をしているか、残っているか分かるように、マークダウンでチェックリスト作る git commitの方法について 僕自身まだまだcommitの単位は汚いので、今の僕レベルで気をつけていることを書
このドメインは お名前.com から取得されました。 お名前.com は GMOインターネット(株) が運営する国内シェアNo.1のドメイン登録サービスです。 ※表示価格は、全て税込です。 ※サービス品質維持のため、一時的に対象となる料金へ一定割合の「サービス維持調整費」を加算させていただきます。 ※1 「国内シェア」は、ICANN(インターネットのドメイン名などの資源を管理する非営利団体)の公表数値をもとに集計。gTLDが集計の対象。 日本のドメイン登録業者(レジストラ)(「ICANNがレジストラとして認定した企業」一覧(InterNIC提供)内に「Japan」の記載があるもの)を対象。 レジストラ「GMO Internet Group, Inc. d/b/a Onamae.com」のシェア値を集計。 2024年5月時点の調査。
A interactive Git visualization tool to educate and challenge!
最近、個人のリポジトリレベルの開発でも、自分のためのIssueを立て、自分しか見ないPull Requestを作ったりしている。 docker-registry をインストールするぞ〜 · Issue #1 · udzura/docker-playroom · GitHub Install Ruby recipe by udzura · Pull Request #3 · udzura/docker-playroom · GitHub First version of ikachan module by udzura · Pull Request #1 · udzura/ikachan-node · GitHub この際気を付けていることとして: Issue、最初のdescriptionは最初のTODOへのポインタだけ書いておく プルリクエストは 生煮え の状態で出す 思ったこと、詰まった
はじめに gitはコミットごとにレポジトリ内のファイル全てをスナップショットとして保存するというリッチな 設計になっている。 それがgitの便利さの所以なのだが画像データや音声データのようなバイナリデータを持とうとすると 少しの変更でもそのたびにコピーが生じてファイルサイズ分の容量が増えることになり、あっという間にレポジトリが 肥大化してしまう。 特に学習結果をファイルに保持してテスト等に使いまわすようなプログラムを管理しようとすると アルゴリズムのパラメータを少し変えるたびに100kB近い容量が増えていき、実にイケてない。 普通なら.gitignoreに*.xmlと書いてデータ自体は手動管理したり、シンボリックリンクにして別ディレクトリに置いてそれだけrsyncで同期するようにしたりするんだが 過去の実験時の状態に戻れなかったり、毎回rsyncするのは不便だった。 なんか無いかなーと思っ
Gitterに感動した 金曜にメールチェックしてたら「Gitterが一般βになったから誰でも参加できるようになったよ」ってメールが届いてた。 確か以前は抽選かなんかだったんだけど、アイディアがちょっと面白いなーと思って参加できるようになったらメールでお知らせしてもらおうと登録してたんだけど。 Gitter - Chat, for GitHub 早速、試してみたんだけど…久々に感動するレベルのWebサービスでした。 そもそもこのサービス何なのか知らない人が大半だと思うんで、ちょっと説明するとこんな感じです。 GitHubのリポジトリやOrganization単位でチャットルームを作ることができる まあ、これだけなんですが。WebアプリとMacアプリがあってiPhoneとかのモバイル対応はまだらしい。とはいえ、Webアプリの方をMobile Safariなんかで見たらそこそこ見やすい感じではあ
ロング・テール理論の名付け親で、雑誌「Wired」の編集長としても知られるクリス・アンダーソン氏が3月12日付けのブログでオープンソースソフトウェア(OSS)プロジェクトの運営体制に関する誤解を指摘をしている。 アンダーソン氏によれば、多くの人はオープンソースプロジェクトというのは草の根から立ち上がり、自律的に組織化し、民主的に運営されているという誤った認識を持っている。ところが現実はまったく逆で、1人か2人の「慈悲深い独裁者」によって運営されている、という。 これはオープンソースプロジェクトに参加していたり、あるいは日常的に成果物を利用している人であれば、そういうものだと首肯するかもしない。メーリングリストで客観データに基づいて議論したり、リーダーを民主的に選ぶようなプロジェクトもあるかもしれないが、おおかたのオープンソースプロジェクトには、それを開始し、中心に位置し続ける“独裁者”がい
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く