2024年Gitワークフロー再考 | フューチャー技術ブログ
春の入門祭り2024の2記事目です。 Gitは、出自としては1週間で作られたLinuxカーネルのための分散バージョン管理システムでした。当時のワークフローに合わせてパッチをテキスト化してメールに添付できるような機能だったりが備わっています。 一方で、現代のGitは、デファクトスタンダードなバージョン管理システムになりLinuxカーネル以外のアプリケーション開発で利用されています。分散バージョン管理ではあるものの、サーバー・クライアント型の使われ方をしていて、GitHubやGitLabを核にして、ローカルで作ったブランチをpushして、Pull Requestの形にして管理しています。少なくとも周りで見る限りでは、それ以外の使われ方の方が少なくなってきてます。そんなこんなで求められている使われ方が変わってきていて、それに合わせた機能がぼちぼち増えています。それを活用することで、ウェブ画面上で
git diff を徹底攻略！よく使うオプションまとめ | WWWクリエイターズ
さて、これらの違いは混乱しやすいので、図を使って少し詳しく見ていきます。 「diff」と「diff --cached」の比較対象の違い さて、おさらいですが、 通常は比較元（デフォルトでインデックス）から作業ツリーへの差分 --cachedで比較下（デフォルトでHEAD）からインデックスへの差分 を見るように動作します。図にすると以下のようなイメージです。 HEADは「作業中ブランチの先頭コミット」を指しますので、現在のコミットを作ろうとしている時、作業ツリーとインデックスの変更状況について分を調べたい時はもっぱら「git diff」「git diff --cached」「git diff HEAD」のいずれかを使うことになると思います。 インデックスと、コミットの関係 「インデックス」は「ステージ領域」とも呼ばれますが、この概念が Git 特有なので、入門者は非常に混乱しやい点だと思いま
GitLabからGitHubに移行してみた（SRE編） | GRIPHONE ENGINEER'S BLOG
こんにちは。SREの徳田です。 今回は、「GitLabからGitHubに移行してみた（アプリケーションエンジニア編）」のSREチーム視点なるものを書いてみようと思います。 とはいえ、アプリケーションエンジニア編で素晴らしいほどにまとめてあるため、こちらでは実際に行った作業やGit LFSについて書いていきます。 Git LFS Git LFSとは Git LFSとはGit Large File Storageのことで、以下の機能を提供しています。 大きなファイルのバージョニングより多くのリポジトリ容量高速なクローン・フェッチGit workflowと同じ様に利用Gitと同様のアクセス制御 導入方法は簡単で、Windowsの場合はGit for Windowsをインストール、Macはbrewを使って導入することができます。 また、基本的にはインストール時に自動的にやってくれるはずですが、以下
Git LFSをAmazon S3でいい感じにする話 - YDiary
はじめに 皆さんはソースコードリポジトリの保存先として，GitHubなどのホスティングサービスをお使いでしょうか． また，リソースファイルなどのバイナリファイルを管理するためのリポジトリのサイズが肥大化していたりしないでしょうか． 実は，GitHubなどのホスティングサービスでは推奨されるリポジトリのサイズが決められており，そのサイズを大幅に超過するようなリポジトリは運営による凍結・削除の対象となってしまうことがあるのです． この記事では，そうしたリポジトリの肥大化を，バイナリファイルをソースコードとは別で管理することによって防ぐことが可能なGit LFS (Large File Storage)と，Git LFSのサーバとしてAmazon S3を活用する方法などを紹介します． 推奨されるリポジトリのサイズ 各ホスティングサービスで推奨されるリポジトリのサイズは次の通りです． GitHub
デザインデータ管理をGit LFSにした話
みてねではデザインデータの管理にGit LFSを使用しています。 昨年から運用を開始したのですが、データ管理が改善され、フローも安定して回って来たので紹介します。 Git LFSとは？Gitで画像などのバイナリファイルを扱うための拡張機能Sketch, Photoshop, IllustratorなどのデザインデータもOKGitHubの単一ファルの上限である100MBを超えたデータサイズのファイルを扱えるファイルサイズの上限が変わる以外は通常のGitと同じです。 Git LFS 事前準備・設定リポジトリの作成github.comでデザイン用のリポジトリを作成します。 用意できたらリポジトリのSettingsでLFSを有効にするだけです。 みてねでは現状 2 data packs（月10ドル）使っています。 Storageが足らなくなっても Purchase more からポチるだけなので楽
git reset --hardした内容を取り消す (git reset --hard, reflog, HEAD@{x}, 取り消してしまったコミットを元に戻す) - いろいろ備忘録日記
相変わらずGit勉強中です。 以下自分用のメモです。 特定のコミット自体をなかったことにするには git reset --hard ... を利用すればいいのですが、このコマンドはhardとオプションが ついているように、コミット自体が無かったことになってしまいます。 なので、間違えて違うコミットの部分にresetしてしまうと ｱﾜﾜﾜな事になります。（というか、なりましたｗ） でも、さすがgitさん。当然元に戻す方法がありました。 reflogを使って、元に戻せます。 元に戻す場合に利用するコマンドも git reset --hard です。 git reset --hard "HEAD@{x}" xの部分には、reflogの番号が入ります。 通常元に戻す場合は、"HEAD@{1}"になると思います。 # 試すためのブランチつくって切り替え git checkout -b test-br
git submoduleについてのメモ 追加/削除/更新等
B! 70 0 0 0 Gitのsubmoduleがいつもイマイチ良くわからなくなるので 自分なりのまとめ。 レポジトリにsubmoduleの追加 submoduleのあるレポジトリをcloneする submoduleの更新 submoduleの削除 ignore = dirty Submoduleのプロトコルの変更 レポジトリにsubmoduleの追加 git submodule addで追加。 $ git submodule add [email protected]:rcmdnk/evernote_mail.git ./submodules/evernote_mail addすると.gitmoduleというファイルがまだ無い場合は作られ、その中に [submodule "submodules/evernote_mail"] path = submodules/evernote_mai
Gitを実践的に使うために参考にすべき記事20選
チームで開発を行うときにGitのスキルは必要不可欠なものとなってきています。以前、Git初心者向けにスライドをまとめたものを紹介しましたが、今回はGit（GitHub）をさらに活用するために参考にしたい記事を紹介します。 この記事は以下のような方におすすめです！ ・ブランチをどのように運用すれば良いのかわからない。 ・コミットメッセージの書き方にいつも悩んでしまう。 ・issueやPull Requestをもっとうまく活用したい。 ・Git�やGitHubに関する便利なテクニックを知りたい。 ・間違ってコミットしてしまったけど対処法がわからない。 今回は、運用編、コミットメッセージ編、issue編、Pull Request編、テクニック編、問題解決編と５つの内容で分類してみました。実践的な読み応えのある記事ばかりなので、ぜひ参考にしてみてください。 運用編 中の人に聞いたGitHub fl
gitにおけるコミットログ/メッセージ例文集100
私はコミットログの書き方に悩む英語の苦手な人間である。実際、似たような人は世の中に結構いるようで、頻出単語を集計したりまとめたものは既にあって役に立つのだけれど、これらはあくまで単語の話であり、具体的な文を構成する過程でやっぱり困る部分がかなりあった。 要するに、どういう時にどういう文が使われているのか、ということを示した例文集が欲しいのである。ググると他にも「例文集があればいいのに」みたいな声はあるくせして、しかし誰も作ろうとしない。何なんだお前ら。それじゃ私が楽できないじゃないか。 仕方なく自分でまとめたので、増田に垂れ流しておく。 はじめにここで挙げているコミットログは全て実際のコミットログからの転載である。当然ながら各コミットログの著作権はそれぞれの書き手にある。いずれも各英文でググれば出てくるし、フェアユースの範囲なら許してくれるだろうと考え名前とプロジェクト名は割愛したが、ここ
Gitのデータモデル
近藤です。こんにちは。Gitは様々な利用の仕方ができますが、その基盤となるモデルは8個だけの簡単なモデルです。これらのモデルを理解していない状態でGitを利用すると、あたかもリポジトリが壊れたように見えてしまいます。Gitは難しいと言われますが、そういう感想を持つ人はGitのモデルを理解していない事が多いようです。 今回はGitを構成する中心モデルと、基本的なコマンドを実行した時のオブジェクト関係を解説します。 基本概念 Gitの基本概念は大きく2つにわかれます。 GitObject Reference GitObjectはGitで管理するオブジェクトです。CommitなどがGitObjectです。Gitリポジトリである.gitを開くとobjects配下にあるファイルがGitObjectです。GitObjectはそのコンテンツをハッシュ化した文字列を元に、先頭2文字で配置フォルダ、残りの文
プライベートな Composer リポジトリを作成する - ngyukiの日記
Composer のプライベートなリポジトリがあればいいなーと思って Composer のサイトを眺めていたら、思っていたより簡単にできました。ちょっとした社内ライブラリとかの配布を管理するのに便利かもしれません。 ディレクトリ構成 一連の作業をひと通り終えると次のようなディレクトリ構成になります、パスなどは適用に読み替えてください。なお、web/ が http://packages.example.org のドキュメントルートになっているものとします。 /var/www/vhost/composer/ composer.phar config.json web/ ← ここが http://packages.example.org のドキュメントルート index.html packages.json satis/* Composer リポジトリのセットアップ まずは Composer の
Git 2.7 の優れた新機能 | Atlassian Japan 公式ブログ | アトラシアン株式会社
Git 2.6 からわずか 2 カ月後、膨大な機能と修正、そして性能の向上を果たした Git 2.7 がリリースされました。ここでは Bitbucket チームが興味を持った新しい機能を紹介します。 git worktree の完成 Git 2.5 で導入された素晴らしい git worktree コマンドを使うと、複数のリポジトリブランチからのチェックアウトやブランチ上での作業を、異なるディレクトリで同時に行うことができます。たとえば、簡単な修正をする必要があるけどワーキングコピーを汚したくない場合、次のように新しいブランチを新しいディレクトリにチェックアウトすることができます。 Git 2.7 には、リポジトリのワークツリー (および関連するブランチ) を表示する git worktree list サブコマンドが追加されています。 ワークツリーをサポートする git bisect コ
git submoduleの更新 - rochefort's blog
2017.8.31 追記 この記事は間違っています。正しくは下記でした。 git submoduleの更新方法を勘違いしていた 昔書いた記事を参考にしてくださった方がいて、 でも「git submodule updateで更新できないよ」と。 gitのsubmoduleだけを最新版にしたい場合のコマンドメモ - Reinvention of the Wheel 私自身もgit submodule updateで更新できると思ってました。 というか、一度も更新処理試してなかった。 結論から言うと これでOKでした。foreach便利。 $ git submodule foreach 'git pull origin master' $ git submodule update ですが、no branch になってしまってるsubmoduleがあったので、pullするのはこっちの方がいいかもし
Mac に bash-completion, git-completion を導入する - KainokiKaede's diary
bash-completion zsh ユーザーに dis られる前に completion できるようにしよう。 $ brew install bash-completion ~/.bash_profile に以下を追加。 if [ -f `brew --prefix`/etc/bash_completion ]; then . `brew --prefix`/etc/bash_completion fi 導入が成功していれば、ssh と入力して TAB を押すと IP のリストが表示される。 git-completion.bash これを導入すれば git のコマンドを補完してくれるようになる。上記リンクから git-completion.bash をダウンロード。これを適当な場所に置いて、.bashrc に以下のように記述する。 source /path/to/git-complet
自分が必要とする最低限の git submodule の知識 - Qiita
それは git プロジェクトに別のリポジトリの特定コミットを示すポイントを埋め込むものです。 理屈の上では、「どのディレクトリに対して、どのリポジトリが関連付けられており、コミットオブジェクトのハッシュはこれです」っていう情報が管理されているだけのシンプルなもの。 以下のような構成のプロジェクトを簡単に管理できます。 root_project/ ├── external_project │ ├── library1（独立した git リポジトリ） │ │ ├── lib │ │ └── src │ ├── library2（独立した git リポジトリ） │ │ ├── lib │ │ └── src │ ├── library3（独立した git リポジトリ） │ │ ├── lib │ │ └── src │ └── li
Gitでやらかさないための事前予防策 - Qiita
Gitでやらかした時に使える19個の奥義を書いてやらかしたときになんとかリカバリできるようにした。 今回は、そもそもやらかさないようにしたいよねっていうお話。 コミット編 .gitignoreを細かく指定しておく .gitignoreを指定しておけば余計なファイルをコミットしちゃうことを予防できます 過去に似たようなプロジェクトがあるのならそれを流用しましょう。 ないのであれば.gitignore.ioで生成してそれをカスタムしましょう。 ワイルドカード指定やディレクトリまるごとの指定は副作用ある可能性があるので慎重に。 コミットメッセージのフォーマットを決めておく コミットメッセージのフォーマットを決めておけば書き直したいということも減ります コミットメッセージをやらかして直したいと思うことはよくあります。 そういうのって案外コミットメッセージが自由すぎることが問題だったりします。 ある
プルリクエストをより使いこなす | POSTD
Gitを使用している人であれば、プルリクエストには馴染みがあるでしょう。これは、分散バージョン管理システムが世に出始めてから、何らかの形で使われています。BitbucketやGitHubのように凝ったWebユーザインターフェイスが構築される前は、プルリクエストは単純に電子メールベースで行われており、Aliceのリポジトリから変更をプルするように依頼していました。プルリクエストを受けた側がこの変更を妥当だと判断すれば、いくつかのコマンドを実行しmasterブランチに変更をプルするという流れです。 $ git remote add alice git://bitbucket.org/alice/bleak.git $ git checkout master $ git pull alice master もちろん、手あたり次第Aliceの変更をmasterにプルすることは、 得策 ではありませ
KYOKUTYO NO BLOG. » Blog Archive » Gitで特定ファイルを昔の状態に戻す
間違えてコミットしてしまったファイルを、前のバージョンに戻したい。いくつ前のバージョンに戻したらいいかわからない。という時に。 作業手順 ファイルの中身を確認 % git show HEAD^:path/to/file や % git show HEAD^^:path/to/file をして、以前のバージョンのファイルの中身を覗く。 特定のバージョンにファイルを戻す バージョンがわかったら戻す。 % git checkout HEAD^ path/to/file すると以前のバージョンの内容に戻ってる。 使用例 どんな場合に使うか(使ったか) 今回↓のような状態で使った。 % cat index.html ここは○○のホームページです // 普段の内容 % vi index.html あけましておめでとうございます。ここは○○のホームページです // 年始用 % git commit -
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Unity のプロジェクトで Git LFS を使い始めた記録
git submodule は癖がすごいとの噂だったが素直につきあっていけそうという話 | DriftwoodJP
