履歴 恥を忍んで記事を公開させていただいたおかげで、いろいろフィードバックいただきました。フィードバックを取り込んで更新を行なっています。 2012/11/16: cherry-pickしやすいように、というくだりのところは論理通ってないので削除しました。 1 pull req. 1 commitの原則をやめました。言いたいことであった「試行錯誤の過程を入れないで」を丸パクリしました！ > id:kazuho その他表記修正、クリアコードさんの記事に説明丸投げなど。 まえがき gitでトラブった！という話を何度か聞いたことがあります。なんでトラブッてるんだろう…と話を聞いたところ、同一のリモートブランチに対して複数人・複数環境から操作が行われているようです。極端な例を挙げると、masterブランチしか存在しておらず、コミットログをキレイにするためと称してgit pull –rebaseを常
会社で使ってる GitHub のプライベートリポジトリで master ブランチに対して出てる Pull Request を Merge したらコードが消えるという珍事があった。ファイルを削除する commit とかないにもかかわらず、全消しされてしまった。ちなみに同じ Merge を手もとでやるとコードが消えたりはせずちゃんと Merge された。極めて謎な現象だった。 master ブランチが空になるとデプロイができなくなって不都合があるので（ Webistrano 上でデプロイするとき master ブランチからしかデプロイできないようなレシピになってる）、コードが消滅したブランチを bukkowaremaster にリネームして手もとで Merge したブランチを force push してしのいだ。 GitHub に問い合わせてみたところ、ぬるい感じの一次返信が来たので原因教えて
普段から git rebase や git commit --amend をよく使っており、それらのコマンドはコミットのタイムスタンプを変更しないものだと思っていたのですが、実はコミットのタイムスタンプを変更していることに気付いて驚いたという話。 Git のコミットがもつ 2 種類のタイムスタンプ 特に何もオプションを付けずに git log すると、以下のように Author と Date が表示されます。 $ git log commit d447eeeb49d04e79b257e7abe6e633541d5e1c52 Author: nobuoka <...@...> Date: Thu Jan 31 20:45:47 2013 +0900 Prepare test tools (mocha and qunit)で、git rebase や git commit --amend で過
あなたが git をコマンドラインで使っていようと、SourceTree などのツールから使っていようと; また、コードを Bitbucket にホスティングしていようと、Stash で会社のファイアウォール内側にホスティングしていようと、もしあなたが私のようであれば git がリリースされたときはいつでもパーティーをするでしょう – ウィンク –。 Git ユーザーにとってスムーズなアップグレード方法 git 1.8.3 がリリースされました。もちろん、これは最新バージョンへのアップグレードを意味しています。これは比較的、簡単であるべきです: もし OSX 上で homebrew を使用している場合は単に brew update && brew upgrade git とタイプするだけ (OSX 上で .gitignore を解析中に、直前に発見されたバグにより、 homebrew はア
コミットメッセージの書き方ではコミットをわかりやすくするためには以下の2つの条件を満たす必要があると書きました。 コミットの内容が分かりやすく説明されていること コミットの内容が小さくまとまっていること このうち「コミットの内容が分かりやすく説明されていること」についてはすでに説明済みです。今回は「コミットの内容が小さくまとまっていること」について説明します。 めざすところ 単純にコミットの内容を小さくするだけではわかりやすくなりません。それでは、どのような基準で小さくすればよいのでしょうか。 よく言われることは1つのコミットには1つの小さな論理的にまとまった変更だけにする、というものです。たしかにこれは重要です。しかし、これだけを基準とすると、人によっては大きめなコミットになってしまいます。人それぞれで論理的なまとまりの大きさが異なるからです。 1つのコミットでどうすればよいかを考えるの
もう1年以上前になりますが、コミットメッセージの書き方を説明しました。ざっくりまとめると、以下のことを説明しています。 わかりやすいコミットメッセージがいかに大切か どのようなコミットメッセージがわかりやすいか（具体例付き） この説明をしてからも、日々コミットしていくなかで新たに得られた「どうすればもっとわかりやすいコミットメッセージになるか」という知見が増えていました。これは、コミットへのコメントサービスの提供を開始した1ことも影響しています。このサービスでは、コミットへコメントするときに「どうして自分は他の書き方よりもこの書き方をわかりやすいと感じるか」を説明しています。その過程で「なんとなくこっちの方がよさそう」だったものを「具体的にこういうときにこう感じるのでこっちの方がよさそう」と何かしら理由を考えるようになりました。これにより、今までそれぞれの開発者でなんとなくだった考えが共有
この記事は会員登録で続きをご覧いただけます申込は簡単3分！ 今すぐ会員登録（無料） 会員の方はこちら 有料会員（月額プラン）は初月無料！ 詳しくはこちら ▼日経クロステック有料会員になると… オリジナル記事がすべて読める 専門雑誌7誌の記事も読み放題 雑誌PDFを月100ページダウンロードできる
ABOUT SEIRYOU GROUP 清凉グループについて 清凉グループでは、「あふれる笑顔～慈悲の心で～」を経営理念として掲げ、 地域における介護・保育ニーズにお応えすべく、複数の施設を運営しております。 今後も地域の皆様の生活に寄り添う場所として、個々の施設と連携し、よりよいサービスを追求していく所存です。 清凉グループからのお知らせinformation
職場ではここ数年Trac + Mercurialを使っているのですが、リポジトリを作成したりユーザを追加するのに毎回サーバ上でスクリプトを叩いたりするのが面倒なのと、SourceTreeを使えばチームメンバーのみんなも直感的に使えそうなのと、あとTracよりもGithubのほうがIssueやWikiが使いやすいということでGithubクローンへの移行を検討しています。 IssueとWikiは必須なので、消去法でGitLabを試しているのですが、インストールがなかなか面倒な上にバグも多いとのこと。GitblitはJavaベースらしく導入は簡単らしいのですが、これはリポジトリビューアのみでIssueやWikiなどの機能は備えていないようです。 しかしこの手のツールってなんで揃いも揃ってRubyとかPythonのようにインストールの面倒なもので実装されてるんでしょうか。Javaで実装されていれば
例えばgit-resetなどをする時などにHEADの2世代前のコミットにHEADを移す場合は HEAD^^としたりHEAD~2としたり。でもHEAD^2という指定もあります。そのへんのまとめ 題材としてアイドルマスターシンデレラガールズ(以下モバマス)で考えます。 まず、適当にリモートリポジトリを作った後git-cloneして最初のgit-commitを行います。 その後、運営の犬であるちひろさんを追加します。ここまでは共通作業ですのでm@sterブランチで行います モバマスはキュート、クール、パッションの3属性があるので3属性分のブランチを作ります。 次に、いわゆる2コスと呼ばれている各属性のコスト2アイドルを追加していきましょう。 キュート:島村卯月 クール:渋谷凛 パッション:本多未央 キュートブランチ $ git co master $ git co -b cute 島村卯月はノー
続編のような物(2012/11/21追加) 掲題の件について最近調べたことをまとめることにします。 はじめに タイトルだいぶ誇張していますが、結論から言うとマージコミットを発生させないGitの使い方です。 マージコミットが悪という言葉を最近よく目にしていたのですが下記リンク先の説明でしっくり来ました。 マージコミットの分割が１本線の履歴の分割よりも困難となる理由 そのためマージコミットが発生しないような使い方を目指します。 また、A successful Git branching modelを実現するためのgit-flowというもののありますが今回は触れません。 (ちなみにA successful Git branching modelではマージコミットは必ず残すことを推奨しています) Non-Fast-Forwordマージでの利点はブランチでの作業履歴が残ることと認識しています。 Fa
自分の開発環境だけでできてしまうようなファイルのために、プロジェクト内の.gitignore に設定追加してしまうと他の人に嫌がられますよね。そこで、自分用に追加でホームディレクトリの.gitignore ファイルを利用するようにします。 $ git config --global core.excludesfile ~/.gitignore Gitを使い始めたらやっておきたい便利な設定いろいろ - アシアルブログ まさにその通りなのですが、初めて Git を使うときには「何を gitignore に設定すればいいのかわからない」かもしれません。そんなときには、GitHub - github/gitignore: A collection of useful .gitignore templates を参考にしましょう。"A Collection of Useful .gitignore
平素よりイベントカレンダー＋ログをご利用いただき、誠にありがとうございます。 イベントカレンダー＋ログは「IT・製造業・ビジネス関係のイベント（セミナー・展示会・勉強会・コンテスト・Webイベントなど）を開催する企業・コミュニティが登録したイベント情報のポータルサイト」として約7年間運営をしてきました。これまでサービスを続けることができたのは、イベントカレンダー＋ログのコンセプトに共感をいただき、適切なイベント情報をお寄せいただいた皆さまのご支援があったからこそと考えております。重ねて御礼申し上げます。 しかしながら、イベント情報の入手方法の多様化やイベント紹介サービス市場の状況、＠ITの今後のメディア運営方針などを検討した結果、2020年6月30日（火）15:00をもちましてイベントカレンダー＋ログのサービスを終了することにしました。 これまでご利用をいただきました皆さまには残念なお知ら
PHPの世界征服が取り消されたのを見たので、いつからPHPが世界を支配していると錯覚していたのか調べました。 $ git clone https://github.com/php/php-src Cloning into 'php-src'... remote: Counting objects: 501255, done. remote: Compressing objects: 100% (101391/101391), done. remote: Total 501255 (delta 399216), reused 500633 (delta 398654) Receiving objects: 100% (501255/501255), 111.43 MiB | 4.70 MiB/s, done. Resolving deltas: 100% (399216/399216), d
git pullは使わなくてもよい 初心者はgit pullを使わない方がよい 我々ソフトウェアエンジニアは勉強が大好きなので、コマンドがあるとそれを勉強して使いこなさなければいけないと考えがちですが、ときには「覚えない、使わない」という発想も大事なのではないでしょうか。 以下にその理由をのべます。 git pullは使う必要がない git pullを使わないとできないこと、というのはありません。 使わなくても全然困りません。 git fetchとgit mergeとgit rebaseだけですべての用は足せます。 私はチーム開発でGitを本格的に使い始めて数か月経ちますが、普段の作業でgit pullを使ったことはないしそれで困ったこともありません。 git pullを使わなければ、余計な落とし穴に落ちない git pullには落とし穴があります。 初心者はたいていその穴に落ちます。 「
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
