コードレビューではgtrが便利！ - Qiita
はじめに GitHubのアップデートは頻繁に行われていて、GitHub上でのコードレビューもしやすくなってきてますね！ ただ、やっぱり手元のエディタで動かしながら確認したいことってありますよね でも、そのために現在の作業を stash したり、ブランチを切り替えて npm install し直したりするのは正直面倒です… そんな課題を解決するのが gtr (Git Worktree Runner) です！ （なぜ gtr と略すのかはわかってないです😇） なぜ gtr なのか？ Git標準の git worktree を使えばフォルダ単位でブランチを展開できます。 しかし、コマンドが長くて覚えにくいのが難点でした。 gtr はそれをシンプルにラップし、さらに便利機能を追加したツールです。 コマンドがシンプル git gtr new <branch> だけで作成完了 多様なエディタに対応
つい手癖で毎回「レビュー修正」とだけコミットメッセージを書いてしまう人へ - Qiita
はじめに：いつも手癖でコミットメッセージを書いてませんか？ gitのコミットメッセージはできるだけ、具体的な内容を書くべきです。 （何をどう変えたのか、どういう理由で変更したのか、等） しかし、初心者の人は「レビュー修正」や「指摘対応」のように、ただの作業名をコミットメッセージに書く人が多いです。 これだと、あとからコミット履歴を見直したときに、何をどう変更したのかわかりません。 しかも、 🙋♂️「修正しました！」 🧔🏻♂️「コメントしました」 🙋♂️「修正しました！」 🧔🏻♂️「コメントしました」 🙋♂️「修正しました！」 🧔🏻♂️「コメントしました」 というように、レビューコメントとレビュー修正のラリーが続くと、コミット履歴が「レビュー修正」の嵐になります。 こうなってしまうと、あとからコミット履歴を見ても何がどう変わったのか、さっぱりわかりません🤷♂
なぜタスク管理をNotionからGitHub Projectsへ移行したのか - AI時代の開発効率を最大化する選択
こんにちは。PIVOTでソフトウェアエンジニア、スクラムマスターを務めて(いる|いた)@tawachanです。 この記事では、PIVOTのプロダクトチームがNotionからGitHub Projectsへタスク管理ツールを移行した経緯と、具体的な実装方法について紹介します。 背景：AIファーストチームへの変革 詳細な背景については、前回の記事「スクラムからカンバンへの移行——ソフトウェアエンジニアがマネージャーになる時代に」で、チームの思想やプロセスの変化について紹介しました。今回は、その思想を支える具体的なツールの変化に焦点を当てます。 前回の記事で紹介したように、私たちのチームはAI時代の開発に合わせてプロセスを見直し、スプリントベースからカンバン方式へ移行しました。しかし、プロセスを変えるだけでは不十分でした。 開発速度が上がると、次に見えてくるのはツール自体のボトルネックです。特に
WIP新しい開発手法 - Qiita
WIPで新しい開発手法 WIP(Work-in-progress)：仕掛り作業という意味 WIPという文字が付いていると、その作業はまだ終了しておらず、作業中であるとわかる。 一つの作業においても作業が様々あるので、それを細分化して書いておく。 例）進行中のチケットの状態 【WIP】#12345 ○○機能の新規追加 [✔] ○○.php にformを作成する [✔] ○○テーブルを作成する [ ] formをカスタマイズする [ ] formの挙動を確認する [ ] CSSの適応 [ ] テスト レビューワー（コードチェック）はWIPの状態を見ることで、その作業がどこまで進行しているかがわかり、タイトルの【WIP】が外れていたらその作業は完了（レビュー待ち）というように一目でわかるようになる。 プロジェクト管理において、今あるチケットがどういう状態なのか「見える化」することができるようにな
Fork - a fast and friendly git client for Mac and Windows
Fork is getting better and better day after day and we are happy to share our results with you.
Gitコミットメッセージの表記法と7つのベストプラクティス
Gitコミットメッセージのベストプラクティスとしては、次に挙げる7項目が一般的に受け入れられている。 件名を50文字以内に制限する 件名の先頭文字を大文字にする 件名の末尾にはピリオドを付けない 件名と本文の間に空白行を設ける 本文は72文字で折り返す 命令形を使用する 行った内容と理由は記載するがその方法は記載しない 件名を50文字以内に制限する Gitの件名を50文字以内に制限する理由は2つある。 まず、多数のコミットメッセージの中からコミットの目的を探す際、件名が50文字以内であれば素早く見つけることができる。 次に、文字数を制限することで、開発者が自身の作業を真剣に振り返り、簡潔に表現するよう仕向けられる。開発者がコミットの目的を50文字以内で表現できないとしたら、コミットが不十分、1回のコミットに多くの作業を詰め込み過ぎ、解決すべき問題や作成する機能についての考え方が不十分といっ
混乱を引き起こしがちなGitの用語まとめ
分散型バージョン管理システムのGitは2005年の登場以降シェアを伸ばし続け、2022年の調査では約94％のユーザーに利用されるほど一般的なツールとなっています。Gitにはさまざまな機能が搭載されていますが、その中で特に混乱を引き起こしがちな用語について、Gitを15年近く使用してきたというジュリア・エヴァンスさんが解説しています。 Confusing git terminology https://jvns.ca/blog/2023/11/01/confusing-git-terminology/ ◆HEADと「heads」 HEADは現在チェックアウト中のブランチやコミットを指しており、「.git/HEAD」に保存されています。一方「.git/refs/heads」に保存されているのはブランチで、「heads」は「branches」と読み替えればOKとのこと。 ◆detached HE
GitHub、GitHub Innovation Graphを公開 ―世界各国の開発者の動きを見える化 | gihyo.jp
GitHub、GitHub Innovation Graphを公開 ―世界各国の開発者の動きを見える化 GitHubは2023年9月21日（米国時間）、GitHubを利用している世界中のソフトウェア開発者の動きや影響をオープンデータとインサイトとして可視化するGitHub Innovation Graphを公開した。 GitHub Innovation Graphを公開 -GitHubブログ GitHub Innovation Graph URL：https://innovationgraph.github.com/ GitHub Innovation Graphは、2020年にさかのぼり、gitプッシュ、開発者、組織、リポジトリ、プログラミング言語、ライセンス、トピックおよび経済的な関係国に関する四半期ごとのデータをWebページでビジュアルに提供するもの。さらに深く知りたい利用者
ACTION REQUIRED: Update your Bitbucket Cloud SSH Host Keys - Work Life by Atlassian
Hello Bitbucket Cloud users, We recently learned that encrypted copies of Bitbucket’s SSH host keys were included in a data breach of a third-party credential management vendor. The SSH protocol uses host keys to establish the identity of a trusted server for every SSH connection, like when a git pull establishes a SSH connection to Bitbucket Cloud. In response, Bitbucket issued two new SSH host k
Gitのコミットメッセージの書き方（2023年ver.）
本記事のモチベーション 約8年前、Gitを使い始めたときに以下の記事を公開したところ、想像以上の反応をいただきました。 当時はSubversionからGitに移行し、試行錯誤をしている中だったこともあり、多くの反応をいただけたことはモチベーションのひとつでした。 ただ、時が経ち、当然かもしれませんが現在は当時と違う書き方をしており、思想として変わっていない部分はあるものの、今でもときどきLikeをいただく中で、アップデートを全くしないのは誠実じゃないなと感じていました。 というわけで、現在のフォーマットも数年後には変わっている可能性が高いですが、その時々のスナップショットを公開することにも何らか意味があるかなと思い、「今の僕はこうコミットメッセージを書いているよ」というのをまとめました。 Gitを使う環境 開発フローやホスティングサービスごとのUIのdiffによって、最適なフォーマットは変
Meta、巨大リポジトリ向けコード管理システム「Sapling」を公開 Git互換クライアントをオープンソース化
Meta（旧Facebook）は2022年11月15日（米国時間）、社内向けのユーザーフレンドリーでスケーラブルなソースコード管理システム「Sapling」のGit互換クライアントをオープンソース化したと発表した。 Saplingクライアントは、互換性のあるSaplingサーバおよび仮想ファイルシステム（Metaは将来、これらもオープンソース化したい意向）との組み合わせにより、数千万のファイル、数千万のコミット、数千万のブランチを持つMetaの社内リポジトリを管理してきた。 MetaはSaplingシステムを、主に大規模なモノリシックリポジトリ（モノリポ）で使用しているが、SaplingクライアントはGitリポジトリのクローンや操作もサポートしており、開発者はGitHubなどのGitホスティングサービスの操作に利用することもできる。 使いやすさとスケーラビリティを重視したSaplingシス
意図せず約200万の.gitフォルダが公開、リスクの高い状態
CyberNewsは10月20日(米国時間)、「Millions of .git folders exposed to public｜Cybernews」において、数百万もの.gitフォルダが公開されていると伝えた。プロジェクトの重要な情報を含む約200万の.gitフォルダが一般に公開されていることがCyberNewsの調査チームにより明らかとなった。 Millions of .git folders exposed to public｜Cybernews GitはLinus Torvalds氏が20年近く前に開発した人気の高いオープンソースの分散型バージョン管理システム(VCS: Version Control System)。.gitフォルダにはリモートリポジトリのアドレス、コミット履歴ログなどプロジェクトに関する重要なメタデータが含まれており、このデータをオープンアクセスで放置してお
git statusが43秒かかっていたのを1秒に高速化する大規模Gitリポジトリの操作を高速化するためのscalarを紹介 | Act as Professional
Git 2.38がリリースされました。 このバージョンから大規模Gitリポジトリの操作を高速化するscalarが同梱されるようになりました。 今回はこのscalarによって、どれぐらいGitの操作が高速化されるのかを簡単に検証します。 結論から言うとgit statusが約43秒かかっていたのが約1秒で操作できるようになります。 Install Git 2.38 Git 2.38からscalarが同梱されましたので、各自の環境にあわせてInstallなりVersionUpなりをしてください。 $ git --version git version 2.38.0 Before 大規模Gitリポジトリとしてchromiumを利用しました。 普通にgit cloneしてきて、git statusを実施すると約37秒かかります。 ❯ time git status On branch main Y
Pull Requestの質を向上させるために行った戦略/戦術の話 - JMDC TECH BLOG
株式会社JMDCでモバイルアプリエンジニアをやっている @mrtry です。入社した当初、モバイルアプリチームのエンジニアは私一人だったのですが、現在では4人になりました。最近はPull Requestのレビュー数も爆増しており、とても疲弊しがちです(嬉しい悲鳴)。たいへんポイントを減らすために、最近Pull Requestまわりの運用を整えたので、今日はその話をしたいと思います。 Pull Requestのレビューがたいへん 現在、モバイルアプリチームでは、3つのプロダクトの開発をしています。各プロダクトに1名ずつassignされており、リードエンジニアとして私が一通りレビューをしている状況です。そんなこともあり「Pull Requestのレビューがたいへん」というのが最近の悩みでした。 Pull Requestのレビューをするとき、私は以下のような観点でレビューしています。 機能仕様レ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
改めて考える、「Gitのコミットメッセージを能動態や命令調で書く意味」
VSCodeのGit連携をさらに便利に！ 拡張機能Git History、Git Graph、GitLensを解説
「Git」に脆弱性 ～対処した「Git for Windows 2.40.1」が公開／他の「Git」関連アプリのアップデートにも注意
「Git for Windows 2.40.0」が公開 ～git-commitなどの「-」系コマンドが廃止／「git jump」が「Emacs」にも対応。Windows 7/8.xのサポートは間もなく廃止
Gitで管理しているソースの改行コードに注意
「Git」に任意コード実行などへつながるおそれのある脆弱性が2件／「Git for Windows」「GitHub Desktop」などの関連ツールにセキュリティアップデート
