Cargo.lock をバージョン管理するや否やcargo new --bin したパッケージに対して、たまたまデフォルで生成される .gitignore を用いずに https://gitignore.io/ で生成してものを用いていたのですが、 Cargo.lock ファイルの扱いが異なるように思われ、あれ？と思って見直してみました。
GitHub - arxanas/git-branchless: High-velocity, monorepo-scale workflow for Git
git-branchless is a suite of tools which enhances Git in several ways: It makes Git easier to use, both for novices and for power users. Examples: git undo: a general-purpose undo command. See the blog post git undo: We can do better. The smartlog: a convenient visualization tool. git restack: to repair broken commit graphs. Speculative merges: to avoid being caught off-guard by merge conflicts. I
Gitのコミット日時を修正する方法 - zzzmisa's blog
忘れがちなのでメモです。 直前のコミット日時を修正現状のコミット日時を確認します。 $ git log --pretty=fuller commit 62c6282c9b6a3f20659559a5d975dc16a33cb7cd (HEAD -> master) Author: zzzmisa <__@mail.com> AuthorDate: Sat Sep 21 14:04:18 2019 Commit: zzzmisa <__@mail.com> CommitDate: Sat Sep 21 14:04:18 2019 ... コミット時間を 15:00 へ修正することにします。 まずは、AuthorDate を修正します。 $ git commit --amend --date="Sat Sep 21 15:00:00 2019 +0900" エディタが立ち上がるので保存して終了
ファイルのタイムスタンプをコミット日時に合わせる - Qiita
svnの場合は、 use-commit-time = true でコミットされた時間にファイルのmtimeを合わせることができる。 ここに記載する内容もほぼ全て、以下のページに記載されている。 checkoutしたファイルのmtimeを、そのファイルがcommitされた時刻に合わせたい ― svnとgitの場合 - (ひ)メモ gitの場合はそういうオプションはないので、スクリプトでサクッと対応することになるが、公式wikiのサンプルスクリプト(perl)に記載があるわりに、それ自体がバージョン管理されていないという矛盾。（wikiなのでページ自体はバージョン管理されているけど…。このサンプルばかりを集めたリポジトリはない。ひょっとしてgit自体に含まれているかと思ったけれど、そんなことはなかった。） あと、他のツールのサポートスクリプトとして収録されていることも多いみたいで、メジャーなと
100MB超のファイルをコミットしてしまい githubに pushを拒否された時 - ブログ - ワルブリックス株式会社
うっかりgithubに受け付けてもらえないような大きなファイルをリポジトリに追加してしまった時の対策。普通に削除しても消えません。 まっとうなソースコードのリポジトリならそんなことは普通ないはずですが、うっかり100MBを超える大きさのファイルをリポジトリに追加してコミットまでしてしまったとします。 $ git add でかいファイル.tar.gz $ git commit -m 'でっかいファイル追加したった' $ git push remote: error: File でかいファイル.tar.gz is 123.00 MB; this exceeds GitHub's file size limit of 100 MB githubへ pushしようとした時、ファイルが大きすぎるということで拒否られます。あなたは嫌な予感がしつつも、問題のファイルを普通に git rmで削除して再度
Emoji Prefixに学ぶgitのコミットの分け方 - dackdive's blog
こちらの記事を読んで。 http://memo.goodpatch.co/2016/07/beautiful-commits-with-emojis/ この記事では、Emoji Prefix というコミットメッセージに関するルールについて紹介している。 どんなルールかというと、「コミットメッセージの先頭には、コミットの内容に合った Emoji をつけましょう」というものらしい。 Prefix に使える Emoji の種類をルール化し、コミットメッセージにはいずれかの Emoji を必ずつけるように徹底することで コミットの内容がわかりやすくなるだけでなく、粒度も揃うという効果が期待できるようだ。 以下、記事から引用。 最も期待している効果は、コミットが綺麗になることです。 開発の現場では「インデントの修正と機能の修正を同じコミットにしないでください 😭 」といった悲痛な叫びをよく耳にしま
【今日からできる】コミットメッセージに 「プレフィックス」 をつけるだけで、開発効率が上がった話 - Qiita
はじめに 今まで commit message を「なんとなく」書いていたが、プレフィックスをつけることで、コミットメッセージに対する考え方が変わった。 そのおかげで開発効率が上がったので、その内容をシェア。 プレフィックスをつけるってどういうこと？ 以下のようにコミットメッセージの先頭に、なんらかの文字をつけること。 feat: xxx という機能を追加 fix: yyy で発生するバグを修正 refactor: zzz の機能をリファクタ のように feat, fix, refactor などがプレフィックスです。 最近 OSS の Contribution Guide などでよく見かけます。 導入したプレフィックスルール Angular.js/DEVELOPERS.md Angular.js の開発者ガイドに書いてあるメッセージを参考にしました。 以前のコミットメッセージ（例 ちなみ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - nikochiko/autosaved: Never worry about losing your code. Written in Go
Dockerでcommitしてみる - Qiita
GitHub - muesli/gitomatic: A tool to monitor git repositories and automatically pull & push changes