日経クロステックNEXT開催記念キャンペーン！ ＞＞詳しくは 日経クロステック有料会員になると… ・専門雑誌7誌の記事が読み放題 ・注目テーマのデジタルムックが読める ・雑誌PDFを月100pダウンロード

バックエンドエンジニアのKazです。 昨今では、エンジニアにとってほぼ必須ツールとなった、ソースコードのバージョン管理ツール「Git」。今回はGitについて、ちょっと上級ですが、使いこなせばとても便利なコマンドを集めてみました。 なお、記事中のコマンドはすべて最新版のGitを想定しています。一部古いバージョンでは動作しないものも含まれていますので、バージョンの差異で非対応の場合はご容赦ください。 用例 任意指定オプションについて コマンド例の角カッコ （[]）で囲まれたオプションは任意指定となります。 git log [-p] ↑この角カッコ内は任意指定 プレースホルダについて コマンド例の山カッコ（<>）で囲まれた値はプレースホルダとなります。下記に沿って適宜置き換えてください。 <branch>: ブランチ名 <path>: ファイルのパス <pattern>: 検索したい文字列やパタ

はじめに こんにちは、クレイの亀井です。ここ最近一気に気温が上がりましたね。顔に重点的に汗をかくタイプの私には憂鬱な季節がやってまいりました さて、今月正式リリースしました(！) DocBase プロジェクトではクレイ外部のデザイナーの方と一緒に開発しています。SourceTree で Git を使っている方で、軽いデザイン修正などは弊社の Rails プロジェクトに直接手を加えてプルリクエストを送ってくれます。 こちらのデザイナーさんに「プルリクエストを送る際は、作業ブランチで git pull --rebase origin master してから送ってもらえますか？」とお願いすると「pull はわかるんですけど、この --rebase ってなんですか？これつけると何が変わるんですか？」と質問がきたのです。 作業ブランチで git pull --rebase origin master

Git には MQ のようなパッチ管理はできないかと調べてみました。 MQ とは 分散バージョン管理システムと言えば有名な Git のほかに Mercurial SCM があります。 Mercurial には Mercurial Queue (MQ) という拡張機能があり、これを有効化すると、通常のチェンジセット (コミット) とは独立してパッチを管理することができるようになります。 JapaneseMqExtension - Mercurial 例えば、以下のような場合に使えます。 何かオープンソースソフトウェアの実装を調査したりデバッグする際に、標準にはないログを追加するとき 自分や自分のいる組織特有の事情があって、ソフトウェア本体を改変する必要があるが、改変箇所をメインブランチにコミットやマージをしたくない場合 MQ でパッチを管理するようになると、メインブランチのリビジョンが進んで

この投稿は Fujitsu Advent Calendar 2017 その2 の 5日目 の記事です。 この記事に書かれた見解は、個人のものであり、所属する会社・組織を代表するものではありません。 その2がまだ空いているので、以前社内の Blog に書いた記事を、転載で恐縮ですが、載せておきます。 なお、その1 に書いた記事がですます調だったのにこっちがである調になっているのは、時間の都合です。 1. git log の revision range (リビジョン範囲) Git で、コミット A から コミット B までのログを見るときは、こういうコマンドを叩く。 A, B は、それぞれコミットID だったりブランチだったりタグだったり。 履歴が、こういう具合にまっすぐなときなら、素直に理解できる。 (A から B と言っているのに、コミット A が表示されないのには、若干違和感を感じるか

なぜ作ったか ターミナルでの git 操作に tig を愛用してます。素晴らしいツールなんですが、マージが入り組んでくるとコミットグラフの線が途切れてしまったり、結構見るのがしんどくなります。tig と併用する目的で、入り組んだマージ履歴を見やすく表示可能な、テキストベースのコミットグラフ表示ツールを探していました。 そんな時、 Jan Engelhardt 氏が作った git-forest を見つけました。入り組んだマージ履歴も見やすく表示できるコミットグラフはいい感じなんですが、ハッシュ・日付・作成者・ブランチ名などの表示方式がイマイチに感じ、コードをいじっているうちに元とは結構違う見た目になりました。これを周囲の人にも使ってもらったところ「見やすい」と評判が良く、せっかくなので公開することにしました。 サンプル（スクリーンショット） というわけで、さっそくサンプルをご覧ください。まず

mainビュー m mを押すとmainビューが表示されます。 tigの起動時にも表示されるビューです。いわゆるgit treeのビューです。 enterでそのコミットの詳細を見れたり、C(shift+c)でcherry-pickしたりできます。 statusビュー s sを押すとstatusビューが表示されます。git statusのビューです enterでファイルの変更内容を見れたり、stage/unstage(add/reset)をしたりできます。 refsビュー r rを押すとrefsビューが表示されます。branch, tagsなどが一覧されます。 enterでmainビュー(git tree)が見れたり、C(shift+c)でcheckoutしたりできます。 logビュー l lを押すとlogビューが表示されます。git logです。 enterでそのコミットのdiffが見れたり

gitでaddとcommit同時にやって欲しい。aliasかな？ git config --global alias.add-commit '!git add -A && git commit' and use it with でaliasを張ったら git add-commit -m 'My commit message' のように実行できる。

既存のGitレポジトリを、GithubやBitBucketのようなホスティングサーバに移行したり、逆にローカルサーバのGitBucketやGitLabなどに移行したい場合、（乗り換えなど）まあ単純にpushすればいいやんと思ったら、思うような結果にならなかったり、面倒な手順になってしまったりしてしまった。 どうも自分のワーキングのレポジトリから飛ばそうとすると、tagだったりbranchだったりが移行できていないかったりするのです。 ぐぐると、いったんローカルにリモートと同名のブランチ作って(checkoutして)から、push --all, --tags とかしてる奴とかありますがそれは面倒だなぁやだなぁみたいな。 最終的には、これが一番楽な手順かなと思う手順に行きつけたのでここに記す。 $ git clone --mirror <SOURCE_REPOSITORY_URL> $ cd

初めまして。Qiitaにはいわゆる初投稿というやつです。今後も(あれば)よろしく。 軽い自己紹介 大学生やってます。後輩のコードレビューをする際に品質を下げずに楽をしたかったので、CIを用いることにしました。 この記事はJenkins等のCI環境を経験したことをなかった僕が手探りでやった内容になりますので、おかしい点があったら指摘してもらえるとありがたいです。 GitLabとGitLab CI ちょっとしたお話 GitLab CIはバージョン7までは設定したら使える、GitLab本体とは別の機能でした。 ですが、8にてGitLab本体と完全に統合された結果、特に設定しなくても有効になり、またUI面でも細かい部分が変化しています。既にあるブログの資料などが、若干runnerの扱いが異なったりするのはそのためです。 使う計算機資源 GitLab(Ver:8.4.2)用のサーバーが一台 CI R

masterブランチをエクスポートしたいとします。 mkdir /tmp/foo git archive master | tar -x -C /tmp/foo (必ず先に空のディレクトリを作っておきましょう。) export-ignoreが便利 export-ignoreという便利なオプションがあって、例えばexport時に"test"ディレクトリだけ除外するということができます。 $Id$展開もしてくれる ident属性が設定してあればファイル中の$Id$をキーワード展開してくれます。 $Id$ ↓ $Id: 547efb313cdee8eb3e37371f800f3bee3479c166 $ 参考：Git-のカスタマイズ-Git-の属性#リポジトリをエクスポートする mkdir /tmp/foo git checkout-index -a --prefix=/tmp/foo/ --p

GitリポジトリとDockerイメージレジストリを統合した「GitLab 8.8」リリース。開発や継続的統合のワークフローがシンプルに GitLabは、Gitリポジトリを中心とした開発ツール「GitLab 8.8」をリリースしました。 GitLabはGitリポジトリ機能の機能に加え、Wikiやイシュートラッキング、コードレビュー、アクティビティフィード、そしてテストやビルド、デプロイなどの自動化を行うGitLab CI機能などが統合された開発ツールです。 GitLab 8.8ではパイプライン機能が強化。パイプラインの状態を画面で参照できるようになりました。 もう1つの大きな機能強化が、Dockerイメージレジストリ機能の統合です。 GitLab 8.8には最初からDockerイメージのレジストリ機能が組み込まれており、インストールするとすぐに使える状態になっています。GitLab CIによ

アッド & コミット 変更されたファイルを選択します。 git add <filename> git add * を実行するとIndexに追加されます。 これは基本的な作業の一つです。 変更を実際に適用するには git commit -m "Commit message" を実行します。 変更がHEADに入りましたが、 リモートリポジトリには未だ入っていません。 変更のプッシュ この時点で、変更がローカルリポジトリのHEADに適用されました。この変更をリモートリポジトリに適用するには git push origin master を実行し、masterの代わりに適用のブランチ名を入れます。 もし既存リポジトリをクローンせずに使用した場合 git remote add origin <server> を実行すると、リモートリポジトリを登録する事が可能です。 これで変更を特定なリモートリポジト

サービス終了のお知らせ NAVERまとめは2020年9月30日をもちましてサービス終了いたしました。 約11年間、NAVERまとめをご利用・ご愛顧いただき誠にありがとうございました。

自分用メモ。 初期設定 基本コマンド コミット stash ブランチとタグ リモート操作 その他 初期設定 $ git config --global user.name "nabe" $ git config --global user.email "nabe-g@example.com" $ git config --global core.editor vi $ git config --global color.ui true $ git config --global core.pager 'less' $ git config --list $ git init $ git clone http://------/ 基本コマンド $ git status $ git log $ git log --oneline $ git log --pretty=oneline $ git