発端 Pull Request で force push されると差分がわからなくなるから困るんだけどみんなどうしてますか？— codehex.bsky（へっくす） (@codehex) 2024年2月25日 ポストの前提がちょっとわかりませんが、レビュー後にforce pushされると、どこに修正を入れたのかわからないケースだと仮定します。プルリクエストがまだドラフト状態でのforce pushやrebaseで困るケースはそんなにないと思うからです。 git commit --fixup このケースではgit commit --fixupが便利です。レビューで指摘が入ったコミットに対して--fixupをかけておき、レビュワーはfixupコミットの内容を確認します。レビュワーが確認してOKが出た段階で、git rebase -i --autosquashなどを使ってfixupコミットを元コ
ブログに書いていなかったことに気づいたので、残しておく。 モチベーション OSSや仕事のコードを修正してるときに「まだ動作確認ができていない」「コミットメッセージの説明が不十分」なコミットが手元に溜まることがある。 このパッチの一覧を確認するため、シェルスクリプトを使っている。 シェルスクリプト このファイルを PATH の通ったディレクトリに git-patch というファイル名で置く。 $ cat << 'EOF' > ~/bin/git-patch #!/bin/bash ls ~/ghq/github.com/*/*/.git/refs/heads/patch/* grep refs/heads/patch ~/ghq/github.com/*/*/.git/info/refs EOF $ chmod +x ~/bin/git-patch Gitは git-*** という命名規則の
2020 年 12 月以降に Homebrew で brew update をしようとすると次のようなエラーが出て処理が実行できないことがあります。 Error: homebrew-core is a shallow clone. To `brew update` first run: git -C "/usr/local/Homebrew/Library/Taps/homebrew/homebrew-core" fetch --unshallow This restriction has been made on GitHub's request because updating shallow clones is an extremely expensive operation due to the tree layout and traffic of Homebrew/homebre
すると、対話モードが開始されます。対話モードでは、git statusと似た「どのファイルがステージに追加されているか・されていないか」といった情報と、この対話モードで実行できるコマンドの一覧が表示されています。 ❯ git add -i staged unstaged path 1: unchanged +4/-0 Cargo.lock 2: +1/-0 nothing Cargo.toml *** Commands *** 1: status 2: update 3: revert 4: add untracked 5: patch 6: diff 7: quit 8: help What now> status は git status とほぼ同等の目的を達成できますが、ステージした変更が左側、ステージしていない変更が右側に表示されます。直感的ですね。 update は、実行後ファイ
リモート リポジトリの追加 新しいリモートを追加するには、リポジトリが保存されているディレクトリでターミナルから git remote add コマンドを使います。 git remote add コマンドは 2 つの引数を取ります。 リモート名 (例: origin) リモート URL (例: https://github.com/OWNER/REPOSITORY.git) 次に例を示します。 $ git remote add origin https://github.com/OWNER/REPOSITORY.git # Set a new remote $ git remote -v # Verify new remote > origin https://github.com/OWNER/REPOSITORY.git (fetch) > origin https://github.c
自分が作業したコミットをpushしプルリクエストを作成しようとしたところ、プルリクエスト作成画面が表示されずにそのままリモートリポジトリのmainにコミットがマージされてしまいました。 原因はリモートリポジトリのmainからブランチを切らずにmainに直接コミットしてしまったこと、またそのままgit push origin mainでpushしたことでした。 同じbranchにpushした時は自動でマージされることを忘れていた……。 私は現在FJORD BOOT CAMP で勉強をしているのですが、Slackのwakaranチャンネル（文字通り分からないことがあった時に質問できる）でヘルプを出したところ色々教えていただき、無事解決したので手順などを書いておこうと思います。 前提 mainに直接追加したコミットをpushしてマージされてしまった状態から、コミットを別のブランチとしてpushし
綺麗にコミットしてますか？？ はじめまして！Emojineerのnownabeです。グッドパッチではProttのサーバサイドエンジニアをやっています 本記事ではGitのコミットを綺麗に保つためにProttチームで導入しているEmoji Prefixを紹介します。 Emoji Prefixって何？ Emoji Prefixは「Gitのコミットメッセージの先頭にEmojiをつけよう」という一種のスタイルガイドです。 GitHubなどEmojiに対応しているGitホスティングサービスの利用を前提としています。 Emoji Prefixをつけてコミットすると、例えばGitHubならこのように表示されます。 基本はコミットメッセージの先頭にEmojiをつけるだけです。 ただし、EmojiはEmoji Prefixのルールに従って決める必要があります。 コミットの種類によってEmojiが決まる、という
Git は紛らわしいという評判です。用語や言い回しが意味するものと、そこから想像する挙動が違ってユーザーが混乱すると言われます。これは、git cherry-pick や git rebase のような「履歴を書き換える」コマンドに最も顕著です。私の経験では、この混乱の根本的な原因は、コミットは 差分 であり順番を入れ替えることができるという解釈にあります。しかし、コミットはスナップショットであって、差分ではありません! Git がリポジトリデータをどのように保存しているかを見てみると、Git を理解しやすくなります。このモデルを調べた後に、この新しい視点が git cherry-pick や git rebase のようなコマンドを理解するのにどのように役立つのかを探っていきます。 本当に深く 掘り下げたいのであれば、Pro Git という書籍の Git Internals の章を読むと
これは『フィヨルドブートキャンプ Advent Calendar 2020 Part 2』7日目の記事です。 https://adventar.org/calendars/5230 こんにちは！メンター枠の odaillyjp です。 今回は生徒の方々向けに「コミットを整理してみよう」という話をします。 コミット整理の重要性「Ruby で ls コマンドを作る」や「Sinatra を使って Web アプリケーションの基本を理解する」などの実装を必要とするプラクティスでは、生徒は実装したプログラムを Pull Request で提出し、メンターに確認していただいていますよね。 私はメンターの立場ということで皆さんの Pull Reqeust をレビューしていますが、実装されたコードを読んでいて、いつも「実装しないといけない機能が盛り沢山である中で、なるべく実装をシンプルにまとめようと頑張って
おはようございます😄プログラミングの学習中のFuushi−です。 今回はフィヨルドブートキャンプ内で実施しているアドベントカレンダー2020用に書いた記事になります😄 adventar.org Part 2もあります✍️ フィヨルドブートキャンプ Part 2 Advent Calendar 2020 - Adventar 「フィヨルドブートキャンプ Part 1 Advent Calendar 2020」の5日目の記事です。 昨日記事はima1zumiさんの 初学者が Ruby on Rails の広大さに途方にくれたけどなんとかやっていけるようになった話 でした😃 ima1zumiさん記事を拝見して共感した点は下記部分です🤔 結局は自分で手を動かして、悩んだり苦しんだりしないと、本やサイトを読んだだけでは、あまり理解できないのかな、と思いました エンジニアに必要な自走力を高める
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
はじめに こんにちは、クレイの亀井です。ここ最近一気に気温が上がりましたね。顔に重点的に汗をかくタイプの私には憂鬱な季節がやってまいりました さて、今月正式リリースしました(！) DocBase プロジェクトではクレイ外部のデザイナーの方と一緒に開発しています。SourceTree で Git を使っている方で、軽いデザイン修正などは弊社の Rails プロジェクトに直接手を加えてプルリクエストを送ってくれます。 こちらのデザイナーさんに「プルリクエストを送る際は、作業ブランチで git pull --rebase origin master してから送ってもらえますか？」とお願いすると「pull はわかるんですけど、この --rebase ってなんですか？これつけると何が変わるんですか？」と質問がきたのです。 作業ブランチで git pull --rebase origin master
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
