Better suggested pull request description from commit message · GitHub Changelog
AI & MLLearn about artificial intelligence and machine learning across the GitHub ecosystem and the wider industry. Generative AILearn how to build with generative AI. GitHub CopilotChange how you work with GitHub Copilot. LLMsEverything developers need to know about LLMs. Machine learningMachine learning tips, tricks, and best practices. How AI code generation worksExplore the capabilities and be
NotGitBleed - TL;DR
NotGitBleed - TL;DR Due to configuration errors or human error, significant numbers of people may have accidentally checked GitHub credentials into GitHub commits as metadata, most commonly a username as the author name and a password in the email address field. We estimate in the region of 50,000 to 100,0001 user credentials may have been affected covering a wide range of organisations including
GitHub - kffl/speedbump: TCP proxy for simulating variable, yet predictable network latency :globe_with_meridians::hourglass_flowing_sand:
You 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
GitHub - rothgar/mastering-zsh: Advanced topics to take advantage of zsh 👩💻👨💻
If you're already using zsh or want to start this tutorial will help you understand how zsh works and how you can customize it to your needs. We won't go into every feature of zsh (read the man pages for that). Did you know zsh has a built in ftp client and calendar? Instead we will focus on functions of zsh that improve your productivity and help you get more out of your shell. We also will not b
You 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
You 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
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
GitHub - diracdeltas/tweets: janky twitter replacement.
You 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
前回はイテレーション的ソフトウェア開発が重要である理由について紹介しました。今回は、コードレビューの観点からイテレーションの重要性について考えてみます。 GitLabでは、反復を可能な限り小さくして可能な限り迅速に成果を出すようにと定義しています。マージリクエストにおいて、もし推奨する指針を1つだけ挙げるとしたら、それは「反復」です。本質的に、ソフトウェアは反復がすべてです。ソフトウェアとは大きな問題を細かく分解し、より取り扱いやすい問題にするものです。他のスキルと同様に、反復について学び、改善するように実践を重ねていきます。あなたが次に「Submit merge request」ボタンをクリックするとき、一瞬立ち止まり、これからサブミットしようとするマージがより小さくできないか考えるようにしてください。 なぜ小さなマージリクエストがいいのか 長いマージリクエストを書くことよりも悪いことは
continue-on-error を使う方法を新たに記事にしました。 以下の内容は非推奨です。参考として残しておきます。 GitHub Actions で変更があるときだけ git commit & push する方法を 2 種類。 方法 1 : シェルスクリプト完結 通常のシェルスクリプトの if ! git diff --exit-code --quiet で判定。 steps: - uses: actions/checkout@v2 - name: 変更があるかもしれないしないかもしれない run: ./script.sh - name: commit & push run: | git add -N . # 新規ファイルを含める if ! git diff --exit-code --quiet then git config user.name github-actions g
Summary 何となくでも良いのでconventional commitの仕様にしたがってcommitを作る 変更はPR作る直前までcommitしない 3.レビュー以前の変更はfixupとforce pushで既存のcommitに入れる。追加のcommitは作成しない 解説 1. 「何となくでも良いのでconventional commitの仕様にしたがってcommitを作る」について conventional commitとは、「人間と機械が読みやすく、意味のあるコミットメッセージにするための仕様」です。（公式から引用https://www.conventionalcommits.org/ja/v1.0.0/ ) この仕様(の特にコミットメッセージのタイトル部分)に従ってコミットを作るようにします。 タイトル部分の仕様はこんな感じです。 <type>[optional scope]:
husky v5 で使い方が変わっている(v6 でも変更後の使い方を継続している)。 husky v4 が deprecated した訳ではない (v5.0.0 リリース後にも v4 系のパッチリリースがある)。 The Parity Public License というのを初めて見ましたが、組み込んだソフトウェアも公開しないと行けないっぽい。つまり商用利用、実質不可。 ライブラリ毎の違いを確認する (CLI から) husky v4 (↓) husky v4 をインストールすると、 .git/hooks 配下に git-hooks 用の shell script が追加される。 $ git init husky-v4 $ cd husky-v4 $ npm init $ npm i husky@4 $ ls -1 .git/hooks | grep -v .sample applypat
ちなみに vim の終了方法としては :cq というのもあり、これを実行すると vim が終了コード 1 で終了します。git commit をキャンセルする場合に使えます。— mattn (@mattn_jp) 2019年6月26日 だいぶ昔のツイートなのですが, さっき知ったので忘備録的にブログに書いておきます. CLIでGitを操作してて, commit logはnvimで書いてるんですが, たまにgit commit した後に｢あ, commitするbranch間違えた...!｣みたいに気づくことがあって困ることがありました. mattnさんのツイートにもあるように, :cq で閉じると, hint: Waiting for your editor to close the file... error: There was a problem with the editor 'nv
この記事は、Chris BeamsのHow to Write a Git Commit Messageブログの内容を簡単にまとめた資料で、翻訳・編集して、役に立つ内容を追加したものです。 Gitのコミットメッセージをうまく作成すべき理由 なぜコミットメッセージをうまく書く必要があるのか？理由は色々ありますが、うまく書かれたコミットメッセージが有益であるという事実は、多くのプログラマが同意することでしょう。そのうち代表的な3つの例を挙げてみます。 コミットログの読みやすさ より良いコラボレーションとレビュープロセス コード保守の容易さ 「良いコミットメッセージについて考えることは素晴らしいアイデアだと思う。しかし、良いメッセージの正解があるかは分からない。個人によって良いコミットメッセージと捉える基準が異なるためだ。多くの人々が共感できる良いコミットメッセージをうまく作るためのルールはないだ
コミットとプルリクエストのベストプラクティスをまとめた記事を寄稿しました #レバテックラボ - give IT a try
お知らせ レバテックラボさんのサイトに、コミットのベストプラクティスと、プルリクエストのベストプラクティスをまとめた記事を寄稿しました。 levtech.jp levtech.jp エンジニアの暗黙知を形式知に お仕事でコードを書いている人は、日々gitにコミットしたり、プルリクエストを作成したりしていると思います。 ただ、「どんなコミットが良くて、どんなコミットが悪いのか」とか、「どんなプルリクエストが良くて、どんなプルリクエストが悪いのか」といった話をわざわざ教えてもらった人はそんなに多くないのではないでしょうか？ せいぜい、先輩プログラマから「このコミットの仕方はイマイチだからこうしようね」とか「プルリクエストにはしっかりdescriptionを書いてください」といった指摘をもらい、「なるほど、そういうもんなのか〜」と徐々に正しいやり方を学んでいく、みたいなケースが多いのでは？と想像
GitHub - RomanHotsiy/commitgpt: Automatically generate commit messages using ChatGPT
You 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】GnuPG x git-secretでcredentialなどの秘匿情報を含むファイルを暗号化して安全にcommitする - その2: 複数人で扱う場合 - tweeeetyのぶろぐ的めも
はじめに gitやgithubでcredentialやtokenなどの秘匿情報を含むファイルを暗号化してcommitするメモを書きました。 【git】GnuPG x git-secretでcredentialなどの秘匿情報を含むファイルを暗号化して安全にcommitする - その1 今回は、それを複数人であつかう場合のメモです。 アジェンダ はじめに アジェンダ 1. ながれのイメージ 2. [Aさん] 秘匿情報をgit secret管理化にする gpgでkeyの生成 リポジトリを用意する git-secret管理化にする git push する 3. [Bさん] gpg keyの作成＆エクスポート gpg keyの作成＆エクスポート この時点で復号化を試してみる 4. [Aさん] GPGとgit-secretにBさん情報を設定 GPGにB -san鍵をインポート git-secretにB
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - tunepolo/manager-readme
GitHub - loov/lensm: Go assembly and source viewer
第2回 小さなマージリクエストが優れたレビューの鍵となる理由 | gihyo.jp
GitHub Actions で変更があるときだけ git commit & push する
PRを小さく保つための、commit管理3TIPS - spice picks
husky(v4, v6) と simple-git-hooks どちらを使うべきか
小ネタ: Gitでコミットメッセージ書いてる最中にコミットを取りやめる - Masteries
Gitのコミットメッセージをうまく作成する7つのルール | NHN Cloud Meetup