Writing good commit messages
Good commit messages serve at least three important purposes: To speed up the reviewing process. To help us write a good release note. To help the future maintainers of Erlang/OTP (it could be you!), say five years into the future, to find out why a particular change was made to the code or why a specific feature was added. Structure your commit message like this: From: https://git-scm.com/book/ch
Sign your Git commits with 1Password | 1Password
So 1Password CEO Jeff Shiner just committed code to one of my GitHub repositories. That’s strange. While he’s a developer at heart, I don’t think he gets much time to code these days. What’s going on here? As you might have guessed, this didn’t actually come from Jeff Shiner. In fact, anyone can spoof a Git committer or author name with just a few terminal commands and pretend to be someone else:
cherry-pick 運用の地獄から這い上がった話をしよう
はじめに はじめに断っておくが、こんな生易しいものじゃない。本当に地獄の沙汰である。 状況と問題点 筆者が参加しているプロジェクトでは、ブランチの運用が cherry-pick で行われていた。Git Flow でも GitHub Flow でもない。言うなれば、Cherry-pick Flow である。 Git Flow について Git Flow なら、本番リリースする際にまず develop ブランチからリリースブランチを切る。 それを master にマージする。 そして、master へのマージ後のマージコミット (M1) を develop に逆輸入すれば、基本的に develop ブランチが Fast-forward な状態となる。 ホットフィックスの場合も同様である。 コミットの取りこぼしなど起きるわけがないし、リリース作業自体もやることが明確でわかりやすい。 Cherry
AWSアクセスキーをGitリポジトリに混入させないために git-secrets を導入した | DevelopersIO
先日開催されたAWS Summit Tokyo 2017、わたしもいくつかセッションを聴講してきたのですが、「DevSecOps on AWS - Policy in Code」というセッション1にてgit-secretsというツールが紹介されていました。 awslabs/git-secrets: Prevents you from committing secrets and credentials into git repositories これ以外にも、いくつかのセッションで言及されていたと思います。 git-secretsのことは以前から聞いてはいたのですが、自分自身があまりコードを書く環境にいなかったので、良くないとは思いつつも今まであまり気にしていませんでした。 ただ、AWSアクセスキーの漏洩が原因と思われる話を聞く機会はなかなか減りませんし、考えてみれば自分でも、AWSクレデ
branch を寝かせるときは TODO.txt を置いている - id:onk のはてなブログ
タイトルがすべて。 思いついたら手を動かしてしまう性質なので、秘蔵のブランチを大量に持っている。 秘蔵のブランチというのは、動いたけどチームメンバーを説得するのが面倒とか、テスト書くのが面倒とか、だいたい動いているけどやりきるのが面倒とかで main にマージしていないヤツ。 例えばフレームワークのメジャーバージョン上げるブランチとか、依存ライブラリをより一般的/現代的なものに交換するブランチや、より良い設計を思いついたのでガッと書き換えてしまうブランチが多いかな。 だいたい 1 年所属していると 80 ブランチぐらい溜まるので、週 1 つ以上は何か作りかけてる計算になる。 ローカルブランチの数、プロンプトに出しておくかな……。(秘蔵のブランチが溜まってる— Takafumi ONAKA (@onk) March 28, 2017 もちろん自分でいいアイディアだと思っているから実装している
Gitのワークフローについての私のスタンス | おそらくはそれさえも平凡な日々
Gitのワークフロー、好みが分かれる分野で自転車置き場の議論にもなりがちだと感じている。基本的にはプロジェクトの流儀に素直に従い、余計なストレスを抱えないのが良いと考えている。例えば、私はマージコミットを作るのが好みだが、OSS活動等では「squash & mergeして」って言われることもあり、そういうときは当然素直に従うようにしている。 ということで、私のGitのワークフローについてのスタンスについて書いておこうと思う。私と一緒に働く人や、働くことを検討している人の参考になればと思います。もちろん、この辺りは、良い方向に変化もさせていきたい。例えばエントリー内でも触れていますが、私は昔はforce pushを禁止したいくらいでしたが、今は使っても良い、と思うようになりました。 Natureの特にGoでのバックエンド開発はこれに近い感じだとイメージしてもらえればと思います。ただ、できてな
Gitly
Gitly is an upcoming open-source development platform that is going to have Source code hosting Project management CI & CD Main features: Light and fast Minimal amount of RAM usage (works great on the cheapest $3.5 AWS Lightsail instance) Easy to deploy (a single <1 MB binary that includes compiled templates) Works without JavaScript Detailed language stats for each directory "Top files" feature t
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Gitea Official Website
GitHub - altsem/gitu: A TUI Git client inspired by Magit
GitHub - jesseduffield/lazygit: simple terminal UI for git commands
GitHub - Byron/gitoxide: An idiomatic, lean, fast & safe pure Rust implementation of Git
sourcehut hub
GitButler | Git Branching, Refined
GitHub - facebook/sapling: A Scalable, User-Friendly Source Control System.
コミットメッセージ規約 「Conventional Commits」を導入してみよう！ / Let's use Conventional Commits
GitHub - djanderson/aho: A git implementation in awk
GitFinder - git client with Finder integration
Git Good - The magic of keeping a clean Git history - Mainmatter
GitHub - extrawurst/gitui: Blazing 💥 fast terminal-ui for git written in rust 🦀
GitHub - github/renaming: Guidance for changing the default branch name for GitHub repositories
