コードレビューはつまらないから丁寧なプルリクエストでチームの生産性向上を目指す
コードレビューにずっと苦手意識を持っていた。レビューは時間がかかるし、あまり気が乗らない。 がんばってやっても、うまくできたのかどうか自信が持てない。 もちろん、世にあるコードレビューに関する書籍や記事などはいくつも読んだ。 そこには、コードレビューをするときの観点や、コードレビューで望ましい言葉づかいなど、ためになることがたくさん書かれていた。 それでも、やはりコードレビューが苦手なことに変わりはなかった。 だけど最近ようやく、こうすればレビューをうまくこなせるのではないかという出口が、なんとなく見えはじめてきた。 この記事では、ぼくなりにたどり着いた、プルリクエストのレビューを上手に行うための心構え、つまりいかにしてレビューのつらみを減らすかについて書く。 目次 なぜコードレビューはつまらないのか われわれは、なんのためにコードレビューをするのか レビューのコスト レビューの観点 文化
OpenAI APIを使ってgit commitメッセージやコードレビューをAIに任せましょう！ - GMOインターネットグループ グループ研究開発本部
2024.09.27 OpenAI APIを使ってgit commitメッセージやコードレビューをAIに任せましょう！ 次世代システム研究室の Y.I です。 OpenAI API を活用してちょっと便利なコマンドを作成したのでご紹介します。作成したものは、「自動Git Commitメッセージ生成」と「コードレビュー」機能です。LangChainやVectorDBなどを利用しなくても、発想次第で便利な機能を作れますので1例としてご覧ください。 機能紹介 Pythonで以下の機能を実現しています。 Git commitメッセージの自動生成 Gitの変更履歴に基づき、適切な日本語のcommitメッセージを生成します。 コードレビューの自動化 Gitの変更履歴に基づき、コードに問題がないかやパフォーマンス改善の提案を行います。 openai apiのtokenを環境変数から取り込み 簡易的ですが
merge commitのrevert commitをrevertしてたけど気持ち悪いからやめました。 - クイック エンジニアリングブログ
こんにちは。mikkiです。 今回はGit運用でずっと気持ち悪いと思っていた、revertのrevertをやめる方法を見つけたので、こちらに記載したいと思います。 （もしかしたらこんなことしてたの私だけかもしれない。。。） Gitの説明は省くので、勉強されたい方は詳しく説明の載っている外部サイトをご覧ください。 サルでもわかるGit入門 〜バージョン管理を使いこなそう〜【プロジェクト管理ツールBacklog】 どんな時にrevertのrevertをしていたのか revertのrevertをせずに修正を加える方法 最後に どんな時にrevertのrevertをしていたのか developブランチから複数のfeatureを切り、developにmergeし動作確認を行っているとします。 追い越しリリースやバグが見つかった場合、対象featureブランチのmergeコミットをなかったことにしたい
Git / GitHub を使用したチーム開発時のガイドラインを制定しました | DevelopersIO
開発時にはみなさん Git や GitHub を使うと思いますが、使い方についてチームメンバー間で微妙に認識の違いがあると進捗を妨げてしまいます。それを防ぐためにガイドラインを定めてみました。 ちなみにこれは CX 事業本部の Tech Lead のお仕事紹介第 1 弾のポストです。 この記事の英語版も書きました。 前提 CX 事業本部ではクライアントからの開発案件や自社サービスの開発をしていますが、その際に有用な（と考えている）ガイドラインです。 様々な事情でチームメンバーが変更になる可能性があり、新規メンバーの立ち上がりを支援する意味合いも込めています。そのため、開発効率をなるべく落とさずに効果的なスキルトランスファーが実施できることを主眼としています。 ガイドライン 定めたガイドラインの全文を貼ります。 3 つのセクションに分かれています。 commit 時のガイドライン avoid
[macOS向け] gitのクライアントはGitUpがいいぞ。 - Qiita
ツイッタフォローしてやで(ﾎﾞｿｯ https://twitter.com/JotaroUT いろいろ使ってみたけどGitUp、やめられませんでした。 Macbookをスタバで開いてはプロジェクトをgitで管理する機会の多いであろう諸兄・諸姉のために、独断でイケてるなと思ったgitのGUIクライアントについて紹介したい。その名もGitUp。 GitUp : http://gitup.co/ GitUpとは GitUpはmacOS用に開発されたgitのGUIクライアントである。 公式ホームページに、 Work quickly, safely, and without headaches. とあるように、確かに使っている間は頭痛がしない気がする。大きな特徴としては、謳い文句の通り、 早い。 ざっくりした使い方 コミットを参照する。 ここでは、openFrameworks (https://op
![[macOS向け] gitのクライアントはGitUpがいいぞ。 - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/2a9c427f726fd589af10501c50805b885e98bf6c/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fqiita-user-contents.imgix.net%252Fhttps%25253A%25252F%25252Fcdn.qiita.com%25252Fassets%25252Fpublic%25252Farticle-ogp-background-afbab5eb44e0b055cce1258705637a91.png%253Fixlib%253Drb-4.0.0%2526w%253D1200%2526blend64%253DaHR0cHM6Ly9xaWl0YS11c2VyLXByb2ZpbGUtaW1hZ2VzLmltZ2l4Lm5ldC9odHRwcyUzQSUyRiUyRnFpaXRhLWltYWdlLXN0b3JlLnMzLmFtYXpvbmF3cy5jb20lMkYwJTJGODYwNDAlMkZwcm9maWxlLWltYWdlcyUyRjE0NzM3MDM2MTY_aXhsaWI9cmItNC4wLjAmYXI9MSUzQTEmZml0PWNyb3AmbWFzaz1lbGxpcHNlJmZtPXBuZzMyJnM9NTFmMzllOWYwZDJiNWU5OTVmNmMxMmFhOThmZWFiZTk%2526blend-x%253D120%2526blend-y%253D467%2526blend-w%253D82%2526blend-h%253D82%2526blend-mode%253Dnormal%2526s%253Deff5bcf9864737e4565caba43ed401de%3Fixlib%3Drb-4.0.0%26w%3D1200%26fm%3Djpg%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk2MCZoPTMyNCZ0eHQ9JTVCbWFjT1MlRTUlOTAlOTElRTMlODElOTElNUQlMjBnaXQlRTMlODElQUUlRTMlODIlQUYlRTMlODMlQTklRTMlODIlQTQlRTMlODIlQTIlRTMlODMlQjMlRTMlODMlODglRTMlODElQUZHaXRVcCVFMyU4MSU4QyVFMyU4MSU4NCVFMyU4MSU4NCVFMyU4MSU5RSVFMyU4MCU4MiZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZ0eHQtY29sb3I9JTIzMUUyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTU2JnR4dC1wYWQ9MCZzPWFlZDE0MGI5YWVmZmEwMzlmNmYzNGIxOWJmODY0MDYz%26mark-x%3D120%26mark-y%3D112%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTgzOCZoPTU4JnR4dD0lNDBKb3Rhcm9TJnR4dC1jb2xvcj0lMjMxRTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9MzYmdHh0LXBhZD0wJnM9YWM3OGFjMTBjNTM4YTIyYWJmMjY0ZmM2YjhhNDQwOGY%26blend-x%3D242%26blend-y%3D480%26blend-w%3D838%26blend-h%3D46%26blend-fit%3Dcrop%26blend-crop%3Dleft%252Cbottom%26blend-mode%3Dnormal%26s%3D1ec795a48155da5917419ebc2d5d0aa6)
git rebaseの使い方をやっと理解したので忘備録 - Perlテックブログ(跡地)
git rebaseの使い方をやっと理解したので忘備録を書いておこうっと。 他の人とのやりとりはgit mergeだけで十分 普段の作業はgit mergeだけで十分。ほぼすべての場合は、git mergeだけで十分。これを肝に命じておく。 git rebaseはコミット粒度を上げるためにgit branchとセットで使う git rebaseとは、小さな多数のコミットを、ひとつのコミットにまとめたいときに使う。 少し修正して、commit、試験。少し修正して、commit、試験。少し修正して、commit、試験。普段の作業はこんな感じじゃないのかな。 でも、コミットのメッセージを書く単位よりも小さく、コミットしたいときはよくある。ここ一行だけ変えて、試験したいとかね。コミット粒度を小さくしておけば、間違った部分だけを、git revertで戻せるし、git resetで戻れるから。 gi
Announcing Sourcegraph 2.4: free, powerful search for your private code | Sourcegraph Blog
Advanced codebase search, batch changes, and insights
Git入門 - Gitの仕組みを速攻で理解する
Gitの場合も基本的な運用では任意の場所にGitサーバを立てます。そして各自のローカルのTortoiseGitやEclipse,ターミナルなどで接続します。 ここまではSVNと一緒なのですが、gitの場合はここで各自のローカルにもリポジトリができあがります。当然、作業フォルダ(ワーキングツリー)も存在します。 ここでSVNユーザの方は「は？なにいってんの？」ってなると思います。たぶん。 ですが、このローカルリポジトリがなかなか便利なんです。 ここではまず、「gitにはリモートリポジトリ・ローカルリポジトリ・作業フォルダ(ワーキングツリー)」という3つの状態があることを覚えておいてください。 覚えておくべきGit用語まず最初にSVN脳からGit脳に切り替えていきます。 同じ用語が出てきますが、意味が変わってくるのでまずSVNと比較しながらGitの用語を覚えていきましょう。 リモートリポジトリ
かゆいところに手が届く系の Git Tips 話 - tellme.tokyo
この記事は Git Advent Calendar 2016 の 20 日目です。git コマンドを日常的に実行するわけですが、外部スクリプトなどで個人的に日々改善しているお話についてまとめてみました。 ブランチ切り替えを手早くする git オペレーションで add,commit 並に多用すると思うのがブランチ切り替えで、特に remote にある branch の切り替えなどをショートカットしたくスクリプトを書きました。 $ git br で fzf/peco などのフィルタで切り替えてくれます。ブランチ切り替え系はよくある tips なのですが、何が便利かというと、remotes/origin/HOGE などのリモートにしかないブランチは git checkout -b HOGE remote/origin/HOGE してくれるようになっているので気にせずに checkout できます
これまで知らなかったGit機能を調べたまとめ - Qiita
変更のdiffを見ながらコミットメッセージを書く 教えてもらってから活用してる。見ながら書いたほうが具体的に書けるような気がする。 ```diff:余談...diffのシンタックスハイライト初めて使ったけど良い感じですね $ git commit -v 変更のdiffを見ながらコミットメッセージを編集できます Please enter the commit message for your changes. Lines starting with '#' will be ignored, and an empty message aborts the commit. On branch commit-v You are currently bisecting, started from branch 'test-git-bisect'. Changes to be committed: >
master への push を禁止するローカル git hook の正しい書き方 - 永遠に未完成
GitHub などで Pull Request ベースで開発をしていると、master には間違っても push したくないわけです。 GitHub 側には残念ながら master への push を禁止するような設定はできないので、仕方ないのでクライアント側の Hook で対応しようってことになり、この方法についてググるとこことかこことか、いくつか方法を紹介しているページが出てくるんですが、どれもやり方が間違っている*1ので、正しい方法を紹介。 何がまずいのか 上記に挙げた方法では、細かい部分は違ってたりするけど、git symbolic-ref HEAD を使って現在ブランチを見て、master だったら push を禁止する、という方法を取っている。 しかし、push はカレントブランチから行われるとは限らない。dev ブランチにいるときに git push origin maste
dfltweb1.onamae.com – このドメインはお名前.comで取得されています。
このドメインは お名前.com から取得されました。 お名前.com は GMOインターネット(株) が運営する国内シェアNo.1のドメイン登録サービスです。 ※表示価格は、全て税込です。 ※サービス品質維持のため、一時的に対象となる料金へ一定割合の「サービス維持調整費」を加算させていただきます。 ※1 「国内シェア」は、ICANN(インターネットのドメイン名などの資源を管理する非営利団体)の公表数値をもとに集計。gTLDが集計の対象。 日本のドメイン登録業者(レジストラ)（「ICANNがレジストラとして認定した企業」一覧（InterNIC提供）内に「Japan」の記載があるもの）を対象。 レジストラ「GMO Internet Group, Inc. d/b/a Onamae.com」のシェア値を集計。 2024年5月時点の調査。
Gitのデータモデル
近藤です。こんにちは。Gitは様々な利用の仕方ができますが、その基盤となるモデルは8個だけの簡単なモデルです。これらのモデルを理解していない状態でGitを利用すると、あたかもリポジトリが壊れたように見えてしまいます。Gitは難しいと言われますが、そういう感想を持つ人はGitのモデルを理解していない事が多いようです。 今回はGitを構成する中心モデルと、基本的なコマンドを実行した時のオブジェクト関係を解説します。 基本概念 Gitの基本概念は大きく2つにわかれます。 GitObject Reference GitObjectはGitで管理するオブジェクトです。CommitなどがGitObjectです。Gitリポジトリである.gitを開くとobjects配下にあるファイルがGitObjectです。GitObjectはそのコンテンツをハッシュ化した文字列を元に、先頭2文字で配置フォルダ、残りの文
gitコマンド派閥 - 弥生開発者ブログ
Misoca開発チームのmzpです。 開発チームでgitコマンドの使い方について話したら、それぞれ使い方が微妙に違っていることが分かりました。せっかくなので、それぞれの人に、なぜその使い方をしているか聞いてみました。 一時的に変更を退避させる方法 作業を中断するときにするとき、作業中の内容を退避させる方法です。 git stash派 git stash で退避させる派です。 そして再開するときは、 git stash pop で退避させた内容を適用します。 使っている理由は「コミットする内容はキレイに保ちたいので、作業中の内容はコミットしたくない」でした。 適当にコミットする派 適当な内容でコミットし、あとで cherry-pick するなり、 rebase するなりする派です。 使っている理由は「退避した内容をリモートのブランチにpushしたいので、普通にコミットしている」でした。 pu
「commit-m: GitHubコミットメッセージの文例が検索できるサービス」がとても便利だったのでcliから使えるコマンド書いた - ( ꒪⌓꒪) ゆるよろ日記
http://commit-m.minamijoyo.com/:titele という有名OSSのコミットメッセージを検索できるサービスがあって、英語のコミットメッセージを書くときに「あれ? これどういう風に書けばいいんﾀﾞｰ」ってときに例文を検索できて捗る。 commit-m.minamijoyo.com が、自分の場合はコミットメッセージ書くときはvim とか git commit -m とかからなのでCLIで検索できたらより捗るかと思ってGolangで書いた。 APIとかは無いようなのでクロールしてる。 GoQuery 使えばこの手のクローラーが一瞬でかけるのでよさがある。 github.com go get github.com/yuroyoro/gommit-m で入れた後に gommit-m keyword [page] で検索できる。
Go 言語のプロジェクト構成 - fugafuga.write
Go のプロジェクトのディレクトリ構成などについて プロジェクト構成 プロジェクトディレクトリをgo_workとする。 go_work ├── bin -> go install 時にバイナリが格納される ├── pkg -> 依存パッケージのオブジェクトファイル格納場所 └── src -> ソースコード格納場所 上記3つのディレクトリがあることが前提。 環境変数$GOPATHにプロジェクトディレクトリを指定することで、依存パッケージの解決が自動的に行われる。 % cd go_work % export GOPATH=`pwd` パッケージについて Go のパッケージは、Ruby で言うところの gem にあたる。 パッケージは自分で作ったり、Git などでリポジトリが公開されていれば、それをgo get コマンドでコピーして利用できる。 パッケージの作成 gosample というパッケ
A useful template for commit messages — David Winterbottom
Here’s a useful heuristic for writing better commit messages. Set your commit message template to: # If applied, this commit will... # Why is this change needed? Prior to this change, # How does it address the issue? This change # Provide links to any relevant tickets, articles or other resources and you’ll be guided into writing concise commit subjects in the imperative mood — a good practice. Se
Gitを学んでいて「なるほど！」となる瞬間 | POSTD
Gitは速く柔軟性がありますが、理解に時間のかかる分散型バージョン管理システムです。Gitを始める前に次を理解しておきましょう。 通常のバージョン管理 分散型バージョン管理 本 や 学習書 、 指南書 はGitを理解するのに役に立ちました。しかし、その他にもGitの理解に至ったきっかけがありますのでご紹介します。 ステージング・エリアがある Gitにはステージング・エリアがあります。繰り返しますが、 ステージング・エリアがあるのです 。 これには混乱しました。リポジトリ（「オブジェクトデータベース」）とステージング・エリア（「インデックス」と呼ばれる）の両方がGitにはあります。チェックインには2段階あります。 git add foo.txt インデックスにfoo.txtを追加します。これだけでは、チェックインは完了していません。 git commit -m "message" リポジトリ
git commitをやり直しする＆取り消しする(「get commit --amend」と「git reset」) - hogehoge foobar Blog Style Beta
git commitを実行あとでコミットをやり直したり、コミット自体を取り消す方法です。 直前にしたコミットをやり直す（git commit --amend） 直前にしたコミットをやり直す場合、「git commit --amend」を使用します。 例えば、直前のコミットログが以下のような状態だったとします。 実は直前のコミットに含めるべきであった「hoge.txt」が含まれていませんでした。 コミットログ(git commit --amend 実行前) $ git log commit cca638b48b4c8be7ad5432f7882497534b04e2b4 Author: mrgoofy <hogehoge@example.com> Date: Wed Sep 8 23:03:57 2010 +0900 2nd Commit.-> New Add File : bar.txtこ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
git fetchの理解からgit mergeとpullの役割 - Qiita
