20210511のGitに関する記事は6件です。

GitHubでのマージの種類

GitHubのマージに関して、簡単にまとめてみました。 Auto Merge このAuto Mergeが最も一般的なマージ方法となります。 これは別々のブランチでそれぞれが開発している時に、別ブランチの変更内容を自分のブランチに取り込むマージとなります。 上の図は、AのコミットからBとB'のコミットに分岐してそれぞれが開発していると想定しています。 ここでmasterブランチの変更内容を取り込む場合、「git merge master」コマンドにて、新しくCコミットが作成されます。 このCコミットは、Bコミットの内容をベースにして、B'コミットの内容を取り込んでいることになります。 特徴として、CコミットはBコミットとB'コミットの2つを親ファイルとして持っていることです。 Fast Foward merge これは先ほどと違って分岐していない時のマージとなります。 元々開発をしていたAコミットに、新しくBコミットをマージして、変更内容が統合される形です。 するとAコミットを指していたmasterブランチはBコミットを指すようになります。 conflict merge conflictは衝突するという意味です。 別々のコミットで、同箇所を変更や追記してマージ場合に、Git側はどっちの方を正と判断すれば良いか分かりません。 このコンフリクトが発生した際は、該当のファイルを開いて正しい記述に修正する必要があります。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

初心者向け GitとGitHubについて②

前回はGitとGitHubの説明、リモートリポジトリの作成まで行いました。 次はローカルリポジトリの作成やコミット、リモートリポジトリへのプッシュなど一通りの流れを説明します。 初心者向け GitとGitHubについて① 初心者向け GitとGitHubについて② 初心者向け GitとGitHubについて③ まずはGitの基本的な用語を押さえておきましょう。 Gitの基本的な用語 コミット(commit) コミットとは、ファイルの追加や変更の履歴をファイルに記録すること。コミットの際にはどのような変更修正なのかをわかりやすくするためのメモを添えます。 プッシュ(push) ファイルの追加や変更をリモートリポジトリに反映するための操作のことです。 アッド(add) コミット前に変更修正したファイルを仮の保管場所に保存することです。コミット前に行います。 ブランチ(branch) ブランチとは変更履歴の流れを保存したコミットの連なりです。ブランチは分岐することができます。分岐したブランチは他のブランチの影響を受けないで、1つのアプリケーションに対して複数のメンバーが同時に修正や機能追加などを行うことができます。 分岐したブランチを大元のブランチにマージしてブランチを一つに戻すことができます。 プルリクエスト(pull request) ブランチでのコミット履歴を残すとともに、各コミットにおける変更修正にコメントをつけることができるGitHubの機能のことです。1つのブランチでの作業について、コードを確認しつつコミュニケーションが取れる掲示板のようなものです。 マージ(merge) マージは統合するという意味です。機能実装のために作成したブランチを、リモートリポジトリ上のmasterブランチに反映する作業のことをいいます。 プル(pull) リモートリポジトリの変更をローカルリポジトリに取り込む操作のことをいいます。 マージした後、リモートリポジトリのmasterブランチはマージ後の情報になっています。しかしローカルリポジトリのmasterブランチはマージ前の情報のままなので次のブランチを作成する前に情報を反映させる必要があります。 クローン(clone) リモートリポジトリを自分のPCにダウンロードすることができます。 リモートリポジトリがあるが、手元にはローカルリポジトリがない状態の場合、cloneすることで作業することができます。同じリモートリポジトリ内で共同作業を行いたい場合は権限を付与してもらう必要があります。 フォーク(fork) 他の人のプロジェクトのリポジトリをコピーして、オリジナルのファイルに対する編集アクセス権がない場合でも、自分の場所に取り入れることによって編集できるようになります。 ローカルリポジトリの作成 ローカルリポジトリを作成していきます。 ローカルリポジトリはGitリポジトリとして初期化することで作成できます。 Gitで管理したいアプリケーションのディレクトリに移動します。 $ git init git initコマンドを入力するることでアプリケーションのディレクトリをリポジトリとして初期化します。 これでローカルリポジトリが作成できました。 ローカルリポジトリの仕組み Gitは3つのデータ領域でファイルの変更履歴を管理しています。 作業ディレクトリ インデックス Gitディレクトリ 作業ディレクトリ ローカル環境で実際に作業するファイルがある領域です。ワークツリーとも言います。 インデックス 作業ディレクトリ上で変更されたファイルのうち、次回のコミット対象になっているファイルを記録しておく領域。ステージングエリアとも言います。 Gitディレクトリ リポジトリの全ての変更履歴を保存している領域です。 ファイルをローカルリポジトリにコミットする 作業ディレクトリからインデックスへ変更修正したファイルをインデックスへ記録させます。 一つのファイル % git add ファイル名 コミットされていない全てのファイルを記録させるには 全てのファイル % git add -all を入力します。 うまくいったかを確認するにはgit statusコマンドを入力します。 確認 % git status 次にリポジトリへコミットします。 リポジトリへコミット % git commit -m "コメント" -mオプションをつけてどのような内容のコミットなのかを記述します。 これでファイルの変更履歴がリポジトリへ保存されてことになります。 git logコマンドで確認することができます。 コミット確認 % git log リモートリポジトリへプッシュする リモートリポジトリへ反映させる前には、リモートリポジトリの情報をローカルリポジトリに追加する必要があります。 ローカルリポジトリとリモートリポジトリを紐づける % git remote add origin リポジトリのURL 作成したリモートリポジトリのURLを貼り付けます。 ローカルリポジトリをプッシュしてリモートリポジトリへ反映させる リモートリポジトリへプッシュする % git push origin master 最初はGitHubのユーザー名とパスワードを尋ねられますので入力してください。 これでGitHubへプッシュすることができました。 コミットしておけば過去の変更履歴を確認できたり、追跡できるので、元に戻すことができるようになります。通常はブランチを切ってそのブランチへプッシュすることが多いと思います。 次回はGitのコマンドやブランチについてまとめていけたらなと思います。 参考サイト 【超入門】初心者のためのGitとGitHubの使い方 GitHub GITチートシート modis GitHubとは?使い方や知っておきたい知識を解説! Gitではじめるバージョン管理 〜ローカルリポジトリでファイルを管理してみよう〜
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

初心者向け GitとGitHubについて①

GitやGitHubについて何となくの理解でやっていたので いい機会だと思い、備忘録としてまとめておきます。 初心者向け GitとGitHubについて① 初心者向け GitとGitHubについて② 初心者向け GitとGitHubについて③ Gitって何なの? Gitは一言で言うと分散型のバージョンの管理システムのことです。 分散型ではないバージョン管理システムには中央集中型のSubversionなどがあるようです。 中央集中型はリポジトリへの接続が必須ですが 分散型のバージョン管理システムは各々のマシン上にリポジトリを作成して開発を行うことができ、現在のチーム開発の主流になっています。 Gitでアプリケーションを管理するとそれぞれの開発段階でアプリケーションの内容をセーブポイントのように記録して、時系列に沿って管理してくれます。このセーブポイントは遡ることができます。 リポジトリとは バージョン管理にとって管理されるファイルと履歴情報を保管する箱のようなものをリポジトリと言います。 リポジトリ下のファイルやディレクトリをバージョン管理の範囲として指定します。 リポジトリにはローカルリポジトリとリモートリポジトリの2種類があります。 ローカルリポジトリ ローカルリポジトリとは自分のPC上(ローカル環境)に置くリポジトリのことです。 作成したリポジトリは自分のPCの中にあるため、ファイルやディレクトリを変更、修正したい際は好きなタイミングでできます。 リモートリポジトリ リモートリポジトリとは、外部サーバ上に置くリポジトリのことです。作成した箱がインターネットの別の場所にも作られる感じです。リモートリポジトリを直接変更修正はせず、ローカルリポジトリの変更修正を同期して、反映させます。 リモートリポジトリは外部のサーバー上にあるので他の人に作成したコードを共有できたり、チーム開発をしやすくさせたりできます。 GitHubって何なの? Git HubはGitの仕組みを利用して、簡単に複数人での開発ができるようにしてくれるWebサービスです。世界中の人々がコードなどを保存、公開しています。ホスティングサービスと呼ばれるものです。ちなみにGitのホスティングサービスはGitHubだけではありません。 Git Hubは基本的に無料で使うことができます。GitHubに作成されたリポジトリは基本的には公開することになりますが、指定したユーザーがアクセスできるプライベートリポジトリにすることも可能です。 Git Hub Gitのインストール Macの場合はGitはすでにインストールされています。最新版にするにはbrewを使ってインストールします。 % brew install git Windowsの場合はインストローラーをダウンロードします。 ダウンロードページ GitHubDesktop GitHubDesktopはGitHubが提供しているデスクトップ用のアプリケーションです。 本来Gitはコンソールで作業しますが、GitHubDesktopはデスクトップ上で簡単にリモートリポジトリの作成やコミット、プルなどが簡単にできるツールです。 GitHubDesktop ferret GitHub Desktop:初心者でも分かる、易しい使い方 これを使うことで簡単にGitHubを扱うことができますが、今回は紹介に止めて GUIしかできないのかとならないように基本のコマンドラインでの操作で行っていきます。 Gitの初期設定 ターミナルで作業していきます。 Gitではソースコードの変更履歴を確認できますが、誰が変更をしたのかを確認するための情報が必要になります。識別するための情報としてユーザー名とメールアドレスを登録します。 ユーザー名 % git config --global user.name ユーザー名 メールアドレス % git config --global user.email Eメールアドレス % git config --list と入力すると登録されている情報が確認できます。 GitHubのアカウント作成 GitHubへアクセスしてアカウントを作成してください。 リモートリポジトリの作成 GitHubでリモートリポジトリを作成します。 左上のCreate Repositoryをクリックしてください。 リポジトリ作成画面に遷移しました。 リポジトリ名を任意のものを入力してください。 リポジトリの種類では公開したい場合はPublicに非公開にしたいばいはPrivateを選択します。 Add a README fileを選択するとREADMEのファイルを作成してくれます。 事前に作ったアプリケーションをGitHubにあげる場合READMEファイルはすでに作成されているかと思いますので ここはスキップして大丈夫です。 入力できたらCreate repositoryをクリックしてください。 リモートリポジトリが作成できました。 次回はローカルリポジトリを作成やGitのコマンドについてなどをまとめていきます。 参考サイト 【超入門】初心者のためのGitとGitHubの使い方 GitHub GITチートシート modis GitHubとは?使い方や知っておきたい知識を解説!
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Gitでローカルをリセットして、リモートに合わせたい時

ローカル環境でコーディングしていて、作業がカオスになる時があると思います。 リモートが合っていて、リモートの状態に戻したいなって時は以下コマンドを叩きましょう。 git fetch origin git reset --hard origin/master
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Subversionを使用し続けているプロジェクトでGitを導入を阻む壁を克服する はじめてのGit

現在Subversionなどの集中管理型のバージョン管理システムを利用している、歴史あるプロジェクトに参画している新人プログラマ及び、その上司に当たる熟練エンジニアに向けて、あなたのプロジェクトでGitをプロジェクトで使えるようになるための、はじめの一歩となる記事にしたいと思います。 はじめに この記事は、モダンな開発者よりも、レガシーなシステムの開発者向けに書きました。 結論から言うと、以下の3つを実現してから、Gitを導入しましょう 1、設計書はGitで管理しようと思わない。設計書の作成・管理方法を見直すこと。 2、ソースコードに品質管理番号等の改版履歴を直書きしないこと。 3、システム更新をリホストだけで乗り切ろうとせず、リライト・リビルドする勇気を持つ。 バージョン管理とは ソースコードをはじめとしたファイルの変更履歴(バージョン)を管理することを「バージョン管理」と呼びます。ファイルの種類は、例えば.java の拡張子がついたテキストのプログラムです。 ファイルの追加や変更の履歴情報を管理することで、過去の変更箇所を確認する、特定時点の内容に戻す、などの「バージョン管理」という作業が可能となります。一人でプログラムを開発している場合であればなくても困らない場合もありますが、通常複数人で構成されたチームで作業するものですし、たくさんの人に使ってもらうためのプログラムであるほど軽微な修正も含めて履歴を追えることはとても重要です。 このバージョン管理という概念が存在しない状況下での開発作業を考えた場合、本当に軽微な、たった1文字・1行変えるだけの修正であっても、突然動かなくなった時に、バグの修正が遅れや影響範囲の特定が難しくなります。チームでの開発する場合も、メンバー間での開発内容を連携することが難しくなります。 このため、ソフトフェアの開発においては、個人的な小規模開発でも、大規模なプログラムを開発するときでも、バージョン管理の理解は必須です。このため、皆さんのプロジェクトでも、すでにGitを使っていたり、そうでなくてもSubversion(あるいはTeam Foundation ServerやAzure DevOps Server、Bitbucketなど)を使ってバージョン管理をしていると思います。 レガシー環境でGitを導入を阻む壁3つ ここで、Subversionを利用しているプロジェクトを考えたとき、Gitにはいくつかの問題が立ちはだかります。 問題1 GitってExcelの設計書管理できるの?? Excelでプログラムの設計書を管理する層にとって、「Gitじゃ使いにくい!」という意見を目にします。初めからモダンな開発に触れている人にとっては理解することができないかもしれませんが、この日本にはExcelを方眼紙にして、それを仕様書にしているプロジェクトはたくさん存在します。 そうすると、こう思うわけです。 Gitで差分を表示してみても、「バイナリファイルなのでバージョン管理ツールで変更箇所を管理できないじゃん」 このような人たちへの処方箋は2パターンあります。 処方箋1:Officeドキュメント管理用ソフトを導入する 1つはGoogle Spread Sheetを用いて設計書をバージョン管理することです。 ただ、それもセキュリティ上できない人たちがいます。 そうはいっても、そういう企業はOffice365のSharePoint(SharePointOnline)でファイルのバージョン管理くらいはできるでしょう。 ただ、これも問題があって自社の社員でないと、アクセス権限が無かったりするわけです。そうすると、困るんですね。 なので、そいういときは、AlfrescoなどのOfficeドキュメントに特化したバージョン管理システムがありますので、あなたの開発サーバーにDockerを入れて、その上でAlfresco Communityエディションのコンテナをダウンロードしてきて動かしてみてください。 処方箋2 Excelの設計書はやめて、astah* professionalを使う きっとそれだけでもプロジェクトの管理精度は向上するでしょう。 ただ、それでも、歴史が長いプロジェクトだと、膨大なExcel文書からはなかなか脱却できないですよね。 対処療法としては、バイナリ系のファイル管理は、集中型のバージョン管理ソフトで管理し続けるのが良いでしょう。差分もWinMerge プラグインなどを使えば Excel の差分表示はできますので。 それでも、肥大化したExcelファイルは、どんなツールも手に負えません。 それは、あなたのプロジェクトが不良資産を抱えている証拠でしょう。 問題2 ソースコードに履歴が書いてあるから、差分がとっても読みにくいんだけど・・・ 改訂履歴のコメントとは・・・ // NN999999 修正|追加|削除 start ... // NN999999 修正|追加|削除 end こういうやつですね。場合によっては、名前や、所属や、日付を入れるかもしれません。 集中管理型のバージョン管理システムを使っているプロジェクトほど、ソースコードにこのようなコメントが入っていることがあります。また、この場合さらに厄介なのは、元々のソース自体をコメントアウトしているわけです。 そうすると、こうなります。 if (a < 10) { b = c + d; } else { b = c - d; } このプログラムに対して、 品質管理番号:NN000001 計算式 b = c + d を b = c * d に変更する修正 を入れる if (a < 10) { //// NN000001 修正 start // b = c + d; // b = c * d; // NN000001 修正 end } else { b = c - d; } そもそも、このような修正方法は、大昔にソース管理ツールなどというものが存在しなかったときの手法ですが、例えSVNを使って、そこにコミットコメント機能があろうとも、その機能を活用せずにこのようなコメントを入れている場合があるわけです。 元々がそのようなプログラム資産ですから、Gitを入れようとすると、まず困るわけですね。 Gitを習うと、必ずコメントを入れて使いますから。 Gitの使い方は、こんな感じです。 リポジトリを新規作成、または既存のリポジトリを初期化します。 git init プッシュ先のリモートリポジトリを指定しておきます。 git remote add origin <URL> ファイルを作成します。 touch hello.java プッシュするためにコミットします。 git add hello.java コミットする際には1行コメントを入れます git commit -m "NN000001 Modify hello.java" git push origin master 実際、差分をみてみると見やすさは一目瞭然です。 Gitでしっかり管理できているファイルは、以下のように表示されます。 GitHubでの差分のUnified表示 Git本来の差分表示 ソースコードに変更履歴を書くと... GitHubでの差分のSplit表示 Git本来の差分表示 ソースコードに変更履歴を書くと... Git(CLI)での表示 以下のコマンドで、Git(CLI)でも差分の履歴が表示できます。 git log -p Git本来の差分表示 ソースコードに変更履歴を書くと... なので、ソースの中にコメントを書く方法は、Gitととても相性が悪いんですね。 処方箋:Gitを使うのであれば、まずはソースにコメントを直書きすることから廃止しましょう。 問題3 うちのプログラムはSJISで書くことになっているのだけど・・・ モダンな開発者には理解できないかもしれませんが、プログラムのソースの文字コードがSJISで作られているプログラムというものが数多く存在します。 なぜなら、古いプロジェクトほど、移行元となる膨大な稼働資産に引きずられます。 なので、移行前のプログラムがシフトJIS(SJIS)文字コード環境で稼働している場合、必然的に今でもSJISで動いているわけです。 これも、Gitと相性が悪い。コンソールがUTF-8なので毎回文字化けして読めないということになってしまいます。 レガシーシステムのマイグレーション方法には、簡単な順にリホスト・リライト・リビルドとなります。業務ロジックが変わらなければ、20年くらいはリホストで乗り切れるのかもしれませんが、限界を感じます。 Gitを、上記の問題を抱えた既存プロジェクトに対して導入しても、Gitらしく使えるようにするのには大変です。 処方箋:そろそろ、リライト・リビルドする時期に来ているのかもしれませんね
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

実践的な、はじめてのGit

現在Subversionなどの集中管理型のバージョン管理システムを利用している、歴史あるプロジェクトに参画している新人プログラマ及び、その上司に当たる熟練エンジニアに向けて、あなたのプロジェクトでGitをプロジェクトで使えるようになるための、はじめの一歩となる記事にしたいと思います。 はじめに この記事は、モダンな開発者よりも、レガシーなシステムの開発者向けに書きました。 結論から言うと、以下の3つを実現してから、Gitを導入しましょう 1、設計書はGitで管理しようと思わない。設計書の作成・管理方法を見直すこと。 2、ソースコードに品質管理番号等の改版履歴を直書きしないこと。 3、システム更新をリホストだけで乗り切ろうとせず、リライト・リビルドする勇気を持つ。 バージョン管理とは ソースコードをはじめとしたファイルの変更履歴(バージョン)を管理することを「バージョン管理」と呼びます。ファイルの種類は、例えば.java の拡張子がついたテキストのプログラムです。 ファイルの追加や変更の履歴情報を管理することで、過去の変更箇所を確認する、特定時点の内容に戻す、などの「バージョン管理」という作業が可能となります。一人でプログラムを開発している場合であればなくても困らない場合もありますが、通常複数人で構成されたチームで作業するものですし、たくさんの人に使ってもらうためのプログラムであるほど軽微な修正も含めて履歴を追えることはとても重要です。 このバージョン管理という概念が存在しない状況下での開発作業を考えた場合、本当に軽微な、たった1文字・1行変えるだけの修正であっても、突然動かなくなった時に、バグの修正が遅れや影響範囲の特定が難しくなります。チームでの開発する場合も、メンバー間での開発内容を連携することが難しくなります。 このため、ソフトフェアの開発においては、個人的な小規模開発でも、大規模なプログラムを開発するときでも、バージョン管理の理解は必須です。このため、皆さんのプロジェクトでも、すでにGitを使っていたり、そうでなくてもSubversion(あるいはTeam Foundation ServerやAzure DevOps Server、Bitbucketなど)を使ってバージョン管理をしていると思います。 レガシー環境でGitを導入を阻む壁3つ ここで、Subversionを利用しているプロジェクトを考えたとき、Gitにはいくつかの問題が立ちはだかります。 問題1 GitってExcelの設計書管理できるの?? Excelでプログラムの設計書を管理する層にとって、「Gitじゃ使いにくい!」という意見を目にします。初めからモダンな開発に触れている人にとっては理解することができないかもしれませんが、この日本にはExcelを方眼紙にして、それを仕様書にしているプロジェクトはたくさん存在します。 そうすると、こう思うわけです。 Gitで差分を表示してみても、「バイナリファイルなのでバージョン管理ツールで変更箇所を管理できないじゃん」 このような人たちへの処方箋は2パターンあります。 処方箋1:Officeドキュメント管理用ソフトを導入する 1つはGoogle Spread Sheetを用いて設計書をバージョン管理することです。 ただ、それもセキュリティ上できない人たちがいます。 そうはいっても、そういう企業はOffice365のSharePoint(SharePointOnline)でファイルのバージョン管理くらいはできるでしょう。 ただ、これも問題があって自社の社員でないと、アクセス権限が無かったりするわけです。そうすると、困るんですね。 なので、そいういときは、AlfrescoなどのOfficeドキュメントに特化したバージョン管理システムがありますので、あなたの開発サーバーにDockerを入れて、その上でAlfresco Communityエディションのコンテナをダウンロードしてきて動かしてみてください。 処方箋2 Excelの設計書はやめて、astah* professionalを使う きっとそれだけでもプロジェクトの管理精度は向上するでしょう。 ただ、それでも、歴史が長いプロジェクトだと、膨大なExcel文書からはなかなか脱却できないですよね。 対処療法としては、バイナリ系のファイル管理は、集中型のバージョン管理ソフトで管理し続けるのが良いでしょう。差分もWinMerge プラグインなどを使えば Excel の差分表示はできますので。 それでも、肥大化したExcelファイルは、どんなツールも手に負えません。 それは、あなたのプロジェクトが不良資産を抱えている証拠でしょう。 問題2 ソースコードに履歴が書いてあるから、差分がとっても読みにくいんだけど・・・ 改訂履歴のコメントとは・・・ // NN999999 修正|追加|削除 start ... // NN999999 修正|追加|削除 end こういうやつですね。場合によっては、名前や、所属や、日付を入れるかもしれません。 集中管理型のバージョン管理システムを使っているプロジェクトほど、ソースコードにこのようなコメントが入っていることがあります。また、この場合さらに厄介なのは、元々のソース自体をコメントアウトしているわけです。 そうすると、こうなります。 if (a < 10) { b = c + d; } else { b = c - d; } このプログラムに対して、 品質管理番号:NN000001 計算式 b = c + d を b = c * d に変更する修正 を入れる if (a < 10) { //// NN000001 修正 start // b = c + d; // b = c * d; // NN000001 修正 end } else { b = c - d; } そもそも、このような修正方法は、大昔にソース管理ツールなどというものが存在しなかったときの手法ですが、例えSVNを使って、そこにコミットコメント機能があろうとも、その機能を活用せずにこのようなコメントを入れている場合があるわけです。 元々がそのようなプログラム資産ですから、Gitを入れようとすると、まず困るわけですね。 Gitを習うと、必ずコメントを入れて使いますから。 Gitの使い方は、こんな感じです。 リポジトリを新規作成、または既存のリポジトリを初期化します。 git init プッシュ先のリモートリポジトリを指定しておきます。 git remote add origin <URL> ファイルを作成します。 touch hello.java プッシュするためにコミットします。 git add hello.java コミットする際には1行コメントを入れます git commit -m "PROJ-123 Create hello.java" git push origin master 実際、差分をみてみると見やすさは一目瞭然です。 Gitでしっかり管理できているファイルは、以下のように表示されます。 差分のUnified表示 Git本来の差分表示 ソースコードに変更履歴を書くと... 差分のSplit表示 Git本来の差分表示 ソースコードに変更履歴を書くと... なので、ソースの中にコメントを書く方法は、Gitととても相性が悪いんですね。 処方箋:Gitを使うのであれば、まずはソースにコメントを直書きすることから廃止しましょう。 問題3 うちのプログラムはSJISで書くことになっているのだけど・・・ モダンな開発者には理解できないかもしれませんが、プログラムのソースの文字コードがSJISで作られているプログラムというものが数多く存在します。 なぜなら、古いプロジェクトほど、移行元となる膨大な稼働資産に引きずられます。 なので、移行前のプログラムがシフトJIS(SJIS)文字コード環境で稼働している場合、必然的に今でもSJISで動いているわけです。 これも、Gitと相性が悪い。コンソールがUTF-8なので毎回文字化けして読めないということになってしまいます。 レガシーシステムのマイグレーション方法には、簡単な順にリホスト・リライト・リビルドとなります。業務ロジックが変わらなければ、20年くらいはリホストで乗り切れるのかもしれませんが、限界を感じます。 Gitを、上記の問題を抱えた既存プロジェクトに対して導入しても、Gitらしく使えるようにするのには大変です。 処方箋:そろそろ、リライト・リビルドする時期に来ているのかもしれませんね
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む