現状 wordpressのプラグインで自動更新するもの（wordfence)を git管理下に含めていた。 またwebhookを利用していて本番でもgit管理をしている状態で gitpullをしている中でadd前の編集されたファイルができるので コンフリクトを起こし自動プルが失敗している状態。 add前の編集をなかったことに removeadd.sh $ git checkout . このコマンドでdeletedされたファイルやmodifiedされたファイルが元に戻せます。 Untracked filesが残る git checkout .ではUntracked filesが残っていると思います。 Untracked filesが残っている場合は git cleanもしくはgit rmで一つづつ削除する必要があります。 git cleanを実行する場合は注意が必要です。 必ずパスを指定して削除範囲を最小限に絞りつつ 以下のコマンドで事前確認をしましょう。 cleann.sh $ git clean -n <PATH> 削除されるファイルが確認できたら 以下のコマンドで実行します。 この時、PATH以下のディレクトリに.gitignoreで 指定しているディレクトリ＆ファイルがないようにしましょう。 .gitignoreで管理外にしているディレクトリ、ファイルも git cleanコマンドは削除してしまいます。 cleanf.sh $ git clean -f <PATH>

この記事は岩手大学 Advent Calendar 2021の記事です！ 記事を書こうと思った経緯 僕が大学生のころ、Git を使わずチーム開発を行っていたときがありました。 今となっては Git は当たり前のように使っていますが、当時を振り返って Git のありがたみを再確認しようという記事です。 また、後輩に Git を使って開発したほうが苦労しないよというモチベーションもあります。 当時の運用 僕の大学では、ユーザーごとにディレクトリが切られていて、その中に各学生が好きなデータを読み書きできていました。そして、自分の管理下のディレクトリ内でパーミッションを設定することで他の学生も読み書きできるようになります。 これを使ってアプリケーションのファイルをディレクトリに入れておき、各開発メンバーがローカルにコピー、変更後に上書きで保存するようにしていました。 もちろんいろんな事件が起こるのですが、それを以下にまとめました。 コンフリクトしたらどちらかが消える 複数人で開発しているので、開発している箇所がかぶる場合があります。 それに気がつくことができれば良いのですが、気づくことができないと先に共有ディレクトリに格納しておいた人の変更が上書きされてしまい消えてしまいます。 これはコンフリクトになれてきた中盤でもやってしまいがちで悲しい思いをしたのを覚えています。 最新バージョン行方不明 各開発メンバーは、共有ディレクトリからローカルに落としてきてから開発をするので、バージョンが古い可能性があります。 また、Git のようにどのファイルが最新バージョンと差分があるかもわかりません。なので、一度ファイルを触ってしまい、そのファイルを触ったことを忘れてしまうと関係のない差分まで生まれてしまいます。 そして、気がつかずに共有ディレクトリに格納してしまうため、最新バージョンのファイルが行方不明になってしまうことが多々ありました。 手動マージ 変更を最新バージョンにマージするときも辛いです。 担当したメンバーから何のファイルのどこを触ったのかを聞き、その情報をもとに最新バージョンに手動でマージを行います。 少し前でも話しましたが、開発メンバーがいつのバージョンのファイルを持っているかもわからないため、マージする箇所やそもそもの処理が全く変わっていたなんてこともあります。 最終的には、開発メンバーがつくってくれた変更を参考にしながら、自分で最新バージョンに対して実装を行うことになりました。 Git のありがたみ 上記で話した問題はすべて Git を活用することで解決できます。 ローカルでの main ブランチとの差分はわかるし、変更履歴、変更箇所のマージ、コンフリクトもうまくできます。しかも、なんかがあったとしてもレビューをするようにしておけば、そのタイミングで気がつくことができ、main ブランチに影響を及ぼさずに開発できます。 Git ははじめ難しいかもしれませんが、main ブランチにとりあえず push するだけでも変更履歴を追うことができるので、大きく変わると思います。 さいごに Git は使ったほうがいい！絶対！

Googleマップに統計データを投影してみた 技研商事インターナショナルでWEBアプリ開発を担当しています 今回はプログラミングやAPIを利用せずとも、GISとはどういったものなのか、その一端に触れる方法をご紹介します。 GISというのはGeographic Information Systemの略で、地理情報システムの略となります。 WEBアプリ等の地図上に位置や地理に関する情報を可視化する目的でよく使われるものの１つにGoogleマップがあります。 今回はインターネット上で公開されているオープンデータをダウンロードし、それをGoogleマップ上に重ねて投影するということをやってみたいと思います。 データをダウンロードする 今回利用するデータとして、総務省が公開している政府統計の境界データを利用します。 境界データとは統計値と結合されているGISデータのことです。 まずは総務省のe-statから2015年国勢調査の境界データをダウンロードします。 [境界データダウンロード]を選択し、[小地域] > [国勢調査] > [2015年] > [小地域(JGD2000)] > [世界測地系緯度経度・Shapefile]と進みます。 [13.東京都]を選択し、今回は[13118 荒川区]のShapeファイルをダウンロードします。 データを編集する 次はGoogleマップで読み込みやすいようにダウンロードしたデータを編集します。 今回はオープンソースソフトウェアのQGISを利用しました。[バージョン：3.18.3-Zürich] QGISは空間情報の編集をはじめ、高度な機能を持ったGISソフトです。 ダウンロード・インストール方法については詳しく載せてあるサイトがたくさんあるので、そちらをご参照ください。 ダウンロードした境界データの「h27ka13118.shp」をQGIS上にドラッグします。 メニューの[レイヤ]タブから「編集モード切替」を選択します。 メニューの[レイヤ]タブから[属性テーブルを開く]を選択します。 「KEY_CODE」「MOJI」「SETAI」「X_CODE」「Y_CODE」の5つだけを残して他の属性を削除します。 KEY_CODE：キー MOJI：市区町村名 SETAI：世帯数 X_CODE：経度 Y_CODE：緯度 メニューの[レイヤ]タブから[名前を付けて保存]を選択し、任意の名前をつけて保存します。この時に形式は[KML]を選択して保存してください。 Googleマップに投影する これから用意したデータをGoogleマップに投影します。 まずはGoogleマップを開いてメニューからマイプレイスを選択します。 タブ上にあるマイマップを選択し、下にある「地図を作成」をクリックします。 レイヤのインポートをクリックし、編集したKMLファイルをインポートします。 画像にあるように地図上にダウンロードしたデータが投影されたことが確認できたと思います。次に世帯数ごとに色分けして町名などをラベルとして表示します レイヤ名の右にある縦三点リーダーを選択し、[データビューを開く]を選択します。 MOJIの右にある▽ボタンをクリックし、[タイトル列に設定]を選択。 SETAIの右にある▽ボタンをクリックし、[コピー]を選択、任意の名前をつけて[タイプ]は[数字]を選択します。 インポートしたカラムは文字としてみなされてしまうため、あらためて数字タイプのカラムを用意することで、 グラデーションを利用したマップ表示を行います。 [個別スタイル]を選択し、[データ列別のスタイル]に、3で作成したラベルを選択。 [範囲]にチェックをいれ、他のパラメーターはお好みで選んで大丈夫です。[ラベルを設定]のところには3で作成したラベルを選択します。 グラデーションを変更したり、余分なポリゴンは削除したりといったことも可能です。 これでいつでもGoogleアカウントから「世帯数がグラデーション表示されているGoogleマップ」を開くことができました。 GISアプリにはこういったことがもっと簡単にできたり、多角的な分析機能を備えたものもあり、 それらの使い方のサポートも充実しているものが市場にあふれています。 これらの活躍を礎にGISという言葉がより浸透していくことを楽しみにしています。

git stash applyを誤って、意図していないブランチに実行してしまい、コンフリクトが起きて、「コンフリクト解消しないと先には行かせねぇ...」と迫られ、二進も三進も行かなくなってしまいました。 ググれば秒だろうと思ってやってみたいくつかの対策が、意外にも空振りに終わってちょいと困ってたので、最後にうまくいった方法をメモ。 git reset --hard いつものあの平和な日々が帰ってきた。 一応ドキュメントはこれっぽいです↓ （追記） 優しい弊社の先輩が本記事を見て声をかけてくれました。 git stash applyならstashに変更履歴が残っているので本当に実行したかったブランチでやり直せば事なきを得ますが、git stash popの場合変更履歴はstashから無くなってしまうので、まずいかもとのこと。 この場合は一回コンフリクトをマージしてコミットしてしまう方がいいそうです。そうすれば履歴は残るので、後でgit reflogでgitログを追えば取り返しがつくと。自分はやってないので保証はできませんが！

検索するといっぱい出てくるのですが、そこにdiff-highlightが無いんですよね。結論を言うとHomebrewのインストール先が変更されてたのでパスが変わったようです。 M1MacのHomebewはインストール先が/usr/local/binから/opt/homebrew/binに変わったようです。そういえばインストールした時に~/.zprofileにeval "$(/opt/homebrew/bin/brew shellenv)"を書けって出ましたね。 以前は/usr/local/share/git-core/contrib/diff-highlight/diff-highlightを実行できるようにしてpagerに指定していたのですが/opt/homebrew/share/git-core/contrib/diff-highlight/diff-highlightを指定しないとダメなようです。 パスの通ってるとこにシンボリックリンク貼るパターンが多いですが、たぶんgitでしか使わないのでフルパスで指定しちゃいました。 # ~/.gitconfig [pager] log = /opt/homebrew/share/git-core/contrib/diff-highlight/diff-highlight | less show = /opt/homebrew/share/git-core/contrib/diff-highlight/diff-highlight | less diff = /opt/homebrew/share/git-core/contrib/diff-highlight/diff-highlight | less

はじめに 今回はAzureを利用してCICDを構築しようと思います。 構築するまえにCI/CDについて説明します。 CI/CDとは？ アプリケーションの構築、テスト、および展開の自動化を実施することにより、 開発および運用アクティビティとチームの間のギャップを埋めることです。 CI(continuous integration) 継続的インテグレーションと言う意味です。 CIとは継続的にクオリティコントロールを適用するプロセスを実行することを言います。 最小限の努力で新しいコードを配布することを目指しています。 多数の開発者がバージョン管理ツール(ex. Git, SVNなど)を共有して使用する環境にCIが必要です。 継続的に運用するサービスや開発中のサービスに機能追加するさいにコミットしてレポジトリをアップデートします。 多数の開発者が1つのチームで作業している場合、このレポジトリに多数のコミットが積み重ねられます。 コミットするたびに毎度ビルド・テスト・マージまでするのであれば、かなりの時間が必要となります。 このような状況で、CIは自動化されたビルド・テストで既存のコードと新しいコードとの競合を防ぎます。 CD(continuous delivery) 継続的デリバリーまたは継続的な展開という意味です。 Continuous Deliveryは共有レポジトリで自動的にReleaseすること、 Continuous DeploymentはProductionレベルまで自動的にデプロイすることを意味します。 複数のワークを複数のサーバーに展開する環境にCDが必要です。 手作業で複数のワークを複数のサーバーに展開する際に発生しやすいミスを防ぐことができます。 CI/CDの種類 Jenkins CircleCI TravisCI Github Actions etc 今回、構築するCICDについて Git Azure DevOps Slack 上記のサービスを利用して、CICD環境構築に取り組んでいきます。 この取り組みでは12月末までに全2回のアウトプットを予定しています。 なお、次回アウトプットは12月初旬頃を予定しています。