課題 うっかりmasterにコミットしてしまう事故がよく発生するので、そもそもpre-commitでコミットする前の段階でエラーで弾くようにした。 前提 mac OS 10.15.4 windows10 準備 git/hooks配下に「pre-commit」ファイルを用意する コード git symbolic-ref HEAD --shortで現在のブランチ名を取得 masterと文字列比較をすることで、自分が今masterブランチ以外のブランチにいるということを確認している #!/bin/sh branch=`git symbolic-ref HEAD --short` if [ ${branch} = master ]; then cat <<\EOF エラー：masterブランチにcommitはできません。 EOF exit 1 fi

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

このスライドは昨年の新人研修でgitについて話した内容をまとめたものです。 addしてcommitしてpushしてpullしてというコマンドを使いこなせるようになったけど、裏側の仕組みはわからないという人向けにまとめてみました。 ハッシュ値を見てみようコミットすると下の図のように謎の英数字の羅列が出てきます。 この値は、一体何でしょうか？ ハッシュ値はファイル内容に基づいて計算される160ビットに集約されるランダムな値です。 試してみようではここで、実際に手元でディレクトリをつくってみましょう。 下記の図のようにコマンドを叩いて見てください。 GUI上では右の図のように何もない状態かと思います。 次にgitを使えるようにしてみましょう。 フォルダのなかみを見てみると.gitというファイルができていることが確認できます。 それでは、コマンドを叩いて作られた.gitファイル 中身はどんなものが

つい最近、Sublime TextがGitクライアントSublime Mergeをリリースしたと話題でしたが、私も使っているAtomエディタの方は2017年6月にGit/GitHubとの連携に対応して...

2018年3月27日にSupporterZ CoLabで行われたgit勉強会の資料です。

レポジトリ内でドキュメントを探している時に、特定ディレクトリの中のファイルをgitのcommit日の順に並べて新しめのファイルを見つけたいなーと思ったことがあったのでやってみた。 例えば https://github.com/golang/go のdoc/以下にある全てのファイルをcommit日時順に一覧してみるには、以下のコマンド一つで良い。 $ git ls-files doc | xargs -I@ bash -c 'echo "$(git log -1 --format="%aI" -- @)" @' | sort -r 2018-01-11T11:30:49-05:00 doc/go1.10.html 2018-01-11T10:41:03-08:00 doc/go_spec.html 2018-01-09T15:32:22-05:00 doc/diagnostics.html

Eureka EngineeringLearn about Eureka’s engineering efforts, product developments and more.

ターミナルから tig refs と打つと refs の一覧画面が表示されます。 さらに、refs の中から checkout したいものを選択し、 Shift + c を打つと、選択したものにチェックアウトすることができます。 大変便利な機能ですが、ローカルブランチだけでなくリモートブランチやタグも表示されてしまいますので、 ローカルブランチだけを見たい場合には表示される量が多すぎますし、 また、チェックアウト時には本当にチェックアウトをするか否かの確認の [Yy/Nn] を打たなければならず、確認を飛ばしたくなる場合もあるかと思います。 そこで、git のエイリアスとして、tig に倣い git refs を用意しました。 .gitconfig に [alias] refs = !git checkout $(git branch | peco | awk '{ print $NF }

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

photo by Chris Turner Photography ghq と peco を組み合わせてめっちゃべんりに使っているのだけれど、GitHub 上にあるリポジトリを取ってくるのは楽なんだけれど、まだリポジトリを作ってなくてこれから作るのが面倒だったので簡単に作れるようにした。 これまでは、ghq で適当な自分のリポジトリに移動して、cd ../ && git init hoge とかしていた。かつ、だいたいは README.md を作ってコミットする。この辺をまとめた。 これを .zshrc とかに書いておいて、使うとめっちゃべんりになる。README.md を作るのに、名前をキャピタライズしているところが Zsh じゃないと動かないと思う。 $ ghq-new test こんな感じでリポジトリの名前だけ指定すると、リポジトリと README.md を作って、そこに移動してくれ

誰にも質問されていないけど回答すると、ぼく個人としては「レビュー指摘事項を反映」的なコミットメッセージにはやんわり否定派で、どうしてそう変更すべきと思ったのかを自分の言葉で書く方がベターと思っています。 — juné29💩公式アカウント (@june29) January 11, 2017 140文字には納まらないな、と思ったのでちゃんとエッセイを書く人間になろう！ たとえばぼくがレビューを担当させてもらって「ここはAの方がよいと思いました」とコメントしたとして、そのときに「レビューで指摘された箇所を修正」というメッセージ付きのコミットが追加されたとする。そのあとぼくが思い直して「いや、他の箇所も考慮すると、やっぱりBの方がよさそうです」とコメントしたとする。また「レビューで指摘された箇所を修正」というコミットが追加される。 こういうやりとりだと、「レビュー」というプロセスというよりは「

友人が「ghqとpecoを使ったらlife changingだった」ととても感動した感じで話してて、えーいいなーと思ったので、ちょっとだけ触ってみた。 qiita.com 素朴なことだけまずやろうと、gitのcloneディレクトリにどこからでもpecoとghqでアクセスできるようにしようと思って上のリンクにある通りのことをざっくり実施。 function repo { local dir="$( ghq list -p | peco )" if [ ! -z "$dir" ] ; then cd "$dir" fi } という単純な関数を書いておいて、実行したところが以下 確かに超便利！！！ github.com に repo 関数が書かれた .zshrc をおいている。

［Chapter1-02］ Git機能を提供するWebサービス ファイルの変更、追加、修正などを管理する場所である「リポジトリ」は、自分のPCにも、ネットを介したサーバ上にも作成できます。サーバを設定するには専門知識を必要としますが、サーバ機能を提供してくれる便利なWebサービスのひとつがBitbucketです。 2015年6月24日／TEXT：大串 肇 使用するコマンド ――――――― $ git --version ――――――― ■ローカルリポジトリとリモートリポジトリ 前述（Chapter1-01）したように、Git によってバージョン管理を行う場所として指定した場所を「リポジトリ」といいます。自分ひとりだけで開発・制作、バージョン管理を行う場合は、リポジトリは自分のPCにあればよいでしょう。しかし、リポジトリをサーバに用意して、ネットを介してどこからでも利用したい、あるいはチーム

gitリポジトリの使い方を間違えると、非常に重くなってしまうことがあります。 巨大なファイルをコミットしてしまった 関連プロジェクトを1個のリポジトリにまとめすぎた まずは犯人を捜す 以下のコマンドで、コミットログをサイズと一緒に見ることができます。 git log --stat 眺めながら、怪しいコミットがいないか探してみましょう。 また、.git/objectsの中から重たいファイルを探して、バイナリエディタで眺めることでも、怪しいファイルの見当を付けられます。 巨大なファイルをコミットしてしまった gitはソースコード管理システムなので、巨大なファイルを管理するのには向きません。 ちょっとしたwordのドキュメントファイルや画像などは問題ありませんが、100MB以上もあるPSDファイルや動画ファイルなどを入れると、git statusなどの基本的な操作も含めて急激に遅くなってしまいま

復習 Git: GitHub のブランチを削除する． 手が滑って test-2 なんて情けない名前のブランチを GitHub に push してしまった． とりあえず，ローカルの test-2 ブランチは， $ git branch -D test-2 で消えた．あとは GitHub の test-2 ブランチを消すだけだ． GitHub でブランチを削除するボタンを探してみたのだが，．．． 見つからない．どうしよう． git push でリモートのブランチを更新git push はリモートリポジトリに変更を反映させるときによく使うコマンドだ． 通常は， $ git push だけでコマンドを実行するが，これは， $ git push プッシュ先リポジトリ ローカルのブランチ名:リモートのブランチ名 を省略した形だ．git push とだけ実行したときのデフォルト値は， $ git pus

私たちは最近、デジタルアセットとワークフローを管理し、スピードをアップさせ、製品提供に関する一貫性を維持するためにAtomic Designの考えを導入しました。 この記事では、アトミックな考え方の概略をお伝えし、私たちがどのように適用してきたかをシェアしたいと思います。BEMとGitの力を、少し借りました。 Atomic Designとは？ *すでにこの概念に馴染みがある人は、このパートを飛ばしたくなるでしょう。コーヒーでもいれて、” アトミックなUIキットを作る”から読んでください。* Atomic Designとは、 デザインシステム の構築に用いられてきた方法論です。この概念は 2013年に、Brad Frostによって生み出されました 。Bradはプロセスを表現するために化学とのアナロジーを用いていて、それによると、デザインは単純で再利用可能なパターンに分解できるというのです。

最近、自分のGitのコミットログを読み返してみたら、すごく分かりづらかったので勉強も兼ねて、Gitのコミットログのプラクティスを勉強してみました！ 🐰 Gitのコミットメッセージの書き方次のサイトを参考にさせていただきつつ、簡単にまとめてみました！ Gitのコミットメッセージの書き方 | プログラミング | POSTD Gitのコミットメッセージの書き方 - Qiita 書き方を知ることのメリットGitのコミットメッセージをわかりやすく残すことで、その変更どんな目的で具体的にどんなことを修正したかを 次の変更を行う人に伝えることができ、次の人の修正する時間を節約できる。 具体的にどんなことを書くべきかどのように変更を行ったかは、コードを見れば分かる。もしわからないのなら、コードにコメントを書くべき。 変更した理由を明らかにすることに焦点を絞り、変更前がどうで、何が問題で、今はどのように機

Git に同梱されている contrib/diff-highlight を使います。 あとは README に書いてあることの引き写しですが、PATH の通ったディレクトリに置いて、~/.gitconfig に以下のように設定を書く。 [pager] log = diff-highlight | less show = diff-highlight | less diff = diff-highlight | less すると、対応するコマンドの出力がこんな風になります。 行レベルの diff に加えて、単語レベルでの diff もハイライトされ、GitHub での diff のように描画されました。 組み込みのオプションで --color-words というのがありますが、こちらを使うと行レベルの diff 情報が失われるので、少し不便だったわけですね。とすべて README に書いてあ

こんにちは。 もうすぐお花見の時期*1ですね。Misoca開発チームのtaiki-tです。 開発チームに聞いたところ、人によってエイリアスの設定に違いがあったので、比べてみました。 対象はZshとGitの設定です。 ちなみに、この間インターンの方の送別会と打ち上げ的なものがあって楽しかったです。 写真: 「commit -m '開発チームと愉快な仲間たちの巻'」 Zsh編 ls たかがls されどls。 lsのエイリアスにも様々なものがあります。 よく使うオプションと合わせてエイリアスにしているようです。 alias la='ls -a' # dot(.)で始まるディレクトリ、ファイルも表示 alias la='ls -al' # -a オプションと -l オプションの組み合わせ alias ll='ls -lav' alias ll='ls -l' # ファイルの詳細も表示 alias