Gut - Ease your journey with Git
Git made easy Gut is a user-friendly Git CLI for Windows, Mac, and GNU/Linux. With intuitive commands and streamlined workflows, Gut simplifies the process of using Git's complex system, allowing you to focus on your code. Download A useful set of commandsHere are some of the most useful commands from the gut CLI
Git 2.27.0 から git pull をすると表示されるようになった "Pulling without specifying how to reconcile divergent branches is discouraged." について - ESM アジャイル事業部 開発者ブログ
最近の趣味はもっぱら L7 より下のお勉強、な @yucao24hours です。 梅雨入りもどこ吹く風の暑いある日、いつものように git pull を実行すると、以下のような警告が出るようになりました。 $ git pull warning: Pulling without specifying how to reconcile divergent branches is discouraged. You can squelch this message by running one of the following commands sometime before your next pull: git config pull.rebase false # merge (the default strategy) git config pull.rebase true # rebas
今いるレポジトリのPR一覧をpecoで絞り込んでcheckoutする便利コマンド作った - $shibayu36->blog;
OSS活動とか仕事をしてる時に、PRをチェックアウトするのだるいなと思っていた。そこで「今いるレポジトリのPR一覧をmodified順に出力し、pecoで選択したものをcheckout」出来たら便利だろうということで作った。 できたもの やり方 まずhubとpecoをインストールしておく。 zshを使っているならこんな感じで定義し、 function peco-git-recent-pull-requests () { local selected_pr_number=$(hub pr list --limit 40 --sort updated --format "%pC%>(8)%i%Creset %t (by @%au)%n" | peco | sed -r 's/^ +#([0-9]+).*$/\1/') if [ -n "$selected_pr_number" ]; then
Gitのワークフローについての私のスタンス | おそらくはそれさえも平凡な日々
Gitのワークフロー、好みが分かれる分野で自転車置き場の議論にもなりがちだと感じている。基本的にはプロジェクトの流儀に素直に従い、余計なストレスを抱えないのが良いと考えている。例えば、私はマージコミットを作るのが好みだが、OSS活動等では「squash & mergeして」って言われることもあり、そういうときは当然素直に従うようにしている。 ということで、私のGitのワークフローについてのスタンスについて書いておこうと思う。私と一緒に働く人や、働くことを検討している人の参考になればと思います。もちろん、この辺りは、良い方向に変化もさせていきたい。例えばエントリー内でも触れていますが、私は昔はforce pushを禁止したいくらいでしたが、今は使っても良い、と思うようになりました。 Natureの特にGoでのバックエンド開発はこれに近い感じだとイメージしてもらえればと思います。ただ、できてな
パーシャルクローンとシャロークローンを活用しよう
Git のリポジトリが大きくなると、新しい開発者がクローンして作業を始めるのが難しくなります。Git は 分散 バージョン管理システムとして設計されています。つまり、リポジトリとのやりとりを管理する中央サーバーに接続しなくても、自分のマシンで作業ができるということです。これが完全に実現できるのは、すべての到達可能なデータがローカルリポジトリにある場合だけです。 もっと良い方法があったらどうでしょうか？Git の全履歴にあるすべてのファイルのすべてのバージョンをダウンロードしなくても、リポジトリで作業を始めることができたらどうでしょうか？Git の パーシャルクローンやシャロークローンという機能は、こういったケースで役立ちます。その一方でこれらの機能にはトレードオフもあります。これらの選択肢は Git の分散という性質によってもたらされる可能性を少なくとも一つは壊してしまうため、こうしたトレ
git-notesでコミットにメモをつける - アジャイルSEの憂鬱
2020年に「コミットログは良くならない」というのを悟ったので、現実的な解決案である「git-notesでメモを残す」について記事を書いておきます。 前回の記事 sinsoku.hatenablog.com git-notes 詳細は git notes --help を読んでください。 概要は以下の通りです。 コミットログとは別にメモを残せる コミットはそのままなのでshaは変わらない shaが変わらないのでCIの再実行が起きない 他人のコミットにメモをつけられる 他人に作業を依頼する必要がない メモもリモートにプッシュできる 過去のコミットにメモを残せる 使い方 メモを書く git notes edit <sha> でメモを書くと、git log のときに一緒に表示される。 $ git notes edit d2cdf0b $ git log -1 d2cdf0b commit d2c
コミットはスナップショットであり差分ではない
Git は紛らわしいという評判です。用語や言い回しが意味するものと、そこから想像する挙動が違ってユーザーが混乱すると言われます。これは、git cherry-pick や git rebase のような「履歴を書き換える」コマンドに最も顕著です。私の経験では、この混乱の根本的な原因は、コミットは 差分 であり順番を入れ替えることができるという解釈にあります。しかし、コミットはスナップショットであって、差分ではありません! Git がリポジトリデータをどのように保存しているかを見てみると、Git を理解しやすくなります。このモデルを調べた後に、この新しい視点が git cherry-pick や git rebase のようなコマンドを理解するのにどのように役立つのかを探っていきます。 本当に深く 掘り下げたいのであれば、Pro Git という書籍の Git Internals の章を読むと
開発チームの生産性・健全性を客観的に知るためにリポジトリ履歴から機械的に可視化するツールを作った - Qiita
はじめに ソフトウェア開発のチームの生産性や健全性というものは、内部の体感的として理解できるものの、外部の人間からは見えにくいものです。こういった情報の非対称性は開発チーム外の人々との関係の中での問題の原因になってきました。 また、複数の開発チームやプロダクトを束ねるEM、CTOや、管理職にとってそれぞれの状況を客観的な数字やグラフで可視化することは、全体的な戦略を考える上でも重要な参考情報になります。ですが、アンケートやプロジェクト管理を増やすほど、どんどんと開発メンバーに負担をかけてしまうことになり、計測のし過ぎによる疲れなども誘発してしまいます。 本稿では、gitリポジトリのログ情報から、いくつかのグラフを生成し、チームの状況を可視化するためのツールgilotを作成したので、その目的と意図、そして使い方、注意点を解説します。 アプローチ方法 gilotのアプローチは、git logの
Git / GitHub を使用したチーム開発時のガイドラインを制定しました | DevelopersIO
開発時にはみなさん Git や GitHub を使うと思いますが、使い方についてチームメンバー間で微妙に認識の違いがあると進捗を妨げてしまいます。それを防ぐためにガイドラインを定めてみました。 ちなみにこれは CX 事業本部の Tech Lead のお仕事紹介第 1 弾のポストです。 この記事の英語版も書きました。 前提 CX 事業本部ではクライアントからの開発案件や自社サービスの開発をしていますが、その際に有用な（と考えている）ガイドラインです。 様々な事情でチームメンバーが変更になる可能性があり、新規メンバーの立ち上がりを支援する意味合いも込めています。そのため、開発効率をなるべく落とさずに効果的なスキルトランスファーが実施できることを主眼としています。 ガイドライン 定めたガイドラインの全文を貼ります。 3 つのセクションに分かれています。 commit 時のガイドライン avoid
ブランチ名を意識しないで git push する方法 - Beeeat’s log
普段開発する時に今まではブランチ名を頭で記憶して，git push origin ブランチ名で push していた． しかし，途中で忘れていること場合は何度も調べ直したりして効率が悪い． git push の後に，さらに git コマンドを実行する 以下のように，git push origin の後に自分が現在チェックアウトしているブランチ名を表示するコマンドを実行すれば良い $ git push origin $(git rev-parse --abbrev-ref HEAD) まとめと所感 今回はブランチ名を意識しないで git push する方法についてまとめた．今回の内容は今まで一番小さい小ネタだがほぼ毎日使うため，メモとして残してみた．
Learn Git Branching
A interactive Git visualization tool to educate and challenge!
pre-commit
pre-commit A framework for managing and maintaining multi-language pre-commit hooks. Git hook scripts are useful for identifying simple issues before submission to code review. We run our hooks on every commit to automatically point out issues in code such as missing semicolons, trailing whitespace, and debug statements. By pointing these issues out before code review, this allows a code reviewer
脱ブランチファースト - 日々常々
あるいは「プルリクエストをやめてみた」 チーム構成とかにもよるんだろうけど。Gitかつフォークされないプロダクトでの話です。OSSとかは全然話は変わります。 問題とアプローチ (2019-10-25T15:20 追加) 表出している問題と、ここでのアプローチを書いておきます。 ブランチファースト（造語） 「ブランチファースト」はこのエントリでの造語です。コードベースに変更を加える際に「まずブランチを作成する」から始めることを指します。 作業単位でブランチを作成、ブランチでコードを変更してプルリクエスト、レビューを経てメインライン（ master ブランチ）に反映までがブランチファーストのスコープになります。 よくあるスタイルだと思いますし、ブランチだけ作成して変更せずプルリクエストを作成する拡張もありますね。 プルリクエストを挟まずにメインラインにマージするものは含みません。 ……名前微妙
Highlights from Git 2.21
CommunityEngineeringHighlights from Git 2.21A look at some of the new features in recent Git releases. The open source Git project just released Git 2.21 with features and bug fixes from over 60 contributors. We last caught up with you on the latest Git releases when 2.19 was released. Here’s a look at some of the most interesting features and changes introduced since then. Human-readable dates wi
Git 業務で役に立ったコマンド達 - stone's throw
業務でGitを使うようになって完全に理解した*1ので、役に立ったコマンド達をここに記しておく。 Git編 その前に Gitコマンドは割と雰囲気で使っていたが、特に$ git checkout --helpと$ git reset --helpを見たら思ってたのと違う概念だったので先におさらいしておく。 checkout $ git checkout branchで特定のブランチに移動する、あるいは特定のブランチの状態をワーキングツリーに再現する。 前者の概念はみんな知っているけど、後者の概念は最初触った時にはあまり意識できていなかった。 特定のブランチの状態をワーキングツリーに再現するので、現在のブランチで何らかの変更をしてしまっても$ git checkout branchnameあるいは$ git checkout .でそのブランチの最新の状態（つまり、変更を行う前）に戻すことができる
Gitで日本語長文のdiffをとる方法 - Qiita
（この記事はここからの転載です） 課題 日本語の長文をgitで管理していると、ほんのちょっとの変更でもdiffでは行丸ごと変更されたことになり、変更点がよくわからないことがある。 二泊三日で小説を書く過激なイベントNovelJam 2018参加作品である高橋文樹氏の「オートマティック クリミナル」は、GitHubを使って執筆されている。小説では、git diffの欠点がはっきりでる。高橋氏は参加レポートで、こう書いている。 あと、今回得た重要な知見なのですが、Githubではある程度以上テキストが長くなってくると、数文字の調整で全部差分として判定されたりするので、小説には向いてないかなーと思いました。小説は行の移動とかがよく発生するので、GithubじゃなくてGitとの相性かもしれません。 普通にdiffを取る 確かに、普通にdiffをとるとその通り。コマンドラインで「オートマティック ク
Semantic Versioningをアプリケーション開発でやっていく · Tomohisa Oda
ソフトウェアのバージョン管理は、かつて曖昧なものでした。Semantic Versioningは、バージョニングを明確に定義し文書化したものです（TOMLやGitHub創設者で有名なTom Preston-Wernerのプロジェクト）。これにより、OSS界隈の人々はバージョニングの意味を共通認識可能なものとして、早くから導入していました。最近では、Goの標準モジュール管理としてもSemantic Versioningが利用されることになり、Goのライブラリ開発者は否が応でもSemantic Versioningを考える必要があります。 APIの変更に互換性のない場合はメジャーバージョンを、後方互換性があり機能性を追加した場合はマイナーバージョンを、後方互換性を伴うバグ修正をした場合はパッチバージョンを上げます。プレリリースやビルドナンバーなどのラベルに関しては、メジャー.マイナー.パッチの
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - github/renaming: Guidance for changing the default branch name for GitHub repositories
GitHub - snwfdhmp/taskr: Automated testing: No-regression implementation using git hooks
Git History