人間らしいGitのエイリアス | POSTD
断固としてコンピュータ言語を拒絶する 私の知っている最も一般的な .gitconfig は、ユーザ名の設定だけが記されたものです。そして、その次に一般的なものはこれです。 [alias] ci = commit cia = commit -a cam = commit --amend cama = commit --amend -a cl = clean cldf = clean -df res = reset resa = reset HEAD ... # 82 more 4-character aliases このコンフィグは、要するにあなたの頭の中のスペースをキーストロークに置き換えます。短縮コマンドのエイリアスを覚えれば、タイピング数の節約が可能です。しかし私はこれが好きではありません。私はタイプミスをしますし、睡眠不足なこともたまにあるので、このエイリアスではやりづらくなってしま
git blameによるSRP（単一責任原則）の定量化 - どこでも見れるメモ帳
はじめに ソースコードを静的解析することでSRP（単一責任原則）を定量的に算出します．*1 svn blameによるSRP算出*2を参考に、git blameによる算出をshで行ってみました． このSRP値が最大のモジュールが王様モジュールに相当します． # 単一責務性の違反指数（SRP） # SRP＝R＋U＋((L/100)－5) # R：修正リビジョンのユニーク数 # U：修正ユーザのユニーク数 # L：モジュールのライン数 function get_SRP() { local target_filepath=$1 echo $(( \ $(git --no-pager blame --line-porcelain $target_filepath | sed -n 's/^summary //p' | sort | uniq -c | sort -rn | wc -l) + \ $(
git push --force でなく git push --force-with-lease を使う - valid,invalid
前に社内チャットで流れてて初めて知った。 他人の変更を上書きするおそれのある git push --force でなく、最後に fetch したタイミング以降に他人が push していたら失敗する git push --force-with-lease を使う方が良い。 --force considered harmful; understanding git's --force-with-lease - Atlassian Developers Quipper では GitHub flow のような開発フローを採用している。 各開発者が feature branch を作成し、master / develop branch へ pull request を作る流れだ。 他人と修正箇所が重なってコンフリクトした際には rebase が必要で、 rebase 後の内容を push する際には
gitコマンド派閥 - 弥生開発者ブログ
Misoca開発チームのmzpです。 開発チームでgitコマンドの使い方について話したら、それぞれ使い方が微妙に違っていることが分かりました。せっかくなので、それぞれの人に、なぜその使い方をしているか聞いてみました。 一時的に変更を退避させる方法 作業を中断するときにするとき、作業中の内容を退避させる方法です。 git stash派 git stash で退避させる派です。 そして再開するときは、 git stash pop で退避させた内容を適用します。 使っている理由は「コミットする内容はキレイに保ちたいので、作業中の内容はコミットしたくない」でした。 適当にコミットする派 適当な内容でコミットし、あとで cherry-pick するなり、 rebase するなりする派です。 使っている理由は「退避した内容をリモートのブランチにpushしたいので、普通にコミットしている」でした。 pu
物理サーバを選定する際のポイント – Eureka Engineering – Medium
Eureka EngineeringLearn about Eureka’s engineering efforts, product developments and more.
Git 2.7 で .gitignore が便利になっている ｜ Tips Note by TAM
2016年1月に Git 2.7 がリリースされました。 色々なコマンドが増えたりしていますが、なかでも .gitignore に関する仕様追加が興味深かったのでまとめます。 .gitignore とは Git で管理したくないファイルを設定するためのファイルです。 たとえば .gitignore ファイルにこのように書いて置いておくと、 *.json /sample-folder 拡張子が .json のファイルと、 /sample-folder というフォルダ配下は Git で管理されなくなります(変更などがあっても無視される)。簡単ですね。 .gitignore の設定を、打ち消したい場合 ! 記法で、設定の打ち消しが可能です。 たとえばこう書くと、 *.json !required.json 拡張子が .json のファイルは無視されるのですが、 ! をつけた required.j
僕がよく使うGitコマンド14個 - Mitsuyuki.Shiiba
僕がよく使うGitのコマンドの整理をしておこうと思った。 1. git clone リポジトリから取ってくる まずはcloneするよね。手元にあってちょうど良い感じなのがmakingさんのjsug-shopだったので、これで進めてみる。 $ git clone git@github.com:bufferings/jsug-shop.git Cloning into 'jsug-shop'... remote: Counting objects: 299, done. remote: Total 299 (delta 0), reused 0 (delta 0), pack-reused 299 Receiving objects: 100% (299/299), 427.05 KiB | 193.00 KiB/s, done. Resolving deltas: 100% (96/96),
vc-mode-line - Shohei Yoshida's Diary
最近知ったのですが, vc-modeが mode-lineに表示している情報(VCS+branch名: gitリポジトリであれば Gitとmasterを表示)はファイルが前のコミットから変更されている場合と されていない場合で異なります. わかりづらいですが, 変更がない場合 VCSとブランチ名のサパレータが -, 変更があった場合は :になります. 変更なし 変更あり 見づらい・わかりづらい 上記で示した通り, 見づらいし, わかりづらいんですが, 有用な情報だなと思ったので, 別情報を表示することにしてみました. 現在のバッファの変更 hunk数の表示 現在お試し中. git-gutterユーザ限定ではあるが, (git-gutter:buffer-hunks)という APIで現在の hunk数を取得している. 変更内容にもよるが, 多すぎるとそろそろコミットしておかないとなぁという気
Gitのコミットハッシュ値は何を元にどうやって生成されているのか | メルカリエンジニアリング
こんにちは。サーバサイドエンジニアの @DQNEO です。 前回の「Gitのつくりかた」に続いてGitのコアな部分のお話です。 Gitのコミットハッシュ値とは何か Gitを使っていると必ずコミットハッシュ値というものが出てきます。9e47c22みたいなアレです。 これはある特定のコミットを指し示すIDとして使うことができます。 では質問です。 このコミットハッシュ値は「何を元に」「どうやって」計算されているでしょうか？ 「ある特定のコミット」とはそもそも何なのか この問題を考える前に、まず「コミットとは何か」を明らかにしておきましょう。 コミットというと「コミットする行為」すなわち「動作」のことを想像するかもしれません。 しかしGitの内部構造的観点から言うと、Gitが管理記録しているのはコミット行為の結果生成されたデータの方です。 この「コミットによって生成されたデータ」のことを「コミッ
「追跡ブランチ」って言うのやめましょう - Qiita
TL;DR 突然ですがクイズです。「追跡ブランチ (tracking branch)」という言葉の使い方で正しいのはどれだと思いますか？ origin/master はリモートリポジトリの master を追跡する追跡ブランチである origin/master はローカルの master に追跡される追跡ブランチである ローカルの master は origin/master を追跡する追跡ブランチである 現在の正解は多分3番です。過去には1番でした。 分からなかった方、分かったけど他人に「追跡ブランチ」と言って伝わるか不安な方。大丈夫です。正確な用語1で言い換えることにしましょう。 origin/master はリモートリポジトリの master を追跡するリモート追跡ブランチ (remote-tracking branch)である origin/master はローカルの master
git commit --fixup とは何か - 詩と創作・思索のひろば
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 から入って
Gitを使って差分ファイルと差分情報を簡単に納品するコマンドのメモ - Qiita
納品を行った後、修正依頼が来て修正対応後 納品する際に「差分ファイルと差分情報が欲しい」と言われることも多々あると思います。 この場合に手動でチマチマやっていると時間がかかりますが、Gitだと簡単に情報がまとめられるとのことなのでそれらの情報をメモしてみます。 やりたいことの流れ 初回納品 納品バージョンのタグを付ける 全てのファイルをZIPにする 修正依頼が来てファイルを修正する 修正バージョンのタグを付ける 差分ファイルをZIPにする 差分情報をメモする 初回納品/全てのファイルをZIPにする まずは納品したいブランチでタグを付ける。納品用ブランチを作っておくとよいと思う。 例としてtag名はv1.0 注釈付きタグ名付与
続・Git中級者に送る便利なコマンド群 - カイワレの大冒険 Second
前回の記事「Git中級者に送る便利なコマンド群」でははてブ経由で多くのコメントを頂きました。今回の記事では、頂いたコメントのうち、いくつか取り上げて、可能な限り補足をしたいと思います。 git push origin master -f 前回の記事で最も多くご指摘頂いたのがmasterに対するforce pushに関してでした。結論から言うと、これはやっちゃいけませんね。 forceが必要になるときでパッと思いつくのはgit commit –amend後であったり、git rebase後なのですが、これらは過去の歴史を書き換えているので、共同レポジトリとかでやってしまうと、他の人がpushできなくなってしまうのですね。 AさんのローカルレポジトリAと、BさんのローカルレポジトリBをもとに再現させてみましょう。ディレクトリAもディレクトリBもともに、リモートからcloneしてきたものです。
Gitのデータモデル
近藤です。こんにちは。Gitは様々な利用の仕方ができますが、その基盤となるモデルは8個だけの簡単なモデルです。これらのモデルを理解していない状態でGitを利用すると、あたかもリポジトリが壊れたように見えてしまいます。Gitは難しいと言われますが、そういう感想を持つ人はGitのモデルを理解していない事が多いようです。 今回はGitを構成する中心モデルと、基本的なコマンドを実行した時のオブジェクト関係を解説します。 基本概念 Gitの基本概念は大きく2つにわかれます。 GitObject Reference GitObjectはGitで管理するオブジェクトです。CommitなどがGitObjectです。Gitリポジトリである.gitを開くとobjects配下にあるファイルがGitObjectです。GitObjectはそのコンテンツをハッシュ化した文字列を元に、先頭2文字で配置フォルダ、残りの文
こわくない Git
8. コミットに入ってる情報 リビジョン (SHA-1 ハッシュ) 例: 23cdd334e6e251336ca7dd34e0f6e3ea08b5d0db Author (コミットを作成した人) 例: オープンソースプロジェクトにパッチを送った人 Committer (コミットを適用した人) 例: 受け取ったパッチを取り込んだ人 ファイルのスナップショット (tree) コミットで変更されたファイルを含むツリー（説明は省略） 1つ前のコミットのリビジョン 例: 4717e3cf182610e9e82940ac45abb0d422a76d77 9. コミットに入ってる情報 リビジョン (SHA-1 ハッシュ) 例: 23cdd334e6e251336ca7dd34e0f6e3ea08b5d0db Author (コミットを作成した人) 例: オープンソースプロジェクトにパッチを送った人 Co
git pull と git pull --rebase の違いって？図を交えて説明します！ | KRAY Inc
はじめに こんにちは、クレイの亀井です。ここ最近一気に気温が上がりましたね。顔に重点的に汗をかくタイプの私には憂鬱な季節がやってまいりました さて、今月正式リリースしました(！) DocBase プロジェクトではクレイ外部のデザイナーの方と一緒に開発しています。SourceTree で Git を使っている方で、軽いデザイン修正などは弊社の Rails プロジェクトに直接手を加えてプルリクエストを送ってくれます。 こちらのデザイナーさんに「プルリクエストを送る際は、作業ブランチで git pull --rebase origin master してから送ってもらえますか？」とお願いすると「pull はわかるんですけど、この --rebase ってなんですか？これつけると何が変わるんですか？」と質問がきたのです。 作業ブランチで git pull --rebase origin master
gitでのヤバイ！を取り消す方法 - Qiita
gitでよくある、やってしまった！を取り消す方法を紹介します。 gitを使っていると、「ヤバイ・・間違えてcommitしてしまった」「消しちゃいけないものをgit reset --hardしちゃった」とか色々なやばいがあります。 そのヤバイを取り消す便利な方法を備忘録として記録しておきます。 【case1】 commit内容が間違っていた。取り消して再度commitしたい 直前のcommitだけであれば、git commit --amendを使えば解決出来ます。 ファイルに修正を加えて、commit 間違っていた事に気づいたので、更に修正を加えた git addしてgit commit --amend これでOKです。 【case2】過去のcommitが誤っていた。commit自体を取り消したい よくあるようなパターン(私はやってしましますｗ)として、ローカルで作業してる時、 何か修正を加
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitLab/GitLab.com 勉強会
Gitでマージ済みのブランチを消す - @peccul is peccu
https://qiita.com/falsandtru/items/d81d844afaca8db2756e