git pullを実行する際に、ローカルで未コミットの変更に対して、リモートの状態で上書きせず、ローカルでの変更を保持したい場合や、やっぱりリモートの変更で上書きしたくなった場合の対処方法についてのご紹介です。 こんにちは、CX事業本部の若槻です。 git pullを実行する際に、ローカルで未コミットの変更をリモートに反映させずローカルでだけ保持したい場合があります。 例えば、以下のようにhoge.txtの変更がローカルで行われていますが、この変更はリモートには反映したくないため、未コミットとしています。 $ cat hoge.txt ローカルでの変更 $ git fetch $ git diff remotes/origen/master diff --git a/hoge.txt b/hoge.txt index 48ee78d..e3130ae 100644 --- a/hoge.t

始めに 私は最近エンジニアに復帰し、現場で便利に思ったことを今後記事にできたらと思っています。 そして1発目は、gitのオプションについて記事を書いてみようと思います。 --fixup はどんな時に使えるの？ Pull Requestなどで、軽微な指摘や後から気付いた修正など、本来の機能のコミットとは別に修正コミットを残すのは少し嫌な時がありますよね。 コミットが一つ手前であれば、直前のコミットを修正してくれる git commit --amendなどで対応できますが、3つ前のコミットに修正を混ぜ込みたい時などは、少し大変。 そんな時に便利なのが、この git commit --fixupです。 使い方 例えば、下記のコミットの状況で、Fix article pageのコミットに対して、追加の修正をしたいとする。 ❯ git log --oneline 1131338365 (HEAD -

みなさんこんにちは、電通国際情報サービス（ISID）Xイノベーション本部ソフトウェアデザインセンターの佐藤太一です。 この記事では、Git を使った仕事のやり方（以降は Git ワークフローと記載）を設計する上での検討事項を説明します。 これによって、読者の皆さんがGitワークフローを適切に定義できるようになることを主たる目的としています。 また、筆者の能力不足によって記載しきれなかった考慮事項について、より深く Git を使いこなしている識者からの指摘を受ける機会を得ることを副次的な目的とします。 この記事には書かれていないものの、検討すべき事項について知見のある方はブログ記事を書いたり、Twitter等のSNSで指摘してくださるとありがたいです。 はじめに 基本的な考え方 Git ワークフロー設計における考慮事項 チームの人数 monorepoの検討 参考文献 プロジェクト管理ツールと

はじめに 業務で複数のAWSアカウントを扱っており、ソース管理のリポジトリ「CodeCommit」も複数アカウントにまたがったものを並行して使用しています。 そういった場合に「git clone」する際のSSHパス設定をどのように扱えば良いかを整理しました。 どういった方法があるのか 複数CodeCommitの管理方法を調べてみると、以下のような記事を発見しました。 「複数AWSアカウントのCodeCommitからgit cloneする際のssh設定についての覚書」 https://qiita.com/SpeakEasy/items/e92a494a3f6a5f81a74c 簡単に説明すると、SSHコンフィグに任意のホスト名を定義して、そのホスト名で「git clone」するという方法です。「aws1」「aws2」というホスト名をつけた例が記載されています。 git cloneする度にHo

データアナリティクス事業本部の笠原です。 複数のプロジェクトでCodeCommitを使っていると、AWSアカウントが異なる関係で、各リポジトリで認証情報が異なるケースが出てきます。AWSの認証情報はプロファイル毎に分かれて保存していると思いますが、CodeCommitを利用する際にどのように切り替えていけばいいでしょうか。 ローカルPCからCodeCommitへアクセスする際の認証方法には以下の方法が考えられます。 Git認証情報を使って、HTTPS接続 Git 認証情報を使用した HTTPS ユーザーのセットアップ - AWS CodeCommit git-remote-codecommit を導入して、HTTPS接続 git-remote-codecommit を使用して AWS CodeCommit への HTTPS 接続をセットアップする手順 - AWS CodeCommit AW

Git管理下でローカル編集した差分を検知除外したい時にはgitignoreではなくgit update-indexを使おう 環境に合わせた修正を差分として検知させたくなく、gitignoreに追加していました。が、結果は変わらず。動作を確認してみると、git update-indexを使うことが動作としては期待するものになると理解しました。環境依存の設定であるため、個々で指定が必要になります。 はじめに gitでのバージョン管理対象にしつつも、編集差異を検知させたくないというケースは時折あります。環境変数設定用ファイルの内容をプロジェクト共通の初期値にしておき、各々の環境に合わせて調整する等。 「.gitignoreに突っ込んで完了」と思いきや、バッチリと差分が検知されました。上手くマッチしていないのかと表記をあれこれ試していましたが、そもそものやり方が違っていることを知りました。 知って

Git moves at a surprisingly fast pace - as of Aug 2021, the current version of Git (git --version) is 2.33. I don't normally know or care what my Git version is, but over the past year this changed. The Git team must be doing something right, because I've noticed a few things trickle down to my relatively light usage: init.defaultBranch The default branch in Git is named master. As of Git 2.28, yo

The Git plugin that comes bundled with all JetBrains IDEs is actually quite impressive, it's a full blown Git client in its own right with almost all the features of a standalone client such as SourceTree, Tower or GitKraken but built into the IDE. But there are even more features you can enhance your IDE’s Git support with - allow me to present to you 5 plugins that build on top of Git and superc

Git における、git commit の取り消し方法や、やり直し操作に関する方法をまとめました。Git はどんなコミットでもすべてを記録していますので、一度間違えたとしても、いつでも昔の記録からもとに戻せ事が保証されています。 取り消しや、やり直し方法をマスターすれば、バージョン管理ツールとしてのメリットを最大限享受することができます。 git commit の取り消し方法、６選 コミットした直後に「あっ、この変更入れ忘れた！」「あっ、いらないファイルを混ぜてコミットしちゃった！」など、確認不足による間違いは、時間に追われるエンジニアに非常にしばしば発生します。そのような間違いコミットは、まだpushしていなければ、容易に取り消したり、その後コミットをやり直すことができます。 コミットの取り消しにまつわるケースを、下記の６種類に分けてご紹介します。 直前の git commit 実行を取

WEBサービス開発歴7ヶ月目に突入しましたにこと申します。 先日、GithubにAWSアクセスキーをあげてしまいました。 その時は事の重大さをわかっておらず、言われるがままにコマンドをうち対処が出来たのですが、調べれば調べるほど「とんでもないことをしていた・・・！」ということがわかりました。 AWSで不正利用され80000ドルの請求が来た話 初心者がAWSでミスって不正利用されて$6,000請求、泣きそうになったお話。 もう今後アクセスキーをあげることはないですが、愚かな人間なのでまた何らかを間違えてやってしまうかもしれません・・・。 二度とないことを誓いつつ、もし万が一やらかしてしまった場合、また同じようにアクセスキーをあげてしまったような方に向け、手順をしっかり残したいと思います。 まずはAWSのアクセスキーを無効化 ※2021/1/30追記 Githubの手順よりも先にAWSのアクセ

Git の中身を詳しく知りたい人に説明する時のメモ 時間があるなら Pro Git を読めば OK Git は分散型 VCS （SVN とか Perforce はみんなが中央サーバにアクセスする集中型） 各自のマシンにリポジトリのクローンが作られる リポジトリとは .git/ があるディレクトリのこと 差分の蓄積ではなくスナップショットを保存して歴史を管理 あらゆるスナップショットやコミットオブジェクトなどにダイジェスト （SHA-1 ハッシュ） がついてる ファイルのとりうる状態 Untracked / Unmodified / Modified / Staged (Stash) / Workspace / Stage / Local Repo. / ……… / Remote Repo. master ブランチは git init した時のデフォルトのブランチ名 origen は git

This domain may be for sale!

「Recursiveマージストラテジー」は、「Resolveマージストラテジー」同様、2つのブランチをマージする時に使用できる「マージストラテジー」です。 現在の「Git」では、「Recursiveマージストラテジー」によるマージがデフォルトの「マージストラテジー」です。 共通のコミットオブジェクトが1つ存在する場合 「Resolveマージストラテジー」同様、2つのブランチの共通の「親コミットオブジェクト」を「マージベース」にし、それぞれのブランチの「コミットオブジェクト」のファイル群を「3ウェイマージ」により、マージします。 共通のコミットオブジェクトが複数存在する場合 「十字マージ」では、複数の共通の「親コミットオブジェクト」が存在します。 これによるメリットは、「マージコンフリクト」の発生量の軽減や、ユーザーの意図をマージ結果に反映させやすくなる点です。 Recursiveによるマー

git-merge の--ff, --no-ff, --squashの違いをまとめてみた。 git helpから引用 まずは、git helpを読みましょう git merge --helpから引用（抜粋） NAME git-merge - Join two or more development histories together SYNOPSIS git merge [-n] [--stat] [--no-commit] [--squash] [-s <strategy>] [-X <strategy-option>] [--[no-]rerere-autoupdate] [-m <msg>] <commit>... git merge <msg> HEAD <commit>... git merge --abort OPTIONS --ff, --no-ff Do not gene

gitを使ったワークフローで困ったなぁ、どうしようと思ったのが、SASSからコンパイルされたCSSの扱い。べき論で言うと、いわゆる「ビルド後に生成されるファイル」はコンフリクトの要因になるためgitで管理すべきではない、です。生成後のファイルは履歴を管理する必要がないのでそもそも対象にすべきではない、ですよね。その通り。 なんですけど、それだとテストアップ前に手元でCSSを生成してFTPするか、テストサーバでコンパイルされるようにするか、テストサーバへの反映に一手間必要になってかなり面倒。せっかくリモートリポジトリへのpushで自動デプロイできるようになっても、CSSだけFTPするとか泣けちゃう。。 CSSをgitで管理しない場合に困る事 CSSを管理しない場合、テストサーバにCSSを反映するためには次のいずれかの作業が必要になります。 テストアップ時に手動でコンパイルしてFTPする（面倒

Webサービスやアプリ開発の現場では必須のバージョン管理システム「Git（ギット）」。Gitは、専用のソフトを使えばクリックで直感的に操作することもできますが、いざというときにコマンドが使えると便利です。 前回の 第5話 では、特定のコミットを打ち消すコマンド「リバート」を学びました。 ・特定のコミットを打ち消す & git revert [打ち消したいコミットID] 今回の第6話では、特定の時点までファイルを巻き戻す「リセット」を学びます。このリセットには3種類方法があります。git reset --soft、--mixed、--hardです。「これらは何が違うのか？どのように使い分ければいいのか？」初心者の方は困ってしまいますよね。このマンガを通して、わかばちゃんと一緒に理解していきましょう！ 【筆者】湊川 あいさん フリーランスのWebデザイナー・漫画家・イラストレーター。マンガと図

2014初頭に書いた「WindowsにおけるGit利用環境は整った： Git for Windows と SourceTree for Windows」の最後の文： ブランチは、Gitのなかで最も重要でありながら最も分かりにくい概念でしょう。表面的な言葉に騙されず、先入観を持たず、SourceTreeの視覚的表示（樹形図）の力を借りながら学習するのが、理解への一番の近道です。 そんへんの詳しいことはまたの機会に述べるかも知れません。 1年半以上たってしまいましたが、「またの機会」がやって来ましたよ。ええ、Gitの説明をします、ブランチを中心に詳しく。 「基礎編」と「ブランチ編」で2回に分けようかと思ったけど、長大な記事として一挙公開。これからGitを使う人が対象ではありません。Gitが何をやっているのか、自分が何をやっているのかイマイチ自信が持てない方向けです。 ブランチやマージって、なん

社内向けに「こわくない Git」というタイトルのスライドを作って発表しました。 対象者は「マージがなんとなく怖い」「エラーが怖い」「リベース使うなって言われて怖い」と、Git が怖いと思っている人です！ こわくない Git from Kota Saito 発表中に出た質問など 補足も兼ねて、上のスライドを発表した際に出た質疑応答などをここに書いておきます。 Q: 常に Non Fast-Forward (--no-ff) でいいのでは、と思えるけど git merge がデフォルトだと Fast-Foward or Non Fast-Forward (--ff) なのはなぜ？ A1: Non Fast-Forward だと、確かにメリットが多いのですが、1点だけデメリットがあります。特に差分が無い状態で git merge --no-ff すると、空のマージコミットが作られてしまうのです。