20211125のGitに関する記事は5件です。

VSCode。。。エディタやめるってよ。

VS CODEってなんですか? 超高機能なテキストエディタ です。最近では統合開発環境(IDE)だと言っても良いぐらいに高機能になりました。 IDEってなんですか? ソフトウエア開発のためにプログラムエディタ、コンパイラ呼び出し、テストの実行、デバッグ支援などの機能を統合したソフトウェアのことです。だいたいこんな機能を持っています NO. 機能 概要 1 任意コンパイル ユーザーの求めに応じて、プログラムをコンパイルする。 2 オートコンパイル プログラムの変更の度にコンパルして、問題などがあればエディタ上にわかりやすく表示する。 3 補完 入力された情報から、取り得る選択肢を並べる。開発者はその中から適切なものを選択する。 4 フォーマッタ インデントなどを適切に整形してくれる 5 シンタックスハイライト プログラムに色を付けて構文をわかりやすくする 5 依存解決 そのプログラムが利用する外部のライブラリを読み込む 6 多言語対応 自然言語じゃないよ。Javaとかcとかたくさんのプログラミング言語に対応するってことだよ。 だいたい1〜4までできたらIDEって言ってもいいかな。と個人的に思う。 IDEはなんでいるんですか? これは一言でいえば、 使わないとプログラムという作業が煩雑になりすぎるから プログラムはただのテキストファイルです。テキストエディタとコンパイラもしくはパーサがあれば、 プログラムを作ることは可能。 事実、僕は、19の時分からJavaを書き続けているが、最初は、Emacsで書いて、javacコマンドでコンパイルしたものです。 こういった開発スタイルは早晩生産性の観点で、行き詰まります。代表的には以下のような場合です。 プログラムの文法上の間違えの発見が遅れる。 パッケージ含んだクラス名を一字一句間違いなく覚えることも、入力することも現実には難しい。 プログラム整形を人手で行う。そのため、品質が安定しない上に時間がかかる リファクタリングが難しい。 この問題を解決してくれるのがIDEです。つまり オートコンパイルでで常に文法敵には正しいプログラムを書ける。 プログラム補完で、入力すべきコードが補完されるため「名称の一部」を覚えておけばよくなった。 プログラム整形は、IDEにおまかせ♪ リファクタリングが簡単なので、より良いプログラムに変更を続けられる。 こんな感じになります。 VS CodeってIDE? これはちょっと判断が難しいところですね。デフォルトの状態ではVSCodeはIDEではありません。超便利な、テキストエディタ です。ただし、VS Codeは拡張機能が豊富なため、組み合わせれば超強力な 統合開発環境(IDE) へと変貌します。 たとえば、私は Pythonを書いたり Javaをデバックしたり Ansible Playbook で構築作業を自動化したり Plant UML だってかけちゃう。 そう、VS Codeならね♪ つまり、基本的にはただのエディタに過ぎないVS Codeは拡張機能を組み合わせることで、単なるエディタであることをやめ、統合開発環境へと変貌するのです。 Java を書いてみる 導入拡張機能 わたしの導入している Java関係の拡張機能はこんな感じです。殆どがExtensions for Javaを導入すると一緒にはいります。 ソースコード整形 まずは整形です。 このように、1行になってしまっている、Javaのソースコードも。。。 ドキュメントの整形を実行すれば... このようにあっという間に整形されます。 コード補完 たとえば、このようにString#formatを呼び出したい場合も、途中まで入力すれば補完候補が表示され、開発者はそれを選択するだけです。 ビルド Java 拡張機能は、Mavenでのビルドをサポートしているため、このように。Maven packageを実行することが可能です。 はい。ビルド完了です。 デバッグ さて、私が大好きなIDEな機能の一つにデバッグ機能があります。どんな言語の開発でもデバッガを探しておくことから私は始めます。これなしでは問題追跡がやりにくいからです。 このように、ブレークポイントを設定してから。 Debugを押すと、プログラムの動作を開始しますが。ブレークポイントに処理がささると。。。 処理を一時停止します。 この後、1行1行個別に実行する(ステップオーバー)も可能ですし、呼び出されるメソッドの中に入ってい実行を継続する(ステップイン)も可能です。このとき、変数内のデータを参照することが可能です。 そのほかのIDE No. IDE 特徴 1 Eclipse IBMの製品をOSSに寄贈。長い間Javaのデファクトスタンダード的なIDEとして君臨。独自のビルドツールのほかMaven等にも対応 2 NetBeans もともとはOpenJDKとともに公開されていた、デフォルトIDE。いまはApacheプロジェクトに寄贈されている。ネイティブでMaven対応していたり、Junitのテストケースのガワを勝手にはいてくれたり。僕の大好きなIDE 3 InteliJ なぜか、みんな大好きInteliJ ビルドはgradleを採用。逆にGradleを各場合は最強 4 Android Studio Googleが開発したIDE。だった。いまはInteliJ派生。Androidのプロジェクトを作成するのに便利 5 Pycharm これもInteliJ派生 6 Visual Studio Code 言わずと知れたVS Code。 まとめ IDEがないと、生産効率ぐんと下がるよ VSCodeも拡張機能をいれれば、IDEとして使えるよ Javaの拡張機能を例に、使い方をみてみたよ
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

fatal: remote origin already exists 新たにBitbucket上にリポジトリを作成してpushしようとしたらできなかった話。

Railsチュートリアル3章の序盤で起きた問題 Bitbucket上にリポジトリを作成してpushしようとしたら ❶ $ git remote add origin git@bitbucket.org:ユーザー名/sample_app.git fatal: remote origin already exists ❷ $ git push -u origin --all Please make sure you have the correct access rights and the repository exists. エラーをコピーしてないので前後にもう少し文があったような気もしますが、こんな感じのエラーが出てきました。 入れ物作れないしpush出来ないし! もうホント手順通りに進めてもうまくいかないんだから困っちゃうよなあw さてさてブツクサ言っても問題は解決しません。 ❶の方に関しては、もうあるみたいなので再度やる必要はないのですが、私はなんでもやってみたいので、一旦 origin を消して入れ直しました。 消してみる $ git remote rm origin これで再度 $ git remote add origin git@bitbucket.org:ユーザー名/sample_app.git はい解決できました。 逆にもう一度入力してみると… $ git remote add origin git@bitbucket.org:ユーザー名/sample_app.git fatal: remote origin already exists. と言うことだったんですねえ あるよー!!だってよ こちらが参考にさせていただいた記事です。 ❷に関しては 調べていくと、細かくは違えど、一貫して書いてあったのは、SSH 接続に問題が起こっている模様。 なので、SSHの公開鍵をもう一度作り、再度$ git push -u origin --allを入力することで解決しました。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

新たにBitbucket上にリポジトリを作成してpushしようとしたらできなかった話。

Railsチュートリアル3章の序盤で起きた問題 Bitbucket上にリポジトリを作成してpushしようとしたら ❶ $ git remote add origin git@bitbucket.org:ユーザー名/sample_app.git fatal: remote origin already exists ❷ $ git push -u origin --all Please make sure you have the correct access rights and the repository exists. エラーをコピーしてないので前後にもう少し文があったような気もしますが、こんな感じのエラーが出てきました。 入れ物作れないしpush出来ないし! もうホント手順通りに進めてもうまくいかないんだから困っちゃうよなあw さてさてブツクサ言っても問題は解決しません。 ❶の方に関しては、もうあるみたいなので再度やる必要はないのですが、私はなんでもやってみたいので、一旦 origin を消して入れ直しました。 消してみる $ git remote rm origin これで再度 $ git remote add origin git@bitbucket.org:ユーザー名/sample_app.git はい解決できました。 逆にもう一度入力してみると… $ git remote add origin git@bitbucket.org:ユーザー名/sample_app.git fatal: remote origin already exists. と言うことだったんですねえ あるよー!!だってよ こちらが参考にさせていただいた記事です。 ❷に関しては 調べていくと、細かくは違えど、一貫して書いてあったのは、SSH 接続に問題が起こっている模様。 なので、SSHの公開鍵をも一度作り、再度$ git push -u origin --allを入力することで解決しました。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

gitignore 個人メモ

目的 すでにgit管理されているファイルをgitignoreファイルに登録したが反映されなかったので自分用のメモとして残す。 概要 gitignoreファイルと同じ階層にあるs3ディレクトリ配下をすべてgit管理から外したい。 方法 .gitignoreファイルへの記載 .gitignoreファイルに下記のように記載を行った。 /s3/ キャッシュの削除 下記コマンドを実行してgit管理から除外したファイルキャッシュを削除した。 $ git rm -r --cached s3/* 後は差分が出ているファイルをaddしてcommitしたら作業完了 参考文献 https://qiita.com/fuwamaki/items/3ed021163e50beab7154
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

WindowsでGitの認証情報をcredential.namespaceと資格情報で管理し認可重複に耐える

TL;DR Windowsで複数のGit Reposを扱うときはsshでトンネルたくさん掘るんじゃなくてnamespace(credential.namespace)使ってHTTPSでやったほうがいいよ。 はじめに お仕事でAアカウントのAWS CodeCommit、BアカウントのAWS CodeCommit、Azure DevOps、Github…といった具合にGit Reposが(悲しいことに、認証認可単位ごと)どんどこ増えて行くわけですが、みなさんも経験お有りじゃないでしょうか。 メンバーが「HTTPS接続のトークンだとWindowsだとリポジトリが上書きになっちゃうのでsshキー登録してます」「諦めてこのプロジェクトではMac使ってます」みたいなことになってきたので、改めてcredential helperとnamespaceについて整理することにしました。 この記事は何をしようとしているのか 異なる認可体系のGit Reposの認証認可状態について、PATをWindowsの資格情報マネージャを使って管理し、再認証不要にします。 この方法では、個別に設定するnamespaceでreposと認可情報を識別するので、reposのURLが被ってるのにアカウントが違うので覚えさせようとすると認証・認可状態が重複する、というようなケースに対応できるはず。(CodeCommitのとあるreposはIAM Aで、別のreposはIAM Bでのみアクセスできる、みたいな場合を想定。) 準備 まず、Gitクライアントが古い場合はアップデートしちゃいましょう。一昔まえまではWindowsのGit認可管理はwincredっていうcredential helperでやってたのですが、これがちょい前くらいにmanager(Git Credential Manager for Windows)に取って代わられており、さらに最近managerはmanager-core(Git Credential Manager またはGCM Core)に取って代わられています。 手っ取り早いのは、最新のGit for Windowsを用意し、インストーラーを注意深く見守ることです。 準備ができていると、credential.helperにmanager-coreが設定されているはず。 PS E:\hoge> git config --get credential.helper manager-core 手元の環境ではすでにここで書いたことを設定済なので、初めてやる方は以下のコマンドの結果が変わってくるかもしれませんが、credential.<scheme>://<fqdn>.usehttppath trueになってるところが使いたいreposのURLに合ってないと駄目かもしれません。 PS E:\hoge> git config --get-regexp credential.+ credential.helper manager-core credential.https://dev.azure.com.usehttppath true 設定例 Azure DevOps (dev.azure.comドメインでアクセス時) VSTS時代からのユーザはtest.visualstudio.comみたいになってるかもしれないのでその場合はアドレス直してください。 reposのURLは以下と仮定します。 https://{user-name}@dev.azure.com/{org-name}/{prj-name}/_git/{repos-name} 汎用資格情報の登録 以下のように登録します。以下アドレス項目の、ado-test-gitが今回指定するgitのcredential namespaceです。 ユーザ名のPersonalAccessTokenはAzure DevOpsの場合決め打ちです。 ※間違えてWindows資格情報を登録しようとするとうまくいかないので注意。 インターネットまたはネットワークのアドレス: ado-test-git:https://{user-name}@dev.azure.com/{org-name} ユーザ名: PersonalAccessToken パスワード: Azure DevOpsで払い出したPAT Clone Cloneするときにnamespaceを指定します。 git clone https://{user-name}@dev.azure.com/{org-name}/{prj-name}/_git/{repos-name} ` -c credential.namespace=ado-test-git # -c credential.namespaceのところ、"="でつなぎ忘れないように。ぼくは10回はやった。 認証を問われることなくcloneできてればOK。 確認 cmdkeyで資格情報の登録状況確認します。 PS E:\hoge> cmdkey /list:ado* 結果(なんか一個増えてるな。。) ado* のために現在保存されている資格情報: ターゲット: ado-test-git:https://dev.azure.com/XXXX 種類: 汎用 ユーザー: PersonalAccessToken ローカル コンピューターの常設 ターゲット: ado-test-git:https://XXXX@dev.azure.com/XXXX 種類: 汎用 ユーザー: PersonalAccessToken ついでに、ローカルにできたreposの状態を確認します。 PS E:\hoge> Set-Location .\{prj-name}\ PS E:\hoge\{prj-name}> git config --local --get-regex cred* 結果(localのgit configのnamespaceが指定した内容になっている) credential.namespace ado-test-git Github 要望などが高まったら書く AWS CodeCommit 気持ちが高ぶったら書く
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む