英語コミットコメントに使えそうなオシャレフレーズを聞いたので、これを使ってドヤ顔コミットをしたくてやれるチャンスを虎視眈々と狙う毎日です v, x, g, z とかこのへんが入ってる単語だとなんかカッコ良さ増す。 tweak とかデザイナーにはだいぶ便利。 単語 意味
![英語コミットコメントに使えるオシャレフレーズ集](https://cdn-ak-scissors.b.st-hatena.com/image/square/840c72b6c5f9f594c1fece248309d3bcd11fb202/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-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTkxNiZoPTMzNiZ0eHQ9JUU4JThCJUIxJUU4JUFBJTlFJUUzJTgyJUIzJUUzJTgzJTlGJUUzJTgzJTgzJUUzJTgzJTg4JUUzJTgyJUIzJUUzJTgzJUExJUUzJTgzJUIzJUUzJTgzJTg4JUUzJTgxJUFCJUU0JUJEJUJGJUUzJTgxJTg4JUUzJTgyJThCJUUzJTgyJUFBJUUzJTgyJUI3JUUzJTgzJUEzJUUzJTgzJUFDJUUzJTgzJTk1JUUzJTgzJUFDJUUzJTgzJUJDJUUzJTgyJUJBJUU5JTlCJTg2JnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmdHh0LWNsaXA9ZWxsaXBzaXMmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz05MDkxMTFmOGI0ZDE3ZDAyNzJkODRjZDI5MDlmMjNmZA%26mark-x%3D142%26mark-y%3D112%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTYxNiZ0eHQ9JTQwa2VuX2NfbG8mdHh0LWNvbG9yPSUyMzIxMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT0zNiZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZzPTYxZTc3NzdhN2ZmODE5OWFhNjA3ZDQ2NmRhMjQyNDc3%26blend-x%3D142%26blend-y%3D491%26blend-mode%3Dnormal%26s%3D40b099be45b6fa13b180209207ce6729)
gitのリモートリポジトリが更新されているかどうかを確認する方法はいくつかあります。 方法1: git fetch 後にdiffをとる 方法2: git ls-remote コマンドを使用する git ls-remoteを使用することでリモートリポジトリのコミットIDが取得できます。 リモートリポジトリの最新コミットID(HEAD)とローカルの最新コミットID(HEAD)を比較し、その2つが異なっていれば差分があると判断できます。 さらに、リモートのコミットIDが過去に存在しないものであれば、ローカルのリポジトリが古い(マージしていないコミットがリモートに存在する)ことになります。 $ git ls-remote origin HEAD 78ddd44eb3b76017a55014f27d9f846054dfa52b HEAD $ git log -1 HEAD # or master c
SubversionからGitに移行する過程で、空のディレクトリをリポジトリに追加するのを忘れないようにしないといけません。Gitは空のディレクトリはバージョン管理しないので、何らかのファイルを置く必要があります。何らかのファイルは.gitignoreやemptyなどありますが、個人的にはRails風に.gitkeepを置くようにしています。 基本的には、find . -type d -name .git -prune -o -type d -empty -exec touch {}/.gitkeep \; を実行すればOKです。今回は作ったツールは、.gitkeepを配置する前にどのディレクトリが空っぽか確認する機能や、このコマンドの.gitkeep部分を指定できたりなど、オプショナルな機能を追加したものです。 使い方 空っぽのディレクトリ一覧を出す:
git の記事などを見ていると、よく rev-parse というコマンドが出てきます。 rev-parse単体でググっても使い道がよくわからないので、メモ変わりにrev-parseでできることをここに書いてみます。 【参考】 git-rev-parse(1) Manual Page https://www.kernel.org/pub/software/scm/git/docs/git-rev-parse.html 使用可能なリファレンス(ref)を渡すとハッシュを返す ハッシュ $ git rev-parse 1838ad4786...02cc4e713a >> 02cc4e713a10dc68bcba40919f0f23eb62b45ec4 >> 1838ad478661d8cdb544c9adf921d08a97f7cc91 >> ^02cc4e713a10dc68bcba40919
社内やオープンソースのプロジェクトに並行して参加していると、gitconfig の user.name や user.email をリポジトリごとに切り替えたくなることがある。リポジトリを作るたびに git config user.name "My Name" すればいいのだが、 user.name が存在しないか空文字列だと環境変数 NAME の値を暗黙的に使う仕様になっているため、設定をうっかり忘れてしまうとなかなか気づけない。名前やメールアドレスを間違えたまま何度もコミットしてしまうと修正が厄介である。 Git 2.8以上 最近の Git で設定忘れを未然に防ぐには git config --global user.useConfigOnly true を実行する。これを設定するとユーザー情報について環境変数を暗黙に参照することがなくなる。グローバルな gitconfig で use
あるファイルに大量のコンフリクトが発生し解決が面倒なとき、パッチを使ってファイルに1コミットずつ変更を適用する方法を示す。この方法のメリットは: ファイルへの変更を1コミットずつ適用・コンフリクト解決することができる それぞれのコミットを適用する前に、コミットをパッチファイルの形で編集できる 注目するファイル以外への変更をいったん無視し、そのファイルに関係する変更に集中できる の3点である。複数コミットの変更が混ざった大量のコンフリクトマーカーを手作業で消すような状況に陥ったとき、この方法を使えばいくぶんかは楽にマージ作業を進められる。 概要 マージ中に特定のファイルに大量のコンフリクトが起きたら、マージを中止する。一時作業用ブランチを作り、そのファイルに1コミットずつパッチを当てて編集する。パッチを当て終わったらマージをやり直し、コンフリクト解決作業中に、コンフリクトしたファイルを一時作
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く