ソースコードをリポジトリ丸ごとLLMに読んでもらう方法
はじめに ソースコードをLLMに読んでもらうとき、単一ファイルだと楽なのですが、GitHubのリポジトリのように複数ファイルから構成されるプロジェクトだと困ってしまいますね。 リポジトリごとLLMに読んでもらえるようにいい感じにテキスト化できると良いですね。そんなソフトがありました。しかも2つ。 両方ともほとんどコンセプトは同じです。特に後者のgenerate-project-summaryは使い方も含めて、自分のやりたいことが、すでに開発者の清水れみおさんが以下の記事にまとめていました。 なので、あんまり書く必要ないのですが、せっかくなのでgpt-repository-loaderの使い方と、出力したファイルの別の活用方法について書いてみたいと思います。 gpt-repository-loaderでリポジトリをテキストに変換 使い方はREADMEに書いてあります。シンプルなソフトなので、
【Git】コミットメッセージの先頭につけた方が良い単語リスト- prefix集 - - Qiita
文章でリストを表示（少し詳細あり） fix: バグ修正 既存の機能の問題を修正する場合に使用します。 hotfix: 緊急対応 稼働中のシステムのバグ修正など、緊急性が高い修正を行う場合に使用します。 add: ファイルや機能の追加 新しいファイルや機能を追加する場合に使用します。 feat: 新機能・新規ファイル追加 新しい機能やファイルを追加する場合に使用します。 update: 機能修正 既存の機能に問題がなく、ただし修正を加えたい場合に使用します。 change: 仕様変更による機能修正 仕様変更により、既存の機能に修正を加えた場合に使用します。 clean・refactor: リファクタリング コードを修正し、改善する場合に使用します。 improve: コードの改善 コードの改善をする場合に使用します。 disable: 機能の無効化 機能を一時的に無効にする場合に使用します。
Git - Book
The entire Pro Git book, written by Scott Chacon and Ben Straub and published by Apress, is available here. All content is licensed under the Creative Commons Attribution Non Commercial Share Alike 3.0 license. Print versions of the book are available on Amazon.com. The version found here has been updated with corrections and additions from hundreds of contributors. If you see an error or have a s
GitHubのリリースノートを自動化する仕組み
GitHub のAutomatically generated release notesを使ってリリースノートの内容を PR に基づいて自動生成するフローを作りました。 今までは、コミットメッセージのルールであるConventional Commitsとconventional-github-releaserを使って、コミットからリリースノートを自動生成していました。 他の人の PR でも、squah merge でコミットメッセージを書き換えることで、リリースノートに反映されるようにしていました。 ただ GitHub に仕組みは違うけどほぼ似たことをするAutomatically generated release notesという機能が実装されているので、これをベースに移行しようと思って、そのワークフローを作っていました。 リリースノート自動生成テクニック - mizdra’s bl
Linus Torvalds 氏の理想の git 運用と GitHub
Note 本記事の内容は Linus 氏の発言が人を傷つける場合に筆者がそれを良しと考えるといった意図はございません 少し古い記事になるが、 Linus Torvalds 氏 の GitHub に対する苦言が記事になっていた。 LinuxカーネルにNTFSドライバーが追加、トーバルズ氏はGitHub経由のマージに苦言 - ZDNet Japan Linus 氏が GitHub について苦言を呈するのは今に始まったことではない（後述）が、 別に GitHub のすべてを否定しているわけではない。[1] では一体何が不満なのか。Linus 氏の理想とする git の開発フローを考察した上で、整理してみたい。 Linus 氏の理想 結論からいうと、 「意味あるコミットを作れ」「コミットを大事にしろ」 という思想が伺える。 では 「意味あるコミット」「大事にされたコミット」 とは何なのか。 筆者な
Gitのコミットメッセージの書き方（2023年ver.）
本記事のモチベーション 約8年前、Gitを使い始めたときに以下の記事を公開したところ、想像以上の反応をいただきました。 当時はSubversionからGitに移行し、試行錯誤をしている中だったこともあり、多くの反応をいただけたことはモチベーションのひとつでした。 ただ、時が経ち、当然かもしれませんが現在は当時と違う書き方をしており、思想として変わっていない部分はあるものの、今でもときどきLikeをいただく中で、アップデートを全くしないのは誠実じゃないなと感じていました。 というわけで、現在のフォーマットも数年後には変わっている可能性が高いですが、その時々のスナップショットを公開することにも何らか意味があるかなと思い、「今の僕はこうコミットメッセージを書いているよ」というのをまとめました。 Gitを使う環境 開発フローやホスティングサービスごとのUIのdiffによって、最適なフォーマットは変
個人的によく使うGitエイリアス、zshキーバインド - 本日も乙
最近、リモートワークということもあり、ペアプロというかAWS、GCPなどの操作をする際に一緒に画面を見ながら作業する機会が多いです。若手の同僚がターミナルソフトを起動してコマンドを実行するのですが、傍から見ているとエイリアスなりキーバインドなりを使えば効率的に操作できるのにと思うことがあります。 最近はGUIで操作することが多いのでターミナルソフトでコマンド操作することがあまりないのかもしれませんが、私は少し前までは（クラウドしかできない）ITインフラエンジニアをやっており、プログラミングよりもコマンド操作するのが圧倒的に多かったため、ちょっとしたことならGUIよりもターミナルで操作することが多いです。Windowsを使っていますが WSL2 + Ubuntu 20.04 LTSで開発環境を整えているため、操作に不自由はほとんどしません。 この手のエイリアスやzshなどのオススメ設定はググ
あなたはmerge派？rebase派？綺麗なGitログで実感したメリット - BIGLOBE Style ｜ BIGLOBEの「はたらく人」と「トガッた技術」
BIGLOBEの開発現場の様子や、developブランチにrebaseで綺麗なコミット履歴を作る方法をご紹介します。 はじめまして！ GitHubを中心に仕事がまわる開発現場 Git logが綺麗だとバグが起こりにくい？ developブランチを綺麗に保つGit操作（マージ編） 1. そのまま気にせずdevelopにマージする。 2. 最新のdevelopをfeature/Bブランチに取り込んでからdevelopにマージする 3. 最新のdevelopにrebaseしてからマージする ﾘﾍﾞｰｽ ｺﾜｸﾅｲｮ 最後に はじめまして！ 基盤本部（開発部門）の江角です。 2021年8月にSIerからBIGLOBEに転職し、半年が経過しました。 転職期間中はもちろんコロナ禍で、カジュアル面談も面接も全てオンラインでした（多分今もそうだと思います）。 入社日当日は出社しましたが、入社してから半年の
テレワークで始めたドキュメント駆動業務｜Dentsu Digital Tech Blog
こんにちは。電通デジタルでEMをしている河内です。エンジニアにおける採用・評価、スクラムマスターなどを担当しています。今回はすこし実装プラクティスから離れた話題になりますがお付き合いくださいませ。 弊社もご多分に漏れず完全テレワークを実施しており、かれこれ4か月が経ちます。その中で見えてきた課題とエンジニアチームとしてどう対峙したか、そしてそこで得た気づきを綴っていきたいと思います。この内容は、過去に開催したオンラインイベントでお話した内容になります。 テレワーク環境で私たちのエンジニア部門で急務と感じた課題テレワークが開始された2月後半、プログラミングやシステム開発プロジェクトを生業とする私たちの部では「リモート？全然OK。支障無いっす。」とタカを括っておりました。しかし開始されて間もなく、やっぱり慣れていない事が判明・・・。テレワークを経験されている読者の多くの方が感じていることと同様
スケールする組織を支えるドキュメンテーションの技術を”GitLab Handbook”から学ぶ｜安野貴博
ドキュメント文化は健全な組織のスケールのために必要 組織の中でドキュメント/文章を残し活用していくことはとても重要だ。クオリティの高いドキュメントがあることで、組織に情報が流通し、透明性を確保できるようになる。情報を流通させるためにいちいち口頭の説明がいらないから、メンバーの数が増えた時でもスケールしやすくなる。過去の結論にアクセス可能になるので、議論を積み上げていき、意思決定のクオリティを高めることにもつながる。そもそも何かを読むということは何かを聞いて教わるよりも時間あたりの処理量が多いし、非同期に実施できる。良いドキュメントをアセットとして社内に蓄積していくことはスタートアップのみならず、ありとあらゆる組織が成長していく上でとても重要であると言える。 しかしその一方で、良質なドキュメント文化を徹底できている会社は多くないように見える。例えば、社内のドキュメントを蓄積させていく場所とし
ソースコードブランチ管理のパターン - Martin Fowler's Bliki (ja)
https://martinfowler.com/articles/branching-patterns.html 最新のソース管理システムには、ソースコードのブランチを簡単に作成できる強力なツールが用意されています。しかし、最終的にはこれらのブランチをマージしなければならず、多くのチームは混み合ったブランチに対処するのに膨大な時間を費やしています。複数の開発者の作業をインテグレーションし、本番リリースまでの道筋を整理することに集中して、チームが効果的にブランチを利用できるようにするためのパターンがいくつかあります。全体的なテーマとしては、ブランチを頻繁にインテグレーションし、最小限の労力で本番環境に展開できる健全なメインラインを作ることに注力すべきだということです。 ベースパターン ソースブランチング ✣ メインライン ✣ 健全なブランチ ✣ インテグレーションパターン メインラインイン
Gitでよく使用するコマンドをGIFアニメで解説
Gitでよく使用するコマンドが何を行っているかをGIFアニメで解説した記事を紹介します。 Gitのマージ、リベース、リセット、チェリーピック、フェッチ、プル、リフログなど、コマンドを実行した時にブランチはどのように相互作用し、履歴にどのような影響を与えるのか視覚的に学べます。 🌳🚀 CS Visualized: Useful Git Commands by Lydia Hallie 下記は各ポイントを意訳したものです。 ※当ブログでの翻訳記事は、元サイト様にライセンスを得て翻訳しています。 はじめに Gitのマージ（fast-forward, no-fast-forward） Gitのリベース（rebase） Gitのリセット（reset, revert） Gitのチェリーピック（cherry-pick） Gitのフェッチ（fetch） Gitのプル（pull） Gitのリフログ（re
美容内服薬ラボットメディカルクリニック【公式】
オンライン診療とは、自宅にいながら医師に直接毎日のスキンケアを相談したり、医薬品や漢方薬の処方を受けることができたりする診察のこと。お薬が処方された場合は郵送で薬局等にお薬を取りにいかなくても、自宅に届けられます。 普段、病院では発生する診察費用や処方箋費用はもちろん、お薬代以外の費用は一切かかりません。
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 する際には
Git GUI for Windows, Mac & Linux | GitKraken
NEW Meet the GitKraken DevEx Platform Desktop, IDE, Terminal, Web and Mobile › Because PR & code review should be more 🎉 & less 🤬 multi-repo setups shouldn’t make you feel 🤢 too much context switching makes you feel 😤 merge conflicts can turn into a real 💩 show fear of Git mistakes has you all like 🫣 and 😱 lousy DevEx will make your top devs run for the🚪 lack of visibility kills progress a
Mac / Windows / Linuxに対応した無料のGUI Gitクライアント「GitKraken」 | ソフトアンテナ
クロスプラットフォームのGUI Gitクライアント「GitKraken」が公開されています。現在パブリックベータテスト中で、公式サイトよりMac / Windows / Linuxに対応した実行ファイルを無料でダウンロードして使用することができます。 最近流行のElectronを使用して作成されたソフトウェアのようで、libgit2やNodeGitといったオープンソースライブラリも組み込まれています。 Electron風の美しいGUI ▼メイン画面は以下の通り。 コミット履歴やブランチの分岐が美しく表示されているのが印象的です。コミットやブランチの作成/マージ、pull/pushといったGitの操作をGUIを使って行う事ができます。 ▲設定画面を使って「git config」の設定や、sshの鍵の管理、GitHubやBitBucketといったサービスの認証情報の管理、Git Flowの設定
新しい環境に移行したときのことを考える.emacsの設定 - Qiita
この記事は .emacsアドベントカレンダーの19日目の記事です。 新しいPCを買いましたら、最初にする事は環境の構築ですね。特にプログラミング環境を整えるのはとても重要です。 最近は.emacs.dディレクトリをまるごとドロップボックス等のクラウドストレージに入れている人もいるようですが、これらの設定ファイル群はやはりgitで管理したいという人も多いと私は信じています。 ここで問題になってくるのが、elpa/melpaやel-getから落としてくる、emacsのパッケージ群です。 日々新しくなっているパッケージ群ファイルや、el-getのビルド成果物を手元のgitで管理するのは非効率に過ぎるので、これらは「設定ファイル」のためのリポジトリにはなるべく置きたくありません。 ですがこれらのパッケージ群の本体をバージョン管理から外してしまうと、単純に「git cloneして一発で環境再現完了」
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - kaityo256/github: GitHub演習
GitHub - isotai/git-tips: 最もよく使われるgitの小技と裏技
Gitハンズオン研修 / Git Hands-on
