などにすごく時間がかかる、ということがあります。 いろいろ調べて、ある程度は改善できたので、メモ。 preloadindex 設定 こちらを元に
git commit --fixup というオプションの存在を最近知って調べた。 ヘルプとリリースノートより "git commit" learned the --fixup and --squash options to help later invocation of interactive rebase. Git v1.7.4 Release Notes --fixup=<commit> Construct a commit message for use with rebase --autosquash. The commit message will be the subject line from the specified commit with a prefix of "fixup! ". See git-rebase(1) for details. 1.7.4 から入って
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
CompanyEngineeringProductSunsetting AtomWe are archiving Atom and all projects under the Atom organization for an official sunset on December 15, 2022. January 30, 2023 Update: Update to the previous version of Atom before February 2 On December 7, 2022, GitHub detected unauthorized access to a set of repositories used in the planning and development of Atom. After a thorough investigation, we hav
id:koogawaさんのgitの記事を読みました。 これを読んでそういえばみんな知ってるのかなと思った点があるので書いておきます。 取り上げるのはgitのpush周りのお話です。 (これ以降の記事中のリモートは全てoriginとします。) このコロンは何?? リモートブランチの削除で以下のようなコマンドを実行すると思います。 git push origin :hoge コロンが付いていますがこのコロン正体、正しく説明できますか? 実用Git 作者: Jon Loeliger,吉藤英明(監訳),本間雅洋,渡邉健太郎,浜本階生出版社/メーカー: オライリージャパン発売日: 2010/02/19メディア: 大型本購入: 7人 クリック: 287回この商品を含むブログ (44件) を見る pushコマンドの実体 普通、ローカルブランチをリモートに反映する際のコマンドはこんな感じです。 git p
はじめに 「プロジェクト管理ファイルについて」三部作の最後は、.ideaディレクトリについてです。無駄に長いので、もうオススメ設定を公開しておきます。 リスト1 オススメのHOME>/.idea/.gitignoreの例 *.xml !/codeStyleSettings.xml !/copyright/*.xml !/fileColors.xml !/encodings.xml !/gradle.xml !/runConfigurations/*.xml !/inspectionProfiles/*.xml /inspectionProfiles/profiles_settings.xml !/scopes/*.xml /scopes/scope_settings.xml !/templateLanguages.xml !/vcs.xml なぜ、こうしたかは本編のお楽しみです。 プロジェ
ある行の変更がどういう経緯でなされたか知りたい時に。 リファクタリング等々の原因でgit blame一発では知りたいChangeに辿りつけないことありますよね。 $ tig blame gitコマンドだけではさすがに厳しいので、vim風インターフェースのtigを使って とする。 この画面上で、以下の操作を繰り返すことで、コミット履歴をたどっていける。 Enter: カーソル行のコミット内容を表示 ,: カーソル行のコミットの親のコミットにblameを適用 他に使いそうなtigコマンドとしては h: tigで使えるコマンド一覧を表示 Tab:ビューのフォーカスを切り替え q: 現在のビューを閉じる ちなみに一度、,を押してしまうと、前の画面に戻る方法はないらしい。そんな時はqまたはQで一から閉じてやり直し。 まぁ、これ以上求めるなら、GUIツールを使ってください。 $ git log -S/
Gitによるバージョン管理では、従来のSVNなどよりずっと簡単にブランチングやマージができます。さまざまなブランチ戦略やワークフローが可能であり、以前のシステムに比べるとほとんど全てが改善されたと言えるでしょう。しかしGitを利用する多くの組織はワークフローの問題に直面します。明確な定義がなく複雑で、Issue Tracking Systemと統合されていないからです。そこで、明確に定義された最良の実践的方法としてのGitLab flowを提案したいと思います。issue trackingには feature driven development と feature branches を組み合わせます。 他のバージョン管理システムからGitに移行する際によく耳にすることは、効果的なワークフローの開発が難しいということです。この記事ではGitワークフローとIssue Tracking Sys
git は、コードベースの発展過程を記録し、開発者間の協同作業を効率化する強力なツールです。でも、記録対象のリポジトリがとてつもなく巨大なものになったときは何が起こるのでしょうか? この記事では、いくつかの異なる意味での巨大化に正しく対処するためのアイデアと手法を少し紹介してみたいと思います。 二種類の 巨大なリポジトリ よく考えてみると 巨大なリポジトリ が生ずる理由はおおまかに言って二つあります: 非常に長い期間にわたって履歴が積み上げられた (プロジェクトが非常に長い期間継続的に拡大を続けたために開発成果が積み重なった) 場合 巨大でしかも履歴の記録が必要なバイナリ データが存在し、それがコードに反映される場合 その両方の場合 即ち、リポジトリの巨大化は二つの異なる方向に向かって起こることになります。それは、作業ディレクトリのサイズ (即ち直近のコミットのサイズ) の問題と全体の履歴
以前gitで一度行った変更をなかったことにする方法4つを紹介しましたが、 日常的に git を使用していると他にも様々な 「なかったことにしたい」「元に戻したい」 という状況に遭遇します。 そのひとつひとつについて対処方法を紹介していきます。 目次 問題1: ライブラリの新機能を試すためにあれこれ適当なコードを書いてみた。でももう要らない。問題2: トピックブランチをマージしたけど実はまだ不完全だった。マージをやり直したい。問題3: リリース後に発覚したバグ。原因は30日前に自分が行ったコミットだった。なかったことにしたい。問題4: 新しいコミットしようとして間違えてgit commit –amendで書き換えてしまった。元に戻したい。問題5: 色々作業していたら作業ディレクトリの内容が混沌としてきた。一度綺麗な状態にしたい。問題6: 作業ディレクトリにゴミファイルが溜まってきた。一度綺麗
Frontrend Vol.6 powered by CyberAgent, Inc. http://frontrend.doorkeeper.jp/events/6907 で発表したプレゼン資料です。 こういう資料に対する投げ銭的なのがどうなるのか気になっていたので、もしよろしければ・・・!15円からできるソーシャルカンパサービスだそうですm(_ _)m http://kampa.me/t/dev
Jenkinsのジョブ1つに対して複数のGitリポジトリを登録してビルドする方法について調べたのでメモ。簡単にできると思いきや意外とハマってしまった。。。 確認した環境 Jenkins 1.456 Jenkins Git Plugin 1.1.16 Jenkins Multiple SCMs plugin 0.2 Jenkins Git Pluginのみではできない!? まずはJenkins Git Pluginの設定のみでできないか試してみたのだが、残念ながらこの方法は失敗。一応設定方法を紹介すると以下の通り。 ジョブの設定で、ソースコード管理システムにGitを選択しつつ、Repository URLにGitリポジトリのURLを設定する。 さらに、Repository URLの下にある追加ボタンをクリックするとRepository URLの入力項目を増やすことができるので、ここに別プロジ
任意のブランチをmasterブランチにマージする前に、Jenkinsで静的分析やテスト実行をしたいというニーズがあったので、任意のブランチにpushしたら CIできるように設定をしてみました。 環境構成 OS: Amazon Linux AMI 2013.03 64bit Git: 1.7.4.5 Jenkins: 1.505 Jenkins設定 ジョブ設定 ビルドのパラメータ化 → パラメータの追加 → 文字列 下記のように、「名前」と「デフォルト値」を設定する ソースコード管理システム → Git → Branches to build 下記のように、「Branch Specifier (blank for default):」に先ほど設定した変数 $branch_name を設定 ただ単に、Jenkinsの画面で毎回ビルド実行をするだけでしたらこれで設定は終わりです。 あとは下記
この前作ったスクリプトをより改良しました。 SourceTree で指定のリビジョン間の差分ファイルだけ取り出したい ターミナルでも使えますが、SourceTree のカスタムアクションで使うほうがわかりやすいです。 こんな感じの機能が git export みたいな感じで実装されてればよいのですが…。 このリポジトリをクローンしてください。必要なのはスクリプトだけなので、アーカイブでもファイルだけでもいいです。 44uk/git-export-tools: export files from git repository 任意の場所に保存したら、SourceTree のカスタムアクションに登録します。 引数としてハッシュが必要なので $SHA を Parameters に画像のようにセットします。 後は、リビジョン一覧から取り出したいリビジョンを選択して、アクションを呼び出してください。
The entire Pro Git book, written by Scott Chacon and Ben Straub and published by Apress, is available here. All content is licensed under the Creative Commons Attribution Non Commercial Share Alike 3.0 license. Print versions of the book are available on Amazon.com. The version found here has been updated with corrections and additions from hundreds of contributors. If you see an error or have a s
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く