【初心者向け】git fetch、git merge、git pullの違いについて - Qiita
gitで手こずった時に色々ググってると、「git fetch」と「git pull」がぐちゃぐちゃになってしまったのでまとめておきます。 結論から言えば、「fetchもpullもリモートリポジトリの最新情報をローカルリポジトリへ持ってくる」という操作になりますが、それまでの流れが違うので説明していきます。 ##git fetch リモートから最新情報をローカルに持ってくるのですが、場所は「master」ブランチではなく、「origin/master」ブランチに取り込まれます。 初めは「何それ知らない」となるのですが、具体的に言うと 「master」ブランチ…ローカルの中心となる統合ブランチで、他のローカルの作業ブランチと繋がったもの。 「origin/master」ブランチ…ローカルにある、リモートのmasterブランチを追跡するリモート追跡ブランチ。 となります。 両方ともローカルにある
Railsのマイクロサービスアーキテクチャで構成されたアプリをモノレポ構成に移行した話 - Sansan Tech Blog
こんにちは。技術本部Sansan Engineering Unit Master Data Groupの古本です。 普段は、営業DXサービス「Sansan」の名刺交換した人や企業に関するニュースを表示し、お知らせする「企業ニュース」や「企業情報」を扱うシステムの開発をしています。 最近、マイクロサービスで作られた企業ニュースのシステムをモノレポ構成に移行しました。 今回はその時に行ったことについて話します。 モノレポ（mono repo）とは 本ブログで類似の記事があったので引用します。 一連のソースコードを単一のリポジトリで管理している状態のことです。 特に、実装言語、またはサブシステムやドメインといった何らかの区切りでリポジトリを分けている場合に、それらを集約することをモノレポ化と言います。 マイクロサービスアーキテクチャのリポジトリ構成を漸進的にモノレポに移行した話 今回も複数レポジ
フォークを同期する - GitHub Docs
Web UI からフォークのブランチを同期する GitHub で、アップストリーム リポジトリと同期するフォークされたリポジトリのメイン ページに移動します。 ファイルのリストの上で、 [フォークの同期] ドロップダウン メニューを選んでください。 アップストリーム リポジトリからのコミットの詳細を確認し、 [ブランチを更新] をクリックします。 アップストリーム リポジトリからの変更によって競合が発生した場合、GitHub は競合を解決するためのプルリクエストを作成するように求められます。 GitHub CLI を使ってフォークのブランチを同期する GitHub CLI は、コンピューターのコマンド ラインから GitHub を使用するためのオープン ソース ツールです。 コマンドラインから作業しているときは、GitHub CLI を使用して時間を節約し、コンテキストの切り替えを回避でき
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
クラスメソッドのReact事情大公開スペシャル#3 -「高速案件立ち上げで使われるマッハテンプレートのフロントエンド技術選定」というテーマで登壇しました #クラスメソッド勉強会 | DevelopersIO
西田@リテールアプリ共創部マッハチームです 先日、大阪で行われたクラスメソッドのReact事情大公開スペシャル#3で 「高速案件立ち上げで使われるマッハテンプレートのフロントエンド技術選定」 というタイトルで発表させていただきました 私が所属する「マッハチーム」はLINEミニアプリの開発を主軸とし、高速にプロジェクトを立ち上げMVPを作成する、プロジェクトの立ち上げの専門チームです。そこで使われてる、高速案件立ち上げのためのテンプレートではReactが採用されています。今回はマッハテンプレートのフロントエンド技術の選定についてお話しさせていただきました 資料 感想 40人近く参加いただき、関西のエンジニアのReactへの関心の高さを感じました。懇談会も多くの方に参加いただき、いろんな方と交流ができて楽しかったです。 また機会があれば発表させていただきたいと思います！
プルリクエストを見る時、出す時に重要なマインドセット - NRIネットコムBlog
本記事は 【プルリクウィーク】 4日目の記事です。 💻 3日目 ▶▶ 本記事 ▶▶ 5日目 📚 こんにちは越川です。 GitHubはアプリケーションの開発に携わる人がメインで使う、という印象が強かったのですが現在、クラウドエンジニアの私もほぼ毎日GitHubを触っています。 私の場合、業務上、IaCを使うのでプログラミングをする機会が多く、その分プルリクエスト（以降PR）を見ることも出すことも多くあります。今回は自分自身がPRを見る時、または出す時にどんなことを意識しているのかを書いてみようと思います。 ※PRとは新規開発や改修などの内容を関係者に通知する仕組みです。このPRをトリガーに関係者はコードのレビューを実施し、問題なければマージを行います。 ※IaCとはInfrastructure as Codeの略称で、サーバーやネットワークなどあらゆるインフラリソースをコード化し、構築を
「Squash merge」の注意点と使い方：開発プロセスを改善するためのヒント
今日は、squash merge についてご紹介します。先日、GitHubでソースを管理していたところ、squash mergeを使用しているときに起きた問題があったので、その共有になります。 Squash mergeとは Squash mergeは、Gitにおいて複数のコミットを一つにまとめる方法の一つです。通常のマージでは、複数のブランチを一つに統合することができますが、それぞれのコミット履歴がそのまま残ります。一方で、Squash mergeでは、統合する複数のコミットを一つにまとめ、新たなコミットとして履歴に残すことができます。 Squash mergeを行うことで、Gitの履歴を整理し、コミットログを簡潔に保つことができます。また、複数の小さなコミットを一つにまとめることで、コードレビューの際にもより分かりやすくなるというメリットがあります。 Squash mergeを行うには、
モノレポにすべきか、レポジトリを分割すべきか
先日 フロントエンドの Monorepo をやめてリポジトリ分割したワケ というブログがバズっていた。そのおかげか、Twitter でもモノレポに関する言及がちょこちょこあった。一家言あるドメインなので書きたい。ただの一家言(a.k.a お気持ち)なのでぜひ皆さんの意見も聞いてみたい。 tl;dr 別に自分はどっち派とかではなく、どっちも選ぶ。強いて言うならリポジトリ分割派で、依存更新がしんどくなったら monorepo 派。 免責 モノレポに対する一家言を書きたいだけであって、内容自体はフロントエンドの Monorepo をやめてリポジトリ分割したワケ と全く関係なく、そのブログで述べられている施策については何も言及しません。ただ一つ言及するとしたら肉の部位がコードネームに採用されているのは良いと思いました。🍖🍖🍖 モノレポにしたくなる状態の前提にあるもの 前提は元記事と同じように
設計ドキュメント腐る問題、Git管理で運用してみた結果 | フューチャー技術ブログ
はじめにTIG真野です。 秋のブログ週間2023 の3本目は、設計ドキュメントをGit管理して腐らせないようにがんばってみた話をします。 前段として6年前、「我々はいかにシステム開発におけるドキュメント腐る問題と戦えば良いのか」という記事を書いたのですが、その後の試行錯誤はどこにも残していないことに気づきました。普段のフューチャー技術ブログですとちょっと引け目を感じるテーマですが、秋の夜長を楽しむため読み物成分を多めに書くというテーマのこのブログリレーにピッタリな気がするため、この機会をお借りします。 ドキュメントも色々な種別があるかと思いますが、この記事では設計ドキュメントを指すことにします。設計ドキュメントは開発メンバーが参照するもので、ステークホルダーへの説明資料に引用して使うことはあれど、主目的は異なるという前提です。Design Docの場合もありますし、システム構成図、ERD、
Git で複数のコミットを1つにまとめられる「スカッシュ」というテクニック | DevelopersIO
こんにちは、CX 事業本部 Delivery 部の若槻です。 今回は、Git で複数のコミットをまとめる方法を確認してみました。 ちなみに Git で行うこの操作のことを「スカッシュ（squash）」するとも言います。squash は「押しつぶす」とか「ぺちゃんこにする」という意味だそうです。 環境 $ vim --version VIM - Vi IMproved 9.0 (2022 Jun 28, compiled Jun 23 2023 22:12:29) macOS version - arm64 Included patches: 1-1544 確認してみた スカッシュしたいコミットが「連続する」場合と「連続していない」場合の 2 通りの方法を確認してみました。 連続するコミットの場合 まずは「連続する」複数のコミットをスカッシュする場合の方法です。 スカッシュ前の状態 次のよう
実務でよく使うgitコマンドライン - Qiita
バージョン管理の個人的な考え方 基本的に歴史は改変したくないタイプ。タイポの修正もわざわざrebaseしないで普通にcommitします。 初回のpushまでは色々試行錯誤もあるので、ローカルのコミットはしばらく放置していますが、目処が立ったらステージングしコミットを付けていきます。 Gitでやらかした時に使える19個の奥義がよく検索ヒットしますが、個人的にはあまり実務で使ってないんです。 そこで、ビギナー〜中級の人向けに役に立つコマンドを以下にまとめます。 という書き出しで当初はまとめていましたが、実は考えが変わってきました。 rebaseからのforced pushはやっても良い派になりました。ただし、forkからのPull Requestもしくはレビュー前のコミットの場合に限ります。自分のリポジトリのブランチなんだからキレイにした後にマージしてもらう方が親切だったり、レビューワーを意識
【Git】後から必要なくなった実装を取り消す方法～revertとreset～ - NRIネットコムBlog
本記事は 【いまさら聞けない○○ウィーク～Git編～】 1日目の記事です。 🍦 告知記事 ▶▶ 本記事 ▶▶ 2日目 💻 はじめに 前提 Gitのステージングとコミット HEAD どんなときに実装を取り消したいか 実装を取り消す方法 revertコマンド resetコマンド 結局どの方法がいいのか 逆に、もう一方のコマンドが活躍する場面はどこか コミットの取り消し機能を有効に活用するために 終わりに はじめに みなさん初めまして。2022年11月にNRIネットコム株式会社に中途入社した上村です。入社してから、Javaを用いたWebアプリケーションの開発に携わっています。開発業務では、ソースコードをGitでバージョン管理しています。Gitは使いこなせると非常に便利ですが、初見では分かりにくい機能も多くあります。今回は、後から必要なくなった実装を取り消す方法についてフォーカスを当てた記事を
君には1時間でGitについて知ってもらう(with VSCode) - Qiita
おことわり この記事はプログラミング＆業務未経験の新入社員に、Gitについて1時間程度で説明した内容をもとに作ったものです。自分がもし誰かにGitについて教えて貰える立場にいたら、最初にこれを教えて貰いたかったという気持ちで作りました。 とりあえず「1人のプロジェクト」で「1時間で」Gitをそこそこ知って使えるようになることを目的としています。実際のチーム開発ができる水準までこの記事だけで達することはできませんが、今後Gitを使う必要がある人にとって学習の足がかりになれば幸いです。 それと、新入社員に教えるという都合上、表現がやや正確でなくざっくりしたところがあるかもしれませんが、質の悪い誤解を招くようなものでなければご容赦下さい。 全体像 まずはGitとは何かをざっくり分かって貰った後で、VSCode上での操作を行って頂きます。 Windowsでの説明を行いますが、Macの方は適宜読み替
Gitのコミットメッセージの書き方（2023年ver.）
本記事のモチベーション 約8年前、Gitを使い始めたときに以下の記事を公開したところ、想像以上の反応をいただきました。 当時はSubversionからGitに移行し、試行錯誤をしている中だったこともあり、多くの反応をいただけたことはモチベーションのひとつでした。 ただ、時が経ち、当然かもしれませんが現在は当時と違う書き方をしており、思想として変わっていない部分はあるものの、今でもときどきLikeをいただく中で、アップデートを全くしないのは誠実じゃないなと感じていました。 というわけで、現在のフォーマットも数年後には変わっている可能性が高いですが、その時々のスナップショットを公開することにも何らか意味があるかなと思い、「今の僕はこうコミットメッセージを書いているよ」というのをまとめました。 Gitを使う環境 開発フローやホスティングサービスごとのUIのdiffによって、最適なフォーマットは変
肥大化したGitリポジトリを別のGitサーバへ移管する｜中央コンピューターサービス株式会社(CCS)
生涯学習事業部、小川です。 部内で個別管理していたGitサーバから、社内共有のGitサーバへ移行した際の手順について記載します。 試行錯誤で建てながら運用していたGit環境だったため、Git内の歴史も整理されておらず肥大化したGitリポジトリがありました。 社内共通管理できる場所ができたということで、移行の準備に取り掛かったのでした。 一番簡単そう、という理由により移行方法１で実験したところ、特に問題なしという結果が出ましたのでいざ実践。 gitコマンドのリモートリポジトリの履歴などをすべてクローンするmirrorオプションを使用し、クローンしたリポジトリを同じくmirrorオプションpushをかける。 $ git clone --mirror <移行元URL> $ cd <ミラーでできた.gitフォルダ> $ git push --mirror <移行先URL> 当然、Gitの歴史が古い
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Gitのブランチ戦略の基本とルールを学んで使いこなそう
Gitコミットメッセージの表記法と7つのベストプラクティス
「git pull」と「git fetch」の違いとは？
Git研修【MIXI 23新卒技術研修】
リモートリポジトリを複数設定にする方法 - Qiita
