GitHub - marionebl/commitlint: Moved to https://github.com/conventional-changelog/commitlintYou signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
デザインデータ管理をGit LFSにした話
みてねではデザインデータの管理にGit LFSを使用しています。 昨年から運用を開始したのですが、データ管理が改善され、フローも安定して回って来たので紹介します。 Git LFSとは？Gitで画像などのバイナリファイルを扱うための拡張機能Sketch, Photoshop, IllustratorなどのデザインデータもOKGitHubの単一ファルの上限である100MBを超えたデータサイズのファイルを扱えるファイルサイズの上限が変わる以外は通常のGitと同じです。 Git LFS 事前準備・設定リポジトリの作成github.comでデザイン用のリポジトリを作成します。 用意できたらリポジトリのSettingsでLFSを有効にするだけです。 みてねでは現状 2 data packs（月10ドル）使っています。 Storageが足らなくなっても Purchase more からポチるだけなので楽
「Gemfile.lockをgitレポジトリに入れるべきではない！」という主張をします。 - Qiita
きっかけ 「xxxx.lock」(以下lockファイル)みたいなファイルを作るパッケージ管理システムと、作らないものがありますよね。 作る側の例 : Gem(ruby)、cocoa-pods(iOS)、昔のcarthage(iOS)、YARN(js) 作らない側の例 : maven(java系)、最近のcarthage(iOS)、npm(js) 作る側を使っている人たちは、ほとんど「Gemfile.lockをgitにcommitしましょう」という旨の主張をしていますが、 ただ、cocoa-podsを使っている人たちの一部(2割くらいかな？)は、 「Podfile.lockをgit-ignoreするべきだ」という旨の主張をしています。 そこで、lockファイルを作る/作らないの違いと、gitに入れる/入れないの主張の違いが気になって調べて見ました。 そもそも、なぜlockファイルが必要なのか
コミットメッセージの書き方
コミットメッセージにはどのような情報を残すべきだろうか？はじめにこの記事ではGitのコミットメッセージの重要性と良いコミットメッセージの書き方を説明します。いままで良いコミットメッセージについて考えてこなかったかたも一度立ち止まって考えてみてくれると嬉しいです。 対象読者GitやGitHubを業務で使っている人「良いコミットメッセージ」をあまり意識しない人目次Gitを使ったソフトウェア開発で、なぜコミットメッセージが重要なのか？コミットメッセージの書き方の1例を紹介まとめGitを使ったソフトウェア開発で、なぜコミットメッセージが重要なのか？ソフトウェア開発において、良いコードとはどんなコードでしょうか？ 私は「 他人が読みやすく、理解しやすいコード」だと考えています。ソフトウェアにバグは必ず出ます。そのバグを修正する時間を最短にできるような、読みやすい、理解しやすいコードが良いコードだと思
CUIで見やすい git コミットグラフ: git-foresta 作った - Qiita
なぜ作ったか ターミナルでの git 操作に tig を愛用してます。素晴らしいツールなんですが、マージが入り組んでくるとコミットグラフの線が途切れてしまったり、結構見るのがしんどくなります。tig と併用する目的で、入り組んだマージ履歴を見やすく表示可能な、テキストベースのコミットグラフ表示ツールを探していました。 そんな時、 Jan Engelhardt 氏が作った git-forest を見つけました。入り組んだマージ履歴も見やすく表示できるコミットグラフはいい感じなんですが、ハッシュ・日付・作成者・ブランチ名などの表示方式がイマイチに感じ、コードをいじっているうちに元とは結構違う見た目になりました。これを周囲の人にも使ってもらったところ「見やすい」と評判が良く、せっかくなので公開することにしました。 サンプル（スクリーンショット） というわけで、さっそくサンプルをご覧ください。まず
空のディレクトリを維持するための、 .gitkeep と .gitignore の使い分け - Qiita
空のディレクトリをコミットに含めたいときは、2つのやり方があります。.gitkeep を使う方法 と、 .gitignore をおいておく方法（例えばPHPのフレームワーク Laravel で用いられている方法）です。 空のディレクトリを保持する目的で使用する .gitignore は、たいていの場合、以下のような内容になっています。 使い分けの基準 .gitkeep と .gitignore は、「空のディレクトリにファイルが追加されたときに、そのファイルを Git での管理対象に含めたいか？」という基準で、使い分けられます。 含めたい場合は .gitkeep 、含めたくない場合は .gitignore を使います。 .gitkeep を使う基準と例 .gitkeepは、「デフォルトではファイルが存在しないけれど、ファイルが追加されたら、そのファイルを Git での管理対象にしたい」場合
イラストを Git で管理したかったのでツールをつくった - blog.syfm
イラストの管理 自分はたまにイラストを描いたりするのですが、以前からその管理方法に苦労していました。 苦労していた点は主に次の 2 点です。 バックアップ 制作過程 Gif をつくるのが面倒くさい 強い人は、短時間でもさらっとイラストを描いてしまいますが、自分は時間をものすごく掛けないとまともなものが描けないので、バックアップは結構頻繁に取ります。 手動でバックアップしようとした場合は、ふつうにファイルを複製する感じになると思います。 ただ、普段からコードを書いていて VCS を利用している身だと、どうしても原始時代かと錯覚してしまいます。 さらに、PhotoShop の psd 形式や CLIP STUDIO PAINT の標準である clip 形式はいろんなデータが詰め込んであるので 1 ファイル当たり平気で 50 MB くらい持って行かれます。これも結構厳しいところです。 VCS を
rebase -iからcommitまで自動化する - Qiita
注: この記事で書いたことはvimscriptで頑張らなくてもgitの機能を使えばできます。 GIT_EDITOR=: git rebase -i --autosquash HEAD^^ のように GIT_EDITOR 環境変数に : を指定するとエディタの起動がスキップされます 指摘してくださったyuku_tさん、ありがとうございます。 rebase -iめんどくさい こんな感じで、タイポ修正など小さな修正してrebaseするとき結構めんどくさいですよね。 ですので自動化しました。 gitで起動するエディタはvimです。 ~/.zprofile function execIfCommandExists () { if type $1 2>/dev/null 1>/dev/null;then $1 fi } # 現在の変更を1つ前のコミットと結合する function gcommit-an
Emojiで楽しく綺麗なコミットを手に入れる | Goodpatch Blog
綺麗にコミットしてますか？？ はじめまして！Emojineerのnownabeです。グッドパッチではProttのサーバサイドエンジニアをやっています 本記事ではGitのコミットを綺麗に保つためにProttチームで導入しているEmoji Prefixを紹介します。 Emoji Prefixって何？ Emoji Prefixは「Gitのコミットメッセージの先頭にEmojiをつけよう」という一種のスタイルガイドです。 GitHubなどEmojiに対応しているGitホスティングサービスの利用を前提としています。 Emoji Prefixをつけてコミットすると、例えばGitHubならこのように表示されます。 基本はコミットメッセージの先頭にEmojiをつけるだけです。 ただし、EmojiはEmoji Prefixのルールに従って決める必要があります。 コミットの種類によってEmojiが決まる、という
ブランチの最終更新日時を一覧にする git branch-activity 書いた - Qiita
概要 どのブランチが新しくてどれが古いのか分からなくなることが多々あるので分かるようにするやつを書いた。 git branch-activity でローカルブランチ名と更新日時を新しい順に表示する。リモートブランチを表示するなら -r オプションをつける。ローカルとリモート両方表示するなら -a。ようするに git branch のオプションと同じ。 現在のブランチは緑、リモートブランチは赤、その他のローカルブランチは白で表示する。これも git branch に合わせてある。 インストール curl -o /usr/local/bin/git-branch-activity https://gist.githubusercontent.com/uasi/ec9978d793df35184b33/raw/git-branch-activity.sh chmod +x /usr/local/
われわれは、いかにして変更点を追うか
われわれは、いかにして変更点を追うか ChangeLog/Issueを追う技術 自己紹介 azu @azu_re Web scratch, JSer.info アジェンダ 変更点を ChangeLogで知る Issue/Pull Requestで知る Commitで知る アジェンダ 変更点を Commitに書く Issue/Pull Requestを扱う ChangeLogにまとめる 変更点を追う :mouse: ChangeLogの追い方 ChangeLogを追うにはまずChangeLogの更新に気づく事が必要 GitHubでライブラリのリリースを見ていくためのツールや方法に書いた 更新検知の仕組みや補助ツールについて リポジトリのWatch => azu/github-reader タイムライン => azu/github-reader Star => starseeker GitHu
gitでマージコミットが含まれるブランチをrebaseする - 作業ノート
確認したのは以下のバージョン。 $ git --version git version 1.7.12.4 例えば以下のように、マージコミットを含むブランチのコメントを編集したいとき。 $ git log --graph --pretty=format:'%h -%d %s' --abbrev-commit --date=relative * cd00264 - (HEAD, master) Merge branch 'branch-b' |\ | * 8f7b4c7 - add b.txt |/ * 521e66f - Merge branch 'branch-a' |\ | * f5622e4 - add a.txt |/ * 0d8bbff - new この状態でrebaseを行うときに $ git rebase -i HEAD~~ -iオプションだけでは pick f5622e4 a
Git の diff を美しく表示するために必要なたった 1 つの設定 #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 に書いてあ
iOS開発でGitを利用する際のTips
Oct 27, 2012 ちょっと今更な感じもありますが、iOS開発でGitを使うときのTipsを紹介します。 Gitそのものの使い方は理解している前提のもとで書きます。 バージョン管理する対象 Xcodeのプロジェクトにはバージョン管理する上で結構余計なものが入っています。 Gitで管理すべきでないもの Xcodeの作業データ Xcodeのプロジェクトは.xcodeprojですが、こいつ自身はディレクトリになっていて project.pbxproj project.xcworkspace xcuserdata というファイルが入っています。このうち、Gitで管理するべきものはproject.pbxprojです。 その他のものはXcodeの状態(グループを開いてるかなど)を管理しているものなので、 プロジェクトのバージョン管理対象としては適切ではありません。 ビルドデータ xcodebui
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 する際には
zsh, emacs, git, peco とかの話 - Qiita
久々に開発やったら色々便利なものが出てたのでまとめ すでにガリガリ書いてたのは遥か昔で全く開発に興味はなくなっていたのですが、最近少しだけ開発する機会があった。で、適当な開発環境でやろうかな？と思ったんだけど、不便な所とか少しずつ手を入れてったら、気がつけば結構良い感じになってたので、ここにまとめておく事にしました。 また開発からは少し離れることになるんだけど、いつか開発やる時にこれを元に環境が作れたらいいなーなんて思ってるんだけど、その頃には、また浦島太郎状態だろうけどね。 誰が嬉しいのか？ 僕の環境を晒して、再度環境を作る時の自分用のメモって位置付けですが、今同じ職場で働いている新卒君や２年目の人などに、コードを「読む・書く」って時に、これがあると全然効率が違うよ！ってのをアピる意味も含んだりしています zshに乗り換える！とかscreen使う！とかemacs使う！とか言ってくれれば設
「追跡ブランチ」って言うのやめましょう - 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ベースのコードリーディングTips - クックパッド開発者ブログ
こんにちは、投稿推進部の森川 (@morishin127) です。 エンジニアが既存のプロダクトの開発に携わる際、他人の書いたソースコードを読み解くところから始まります。過去に書かれたコードの意図を理解することは自分が書いたものでもしばしば難しく、他人が書いたものならなおさらです。この記事では過去に書かれたコードを理解するための工夫についてお話したいと思います。 なお、この記事ではプロダクトのソースコードはgitおよびGitHubのPull Requestを利用して開発が進められていることを前提としています。 特定の行から関連するPull Requestページを開く クックパッドのソースコードには概してコメントがあまり書かれておらず、見ただけでは理解しづらいような特殊な方法をとっている場合のみコメントを書いている印象です。基本的に実装に関する説明はソースコード中ではなく、GitHubのPu
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - jesseduffield/lazygit: simple terminal UI for git commands
gitでyarn.lockを常にバイナリとして扱う - Qiita
