ブックマークしました ここにツイート内容が記載されます https://b.hatena.ne.jp/URLはspanで囲んでください Twitterで共有
![『バージョン管理したくない作業用スクリプトは「,」ディレクトリに入れるといい - Qiita』へのコメント](https://cdn-ak-scissors.b.st-hatena.com/image/square/6bfd558d3f00272fd614e55e2c1cf67bbae6dc88/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-9f5428127621718a910c8b63951390ad.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTkxNiZoPTMzNiZ0eHQ9JUUzJTgzJTkwJUUzJTgzJUJDJUUzJTgyJUI4JUUzJTgzJUE3JUUzJTgzJUIzJUU3JUFFJUExJUU3JTkwJTg2JUUzJTgxJTk3JUUzJTgxJTlGJUUzJTgxJThGJUUzJTgxJUFBJUUzJTgxJTg0JUU0JUJEJTlDJUU2JUE1JUFEJUU3JTk0JUE4JUUzJTgyJUI5JUUzJTgyJUFGJUUzJTgzJUFBJUUzJTgzJTk3JUUzJTgzJTg4JUUzJTgxJUFGJUUzJTgwJThDJTJDJUUzJTgwJThEJUUzJTgzJTg3JUUzJTgyJUEzJUUzJTgzJUFDJUUzJTgyJUFGJUUzJTgzJTg4JUUzJTgzJUFBJUUzJTgxJUFCJUU1JTg1JUE1JUUzJTgyJThDJUUzJTgyJThCJUUzJTgxJUE4JUUzJTgxJTg0JUUzJTgxJTg0JnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmdHh0LWNsaXA9ZWxsaXBzaXMmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz0yNmU1Zjk0MDk1OThmNzg1ODVhOWMwMGRmOWFmZDRiNg%26mark-x%3D142%26mark-y%3D112%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTYxNiZ0eHQ9JTQwdWFzaSZ0eHQtY29sb3I9JTIzMjEyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTM2JnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnM9Y2ZkNzYyNjlkOGRhOGE3MWMyYzQwYjJmNjkxZTRhNmU%26blend-x%3D142%26blend-y%3D491%26blend-mode%3Dnormal%26s%3Df4d36b50bf5f77b1bbf13f6667420818)
git commitを行う際、任意の名前・メールアドレスで行いたい時、ありませんか? だからといって、以下のように一時的に変更して元に戻すのも面倒ですよね。 そんな時にオススメしたい方法、あるんです。 グローバル設定を変更する ホームディレクトリ/.gitconfigで定義する情報を変更するコマンド $ git config --global user.name "John Doe" $ git config --global user.email johndoe@example.com ローカルリポジトリ設定を変更する リポジトリ/.git/configで定義する情報を変更するコマンド $ git config user.name "John Doe" $ git config user.email johndoe@example.com ユースケース sudo git commit -
git log 使い方 コミットログを表示する git log とするとページャが起動して(設定による) コミットログが表示される。 パッチ形式のコミットログを表示する コミットログと変更点のパッチ形式を表示するには「-p」オプションを使う。 git log -p コミットログとファイルの変更の状態を表示する git log --stat とすると diffstat が表示される。また、 git log --name-status とすると変更されたファイルの名前とステータスが表示される。 コミットログを指定した数だけ表示する たとえば、最近のコミットログを 5 つだけ表示するには「-<num>」か「-n」オプションを使って git log -5 git log -n 5 とする。 特定の範囲のコミットログを表示する 「<since>..<until>」で指定する。 たとえば、 git l
git管理下にある複数のファイルをrmしたときに、それらを一括してgit rmしたい場合の方法です。 git ls-filesコマンドは、gitの管理状況ごとにファイルを一覧表示するためのコマンドで、上のように--deletedを使えば削除されたファイルを表示します。他にも --unmergedでコンフリクトしたファイル表示、--excludeを使えば管理外のファイルの非表示条件も設定できます。 シェルでは「`」でくくればコマンドの実行結果を取得できるので、それによって得られたファイル一覧をgit rmで消す、という流れです。 一括削除する方法では、これ以外にもgit stをgrep deletedしたのを整形するなど色々と手段はあるようですが、上記の方法が一番シンプルで分かりやすいので使っています。 Register as a new user and use Qiita more co
インターネットには、Git submodule を使っては いけない という記事が飛び交っています。私はこれらの記事が言うほどひどいものとは思っていませんが、そういった主張が大方正しいことは認めます。以前の投稿でも説明しましたが、submodule は利用価値のあるユースケースは少なく、逆にいくつもの欠点があります。 では、これに代わるものはあるのでしょうか? 答えは「ある」です。Git の利用は続けつつ、プロジェクトにおけるソフトウェアの依存関係を追跡することができるツールが (少なくとも) 二つあります : git subtree google repo この記事では、git subtree に注目し、完全とまではいえないもののそれが git submodule の問題を解決するものであることを説明しようと思います。 実例としていつもの私のユースケースを取り上げます。自分の dotfi
ライブラリやフレームワークなど、外部のリポジトリで管理されているソースコードをプロジェクトに取り込む際によく使われているgit submoduleを使わないほうが良いという論争が起こっています。それを受けてgit subtreeを使うべきであるというエントリがAtlassianのNicola Paolucci氏がブログに投稿しています。彼はまずgit submoduleを使うべきではないという話題が盛り上がっているという事で3つの記事を参照したあとに、git subtreeを使うべき理由と使用例を挙げています。それによるとgit subtreeを使うべき理由は以下のとおり。 ワークフローがシンプルなので管理が簡単。 古いバージョンのgitもサポートしている。(v1.5.2ですら。) サブプロジェクトのコードがcloneした直後に利用できる。 subtreeはユーザに新しい学習を要求しない。
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
はじめに この記事は How to write the perfect pull request - GitHub を和訳というか、意訳した記事です。 ご指摘などありましたら大歓迎です! 良いプルリクエストを書くには (原題 : How to write the perfect pull request) 会社が成長していくと、人もプロジェクトも様変わりしていきます。GitHubの中に私達が望む文化を育んでいくためには、我々が何を自覚してコミュニケーションするべきなのか分かってきました。私達のチームが最強であり続けるために、最近以下のようなプルリクエストのガイドラインを導入しました。 プルリクへのコメント (原題 : Approach to writing a Pull Request) プルリクエストには目的を明記しましょう。たとえば… これは〜を調べてみるためのプロトタイプです これは
Git の pull / merge が --no-ff だと 自分の Mac と会社の Mac で wada811/dotfiles を更新/同期していると 以下の画像のようにマージコミットが増えていってコミットグラフも分岐してしまいます。 ただ異なる環境で編集しているだけなのに このように本質的でないコミットが増えていくのは本意ではありません。 git pull --ff-only で実行すれば良い上の例では確かにそうです。 しかし、 Brewfile + Homebrew + Homebrew-caskで Mac の環境構築をする | DevAchieve で書いた HomeBrew / HomeBrew-cask の更新では brew upgrade で内部的に git pull が実行されるので、 オプションを付けることができません。 個人的な設定により Non Fast-for
Git2.0がまもなくリリースされるようです。 Git v2.0 Release Notes リリースノートをもとに、一足早く新機能と変更点の紹介をしてみます。 (各機能についてはまだ動作確認しておりませんので、ここがおかしいなどあればご指摘ください) 引数なしのgit pushが安全になりました。 When "git push [$there]" does not say what to push, we have used the traditional "matching" semantics so far (all your branches were sent to the remote as long as there already are branches of the same name over there). In Git 2.0, the default is no
「オレは git の alias こんな風にしてるぜ!」っていう投稿とかブログ記事、よく見かけるし実際かなりお世話になっている(ありがとうございます)。…のだが。 誰も git show-branch のエイリアスを設定していなくて信じられない。そんな Git 歴 3 ヶ月の私が通りますよ。 $ git sb * [master] Add 'git show-branch'. ! [fixes] Introduce "reset type" flag to "git reset" ! [mhf] Allow "+remote:local" refspec to cause --force when fetching. --- + [mhf] Allow "+remote:local" refspec to cause --force when fetching. + [mhf~1] Use
古くから使われているdiffツールは、ファイルの変更箇所を正確に知るための情報を出力してくれるので、ソフトウェア開発に欠かすことができないツールといえるでしょう。しかしその表示はどちらかといえば機械向けで、人間が直感的に変更点を知るためには向いていないのかもしれません。 その欠点を補うために開発された新世代のdiffツールが「icdiff」です。変更前/変更後のソースコードを横に並べ、かつ変更箇所をハイライト表示してくれます(上の図のように)。 diffを置き換えるものではなく、補助する差分ツールとして便利に使えそうです。 インストール Mac OS X / Linux用のインストール方法は以下の通り。 curl -s https://raw.githubusercontent.com/jeffkaufman/icdiff/master/icdiff \ | sudo tee /usr/l
$ sudo yum remove git $ sudo yum install gcc curl-devel expat-devel gettext-devel openssl-devel zlib-devel perl-ExtUtils-MakeMaker $ wget https://www.kernel.org/pub/software/scm/git/git-2.2.0.tar.gz $ tar -zxf git-2.2.0.tar.gz $ cd git-2.2.0 $ make prefix=/usr/local all $ make prefix=/usr/local install $ git --version git version 2.2.0 これでどうだ! // @clown0082 さん、GCC に関する編集リクエスト有難う御座いました m(_ _)m 途中の
Gitの使い方を覚えるにあたって、まず知っておきたいのは――git-cloneだのgit-commitだのは当然として――「操作をミスったときにどのように回復するか」である。それを実現するのは、次の3つのコマンドだ。 git-commit --amend git-reset git-reflog git-commit --amend あるファイルをコミットしたとしよう。 $ (edit...) $ git commit -am 'メッセージ生成処理を実装したよ。'しかし、しばらくして彼は気づいた。 def create_massage(param) ...typoしてる!massageじゃない、messageだ!マッサージを作ってどうする! 慌てるな。まずは直してステージに上げるんだ*1。 def create_message(param) ...$ git add .そして…。 $ gi
この記事は Perl Advent Calendar 2014 - Qiita の20日目の記事です。 19日目は id:y_uuki さんの Perlはもう古い、これからはDocker - ゆううきブログ でした! 普段みなさまごぞんじ hub でべんりなgitライフを送っているとおもうのですが bitはそのなかのうち"対応するwebページを見にいく"あたりを切り出したコマンド…みたいなものです。 ar-tama / Bit git remote -vして勝手にURLを取ってきてくれるので、Enterpriseなミナサマもhub configに振り回されなくてよいのと、デフォルトでbitbucketもサポートしているのがウリです。 本家のカスタマイズで対応できそうならそれでもよかったのですが、せっかくなので作ってしまいました。 自分自身でいがいとべんりに使えているので、このタイミングでg
Gitのコミットメッセージの書き方 自分なりにまとめてみました。Git歴浅いので、意見募集中です。 (2014年12月17日追記) 想像以上にたくさんの方にストックなりはてブなりいただいたので、はてブでなるほど!と思ったコメントをもとに少し修正・加筆してみました。 (2022年1月4日追記) 最新の書き方をこちらに書きました。 https://zenn.dev/itosho/articles/git-commit-message-2023 原則 以下のフォーマットとします。 1行目:変更内容の要約(タイトル、概要) 2行目 :空行 3行目以降:変更した理由(内容、詳細) 日本語でも英語でもOKですが、リポジトリで統一してください。 1行目 コミット種別と要約を書きます。フォーマットは以下とします。 [コミット種別]要約 コミット種別 以下の中から適切な種別を選びます。 (多すぎても悩むので
TL;DR: グローバルな gitignore に ,/ を追加して、作業用スクリプトを , ディレクトリに入れると便利。 ,/tmp_script.sh で実行できる。 Git リポジトリの中に一時的に使う作業用スクリプトを置いておきたいことがある。自分だけが使うものなのでコミットはしたくないが、いちいち .git/info/exclude に追加して無視させるのも面倒臭い。 今まで自分は、 tmp_script.sh~ や tmp_script.sh.bak など、グローバルな gitignore で無視されるファイル名にしていたが、これは不要なファイルと間違えて消してしまう危険がある。 ignored.tmp_script.sh は分かりやすいぶん長い。 _tmp_script.sh は悪くないが、コミットすべきファイルにもアンダースコアで始まるものがあって紛らわしい。 そこで、作業
はじめに RubyのコミッターでもありRailsなどの多くのOSSで活躍されているMarc-André Lafortune さんのブログに面白い記事があったので筆を取りました. (許可は取りましたヨ) Why I Won't Squash My Commits *注釈 [...] で記された文章は原文には存在しない私の注釈であるので留意されたいです. 翻訳に至らない所があれば編集リクエスト待ってます. 要約 PR,feature単位でcommitをまとめるかどうかでRailsのプロジェクト上などで揉めた. それぞれのcommitは独立してるいるはずだからまとめる必要はない 仮にどうしてもまとめたいなら自分でやるべきだし人にその考え方を押し付けるな (まあ実際は皆いい人だから理解してくれるけど) この方は徹底してcommitを最小の変更単位で分けて、 それぞれが独立してテストを通るように心が
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く