中級Git操作
今回の記事の内容はGitHub共同創業者のScott Chacon氏の「Pro Git」と同氏の今年の「So You Think You Know Git」（Gitがわかっているとでも思っているか？）発表をベースにしている。 コンフィグ ここでコンフィグにてデフォルトとして指定して損がないオプションをいくつか紹介します。 git rerere git rerereは"reuse recorded resolution"（記録ずみ解決方法を再利用）の略語になっている。 名の通りマージコンフリクトがどう解消されたかを記録し、次に同じようなコンフリクトが発生した際、同様の解決方法を自動的に適用するためのコマンドです。 また、基本的にデフォルトにしてもときに差し支えないため、ぜひgit config --global rerere.enabled trueを実行してみてください。 git main
Git中級者への第1歩！ レビュー品質向上の秘訣、コミットに便利なコマンドを紹介
「Women Developers Summit 2023（デブサミウーマン2023）」で大反響だったセッション「Git中級者への第1歩」が、パワーアップしてCodeZineに帰ってきました。この連載では、コマンドの使い方やGitの効率的な学び方など、知っておくと役立つ情報をお届けし、基礎から更なるステップアップを目指すみなさまを応援していきます。 はじめに こんにちは、都内でソフトウェアエンジニアとして働いている藤澤です。最近はフロントエンドの開発を担当しており、TypeScript、Reactあたりをよく触っています。 今回は「Git中級者への第1歩」と題しまして「普段の業務では困らないくらいにGitを使えているけど、もっと便利にGitを使いたい」という方向けの記事を3回にわたって書いていきます。 本連載は「Women Developers Summit 2023」にて筆者が発表した「
え？まだgit checkoutしてるの？
公式ドキュメントには以下のように書かれています。 THIS COMMAND IS EXPERIMENTAL. THE BEHAVIOR MAY CHANGE. 和訳：このコマンドは実験的です。動作が変更される可能性があります。 この記事の内容と違う場合があるので、ご注意ください。 この記事は2024年2月28日時点の情報です。 え？まだgit checkoutしてるの？ git checkoutといえば、ブランチを切り替えたり、git addしたファイルを元に戻したりするコマンドですが、それはもう古いです。 実は2019年8月リリースのgit 2.23からgit switchとgit restoreが追加されました。 知らなかった人も多いのではないでしょうか？(恥ずかしながら私は知らなかった...) 「先輩、checkoutってなんすか？」と後輩に聞かれる前に、この記事を読んでgit sw
Gitのコミットメッセージの書き方（2023年ver.）
本記事のモチベーション 約8年前、Gitを使い始めたときに以下の記事を公開したところ、想像以上の反応をいただきました。 当時はSubversionからGitに移行し、試行錯誤をしている中だったこともあり、多くの反応をいただけたことはモチベーションのひとつでした。 ただ、時が経ち、当然かもしれませんが現在は当時と違う書き方をしており、思想として変わっていない部分はあるものの、今でもときどきLikeをいただく中で、アップデートを全くしないのは誠実じゃないなと感じていました。 というわけで、現在のフォーマットも数年後には変わっている可能性が高いですが、その時々のスナップショットを公開することにも何らか意味があるかなと思い、「今の僕はこうコミットメッセージを書いているよ」というのをまとめました。 Gitを使う環境 開発フローやホスティングサービスごとのUIのdiffによって、最適なフォーマットは変
特別な理由なしにgit-flowを新規採用するべきではない - Qiita
私がこれまでGitの研修講師やブランチ戦略のコンサルティングをおこなってきた経験に基づいて、この記事を書きます。 Gitのワークフローについては自転車置き場の議論になりがちであまり乗り気がしないのですが、最近少し発見があったのと、実際に多くの現場で明らかにフィットしないのに git-flow を検討したり採用したりしようとして苦労をしている様を目撃することが多いので書くことにしました。 この記事で主張する内容はタイトルの通りですが、まず前提として以下を宣言しておきます: 全てのケースに100%フィットするようなワークフローは存在しない git-flowがフィットするケースも探せばあるかもしれない 例えばすでに何年もgit-flowでうまく回せてるよ、など どのようなワークフローを採用するかは最終的にはあなた（のチーム）が判断すべき さて、 git-flow は 2010年1月「A succ
Git の仕組み (1) - こせきの技術日記
目次 はじめに Git を使ったことがない方へ 生のデータが見たい方へ Git の全体像 .git の中身 Git オブジェクトデータベース 4種類のオブジェクト リファレンス リファレンスのリファレンス 大きなツリー Git オブジェクトの ID と 中身 ハッシュ関数 SHA1 の簡単な説明 tree と blob オブジェクト tree と blob の参照関係 ルートツリーの ID でツリー全体を識別する commit オブジェクト リファレンスとブランチ ブランチ ブランチ先頭を指すリファレンス HEAD リファレンス detached HEAD 2種類のタグ 一時待避 (stash) インデックス キャッシュとしての役割 マージ Fast-Forward マージ non Fast-Forward マージ rebase reset 2種類のブランチ 各リポジトリが自分のブランチを
ブランチ追従コストが大幅DOWN! RettyアプリチームがFeature Branchを捨てFeature Flagでの開発へ移行した理由と成果 - Retty Tech Blog
Feature Flagで 素早くマージ 安全にリリース Rettyアプリチームの @imaizume です、新しい年度が始まり新卒社員も入社してフレッシュな気分になる今日このごろですね。 今回は最近Rettyアプリチームで利用することが増えている、Feature Flagを使った開発についてのお話です。 Feature Flagを使うことで、大規模な開発であっても開発中から継続的に差分をマージできるようになり、デリバリー効率を大きく向上させることができます。 本記事では、この方法を採用するに至った背景や実際に取り入れて感じたメリット、課題感などを書きましたので、読んでみてメリットが感じられたならぜひみなさんの開発でも取り入れてみていただければと思っています。 Feature Flagとは? FFを採用する前の開発の様子 RettyでのFFによる開発の始まり アプリチームでFFを採用したこ
Gitのおすすめエイリアス5選 - 詩と創作・思索のひろば
緊急新人エンジニア応援企画！ ということで自分が Git のエイリアスとして設定している便利コマンドを紹介していく。 直前のコミットに追いコミットする (git fixit) git commit --amend --no-edit もろもろ整えて git push しよう、とすると「あっちょっと修正したい」となるのはよくあること。その際いちいちコミットメッセージを書いて rebase するかというとそんな面倒はとりたくなく、一撃で終わらせたい。--no-edit でコミットメッセージを編集せずに --amend できる。 git fixit に設定している。git commit の引数をそのまま受け付けるので、git fixit -a や git fixit <file> のように使える。 メインブランチに戻る (git com) f() { remote_head=$(git symb
コミットはスナップショットであり差分ではない
Git は紛らわしいという評判です。用語や言い回しが意味するものと、そこから想像する挙動が違ってユーザーが混乱すると言われます。これは、git cherry-pick や git rebase のような「履歴を書き換える」コマンドに最も顕著です。私の経験では、この混乱の根本的な原因は、コミットは 差分 であり順番を入れ替えることができるという解釈にあります。しかし、コミットはスナップショットであって、差分ではありません! Git がリポジトリデータをどのように保存しているかを見てみると、Git を理解しやすくなります。このモデルを調べた後に、この新しい視点が git cherry-pick や git rebase のようなコマンドを理解するのにどのように役立つのかを探っていきます。 本当に深く 掘り下げたいのであれば、Pro Git という書籍の Git Internals の章を読むと
絶対に止められない超重要サービスをGitOpsで安全に開発できるようにしている話 - BIGLOBE Style ｜ BIGLOBEの「はたらく人」と「トガッた技術」
自己紹介と前置き こんにちは、BIGLOBE谷山です。 ここ最近はコロナの影響もあって、2,3か月くらいほぼ出社していないので 出勤経路を忘れかけています。 現在携わっているProjectは、何十台ものサーバから構成されるRADIUSシステムを、オンプレミスからAmazon Web Services（AWS）に移行し、かつ一部機能はサーバレス化するというProjectです。 RADIUSシステムは240万人超の会員様が利用している認証システムなので絶対に落とせません。なので、より安全に運用していくために「GitOps」の仕組みを取り入れようと開発を進めています。 モバイルコア技術部 テクノロジー開発グループ 谷山 大介 (まだ外に出れたころに山に行った時の写真です。) 2021/08/30 追記： 続編を書きました！ style.biglobe.co.jp GitOpsとは そもそもGit
ふだんの開発でPRを出すときに考えていること - 私が歌川です
業務の話です。OSSとかだとまた変わってくるのかもしれないし、共通することもあるかもしれません。 先に作戦を練る 実装する前に、方針段階でレビューしてもらえるとよい 自分だけでは気づけない考慮漏れとか、こういう方針もあるよっていう提案とか、いろいろ得られるものがある 先に実装完成させてから、これでは要件を満たせない・うまくいかないねってなるともったいない 巨大なPRにしない diffの大きさについては、プログラミング言語とか、利用するフレームワークによっても変わってくるので、一概には言えなさそう +1500, -1500 だけどスナップショットの更新があったとか インデント1つ下げることになったとか たとえば、あらゆる機能を1つのPRで実装してたら巨大なPRになると思う 1つのPRであらゆるものを実装しない、1機能ずつ実装するとか、1つの層だけ実装する、とか PRが巨大だと、コミュニケーシ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
gitでstashが面倒なあなたにautostash
Git の最新アップデートから考える開発手法の潮流