gitのコミットメッセージを日本語にした話［bash関数でgitコマンドの入力を楽にしよう］ - Qiita
こんにちは、CAMPFIREエンジニアのishimizuです。 これまで20年近くエンジニアをしてきて今年大きく開発スタイルを変革した事がありましたので経験談を踏まえてまとめていこうかなと思っています。 突然ですが、皆さんgitのコマンドは何をよく使っていますか？ webエンジニアに限らずエンジニア稼業をしていれば、当然毎日使うgitコマンドですが、git commitやgit pushは欠かせないと思います。 私も毎日git pushやgit commitを打ちまくっています。git mergeやgit cherry-pickも人よりはよく使うかも知れません。 git rebaseとかはよく分からないので使わないようにしています。 ブランチの歴史がおかしくなったら1から作り直して必要なコミットを古いものからcherry-pickして新たに歴史作るほうが絶対に早いし安全です git rev
Gitのコミットメッセージの書き方（2023年ver.）
本記事のモチベーション 約8年前、Gitを使い始めたときに以下の記事を公開したところ、想像以上の反応をいただきました。 当時はSubversionからGitに移行し、試行錯誤をしている中だったこともあり、多くの反応をいただけたことはモチベーションのひとつでした。 ただ、時が経ち、当然かもしれませんが現在は当時と違う書き方をしており、思想として変わっていない部分はあるものの、今でもときどきLikeをいただく中で、アップデートを全くしないのは誠実じゃないなと感じていました。 というわけで、現在のフォーマットも数年後には変わっている可能性が高いですが、その時々のスナップショットを公開することにも何らか意味があるかなと思い、「今の僕はこうコミットメッセージを書いているよ」というのをまとめました。 Gitを使う環境 開発フローやホスティングサービスごとのUIのdiffによって、最適なフォーマットは変
Gitでのファイル名変更 - Qiita
起こったこと gitを使って開発をしている際に、text_HOME.svgというファイル名をtext_home.svgに変更したところnothing to commit, working tree cleanと言われました。 どうやらファイル名の変更がGitに差分として認識されていないよう。 実験 同じような状況を再現してみます。 ディレクトリrename_testに実験用のファイルtext.txtが存在しており、working treeには何もない状態です。 それでは、test.txtをTest.txtにリネームしてみます。 普通にmvコマンドを使ってtext.txtをリネームしてもgitは差分を認識してくれません。 git mvコマンド 次はgit mvを使用してファイルをリネームしてみます。 今度はファイル名の変更が差分として認識されました🙌 参考 ファイルのリネームはgit mv
1つのgitリポジトリに複数の作業ディレクトリを作る - Qiita
（commit or stash + checkoutすらめんどいことだって、あるんですよ・・） そもそもリポジトリと作業ディレクトリの違いって？ gitリポジトリには、コミットされている内容やブランチなどの全ての情報がつまっています。一方で作業ディレクトリは、リポジトリ内のあるcommitの内容を、ファイルとして書き出したものになっています。 git-new-workdirコマンド gitリポジトリに紐づく新たな作業ディレクトリを作成します。 ただし、デフォルトでPATHが通っていません。Fedoraあたりなら /usr/share/doc/git-1.7.10.2/contrib/workdir/git-new-workdir に、homebrewなら /usr/local/Cellar/git/1.7.12.4/share/git-core/contrib/workdir/git-n
複数のGitリポジトリを一つにまとめる - Qiita
また例によって他の方の例の通りにやっても自分の希望通りにはできなかったので、自分なりの試行錯誤も込めて。 目的 複数のGitリポジトリを一つにまとめたい。 まとめた後、元のリポジトリは削除し統合したリポジトリで運用したい。 ローカルリポジトリ間で統合させたい（いろいろ試行錯誤したかったため） ディレクトリ構成も綺麗にしておきたい。 参考の方法ではディレクトリ構成が希望通りに行かなかったり、 ディレクトリ構成は上手くいってもリポジトリが希望通りにマージされなかったりしたので その辺りを対処した手法になります。 構成 parent_repo（親リポジトリ、新規に作成） ├child_repo1 ├child_repo2 └child_repo3 Finder上で見るとまとめた後は以下のような構成になります。 作業の前に 元のリポジトリにあるブランチはmasterにマージしておくなど、綺麗な状態
ローカルでgit管理を行う（bareリポジトリを利用） - 気ままに技術勉強ブログ
はじめに こんにちは、良い技術ブログが書けるよう日々試行錯誤しているエヌです。 この記事では「bareリポジトリを利用したローカルでgit管理を行う方法」についてを書いています。 GitHubなどをのサービスを使いリモートリポジトリと連携して履歴管理などを行ってますが、個人的な資料もgitで管理したくて、ローカルだけでgit管理できないのかなぁと思ったのがこの記事を書いたきっかけです。 以前に似たような記事を書きましたが、今回はbareリポジトリを利用してgit cloneができるような管理を行っていきたいと思います。この方法だと例えば社内でサーバーを立ててチームでGitを使う、ということもできるようになります 自分に向けた備忘録も目的ではありますが、「サーバーとか要らなくて個人PCだけで履歴の管理が行えるようにしたい」な人の一助になれば嬉しいです。 Note bareリポジトリとは何か、
Gitの社内研修やってみた – 資料公開 – その2 – クリエイティブスポット
■はじめに（公開資料の説明） バージョン管理システムのスタンダードである「Git」。 前回、社内研修で使った資料のうち、前半部分である「領域とコマンド」の用語説明と概念図を公開しました。 この記事では、その続きである「ブランチモデルと識別子」の説明で使った用語説明と概念図を公開します。 また、こちらもアトラシアンのBitbucketとSourcetreeを使用する前提での内容となっています。 あくまで研修で使用した資料ですので、説明としては不足していたり、あくまで正確性よりも概念を示すだけの部分があると思いますが、これからGitの社内研修をするにあたって何か資料の参考になるものをお探しの方に役立てていただければと、以下に公開します。 それでは、どうぞ！ ↓ ●ブランチモデルと識別子 ▼ブランチ プロジェクトの変更履歴（コミットの重なり）を分岐させて枝分かれさせたもの。 「main」（旧名「
【Git】リポジトリをコンパクトにする - MarkdownとBullet Journal
リポジトリのディスク容量を削減する 開発を何年も継続し続けるとリポジトリもそれなりの規模になる。エンジニアの心理としてはリポジトリを整理したくなるもので、５種類の方法を紹介する。 方法 過去へのアクセス 削減度 作業の手軽さ git-gc ◎ 50%～ ◎ partial-clone ◎ 90%～ ◯ shallow-clone ◯ 90%～ ◯ logic-compress ◯ 90%～ △ reborn ✕ 100% ◯ その１：git gcを用いる これは最も簡単でそれなりの効果が得られる手段だ。通常Gitはfileをsnapshotして全て保存しているが、git gcを発動するとバイナリfileに差分保存することでディスク容量を圧縮する。オプションを付ける事でさらに圧縮率を上げる事が可能。 programmingforever.hatenablog.com その２：クローンサイズを
リモートリポジトリをローカル環境に作成してgitの練習をする - Qiita
はじめに gitコマンドの挙動を覚えるためには、ひたすらに実践するのが効果的です。 ただ、githubなどにリモートリポジトリを作成すると、ターミナルだけでgitコマンドの実行をすることが難しく、勉強するのにめんどくささがつきまといます。 そこで、ローカル環境にリモートリポジトリを作成することで、ターミナルだけでgitの練習ができる環境を構築します。 ローカルにリモートリポジトリを作成するとは リモートリポジトリについては、gitのドキュメントに以下の記述があります。 リモートリポジトリとは、インターネット上あるいはその他ネットワーク上のどこかに存在するプロジェクトのこと リモートリポジトリとは、githubやAWSのcodecommitなど、ローカル環境ではないところを指すような印象を持ちますが、ローカル環境というネットワークを使えば、ローカルリポジトリとリモートリポジトリをローカル環境
結局 Git のブランチ戦略ってどうすればいいの？ - Qiita
1つのIssueが大きくなると1 Pull Requestで大量の差分が発生します。 そうなるとレビュワーに負担がかかり、コンフリクトの可能性も高まり、コードレビューを効率よく進めることができません。 このINVEST原則を守ることでチームはより効果的に作業を進め、柔軟に対応して開発を進めることができます。 Git Flow Git Flowは5種類(main, hotfix, release, develop, feature)のブランチを運用するブランチ戦略です。 2010年に提唱された有名なブランチ戦略です。 オンラインサービスのように継続的デリバリーするコードを想定して作られた戦略ではないです。 main ブランチ 常にリリースできる状態を保つ hotfix, develop へ切り出す このブランチへの直pushはNG hotfix ブランチ バグ修正など緊急時に対応するためのブ
ソースコード管理の進化：Excel管理からGitHubまで、エンジニアの戦いを振り返る！ - Qiita
ソースコード管理の進化：Excel管理からGitHubまで、エンジニアの戦いを振り返る！ プロローグ 先日、弊社のとある案件内での会話です。 熟練エンジニア（以降「熟練」と表記）：GitHubのプルリクが来てたからコードレビューしておいたよ。 若手エンジニア（以降「若手」と表記）：ありがとうございます。助かります。 熟練：他の人のコードにも指摘した内容がキミのコードにもあったので指摘しておいた。他の人のプルリクは見ていないの？ 若手：いや、他の人のプルリクは見てないですね。。 必要ですかね・・？ 熟練：必要だよ。昔はそういうのやりたくてもできなかったんだから！ 若手：（はじまった、熟練さんの昔語り・・。長いんだよなぁ。。）なるほど！そうなんですね。他の人のコード読んで勉強します！ はじめに 皆さん、こんにちは。エンジニア歴約20年目の立脇です。今日は、エンジニアにとって切っても切り離せない
初めてのGitは電車で例えて学ぼう！初学者向け基本Gitコマンド入門 - Qiita
Gitを学びたての人へ Gitを学びたての皆さん、こんにちは！今年の4月よりエンジニアとして新卒入社した k_uki512です！🎉 会社の新人研修や、プログラミングスクールでGitを初めて触り始めた方もいらっしゃるのではないでしょうか。そんな方が「分からない」という状態に陥りやすいのが "Git" のコマンドだと思います。 分からない理由を分析してみた Gitのコマンドが分かりづらい理由として以下のような原因があると考えました。 データをコマンドでやり取りすることがなかった 用語いっぱい。違いが分からない、、（add,commit…） データ（変更履歴）の流れが見えづらい つまり変更履歴という概念が抽象的かつ、pushまでのステップが多いことが原因だと考えました。 そこで、この記事ではGitの一連の流れを、わかりやすく電車に例えて解説していきます！ この記事を通じてGitの流れを学び、会
｢これはHEAD^^｣ ｢これはHEAD^2｣ ｢これはHEAD~2｣｢HEAD@{2}､reflog用｣｢全部いっしょじゃないですか｣｢違う!!もっとよく見ろ!!｣ - Qiita
｢これはHEAD^^｣ ｢これはHEAD^2｣ ｢これはHEAD~2｣｢HEAD@{2}､reflog用｣｢全部いっしょじゃないですか｣｢違う!!もっとよく見ろ!!｣Git 画像略 TL;DR(Too Long; Didn't Read) ~nは単純なコミットの親をたどる(ブランチの分岐がある場合は現在のブランチのみで辿れるコミット) ^nはマージコミット向けで^2は｢そのコミットの2番目の親(取り込んだブランチの前回のコミット)｣ だからHEAD^n(n > 2)は存在しない 2024/06/04追記： OctopusなMergeだと３つ以上のブランチからマージできるので^nも存在する......があまり見かけることはない HEAD^^は｢HEAD^の親｣､HEAD^2は｢HEADのもう一人の親｣みたいな......｡タラちゃんがHEADだと波平がHEAD^^でマスオがHEAD^2です(
Git の GUI クライアントを使ってみた比較：SourceTree/Fork/GitKraken
Git の GUI クライアントにはずっと SourceTree を使っていましたが、Windows 版で見過ごせないひどい有様があらわになったのを見て、よさそうなのを他に２つ試してみた記録です。 書くのは SourceTree Fork GitKraken の３つです。Git を GUI クライアントで使用している人のほとんどはこの 3 つのうちのどれかに落ち着いているんじゃないでしょうか。 あとずっと気になってたんだけど、Git ってみんなどう使ってるのか全然知らない。エンジニアならみんな興味ありそうなネタなのにそういう記事とか特集も読んだことないのよなー。普通にターミナルからコマンド打つ人、VS Code 内蔵（かもしくは関連する拡張機能）のやつ、あとは GUI クライアントって感じですかね。この 3 つはどういう比率になるんだろう。 結果的には Fork が最高ということでその後ず
ミクシィ、新卒向け研修資料を無償公開 「Git」と「テスト・設計」 今後も随時公開
MIXI（旧社名ミクシィ）は5月8日、同社の新入社員向け技術研修で使用した資料を無償公開した。分散型バージョン管理システム「Git」とテスト・設計研修の資料をスライド共有サービス「Speaker Deck」で公開中。動画も後ほど公開するという。 Gitの研修資料は約470ページあり、Gitを使ったチーム開発の進め方やGitの内部構造などを記載している。テスト・設計研修の資料は約40ページ構成で、テスト技法やコードレビューのコツなどを紹介。いずれの資料も同社の社員が作成した。 同社は2021年から新入社員向け研修の資料を一般公開しており、22年はUnityでのゲーム開発やAI、セキュリティ研修など全12種類の資料を自社ブログに掲載していた。同社の公式Twitter（＠mixi_engineers）は「今後も随時資料や動画を公開していく」としている。 関連記事 ミクシィ、技術カンファレンスを初
初学者の私がGitを理解するために、この順番で読めばよかったと思った記事の順番 - Qiita
エンジニア未経験のわたしがGitを学ぶ上で、この流れで記事を読むべきだったと思ったことを記載する。 完全に初学者意見のため、疑いながら読んでください。 私は下記の流れで学習することによって、理解をしやすいように感じた。 ① Gitで何をしているかのイメージを掴む（コマンドなし） ② Gitのイメージを、コマンドで実現している記事をみる ③ 実際にGitのコマンドを打ちながら、出力と、頭の中のイメージのすり合わせ Gitで何をしているかのイメージを掴む（コマンドなし） こちらの記事は、Gitのイメージをコマンドなしで、わかりやすく図で示してくださっています。 記事にも記載されていますが、 ・重要なのは 「何」から「何」へ・「どんな作業」を行う のかを追う ・操作前と操作後でどんなことが起こっているのかをイメージする 上記の内容が、すごく同意で、重要だと感じている。いきなりコマンドを打ちながら
Gitコマンドの結果一体どうなるのかをすばやくアニメーション画像を生成して視覚的にわかりやすく見せてくれる「git-sim」
プログラマー育成を支援するInitial Commitが、ローカルリポジトリにおけるGitの動作をシミュレート可能なコマンドラインツール「git-sim」を2023年1月22日にリリースしました。git-simを使うことで、Gitコマンドがリポジトリに及ぼす影響を視覚化した画像やアニメーションを生成できます。 git-sim - Visually simulate Git operations in your own repos with a single terminal command. https://initialcommit.com/tools/git-sim GitHub - initialcommit-com/git-sim: Visually simulate Git operations in your own repos with a single terminal c
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
サル先生のGit入門〜バージョン管理を使いこなそう〜【プロジェクト管理ツールBacklog】
Pushing & branching: git for hardware - AllSpice.io
Git入門
