- 投稿日:2022-02-28T23:43:23+09:00
Windows10でGitHubを始める~④リモートリポジトリの作成(GitHub)
個人学習メモ。 前回の記事⇒Windows10でGitHubを始める~③GitHubでのメールアドレス設定とGitクライアントでのユーザ名・メールアドレス設定 Windows10でGitHubを始める~③'おまけユーザ名・メールアドレス設定について詳細 1.GitHub上にリモートリポジトリを作成する 右上の+から「New Repository」、もしくは左メニューの「New」をclick。 Create a new repository 画面が開く。 Repository template:No templateのままでよい Owener:<自身のアカウントユーザ名>のままでよい Repository name:自由に入力(画像の例ではqiita-testとしている) Description:リポジトリの利用用途がわかる説明を入れておくとよい。空欄のままでもよい。(画像の例ではCreate remote repository test.としている) 公開範囲をPrivateにしておく。(リポジトリを全世界に公開したい場合はPublicにする) 今回はその他のチェックはしないで「Create repository」をclickする。 以下のような画面が表示され、「qiita-test」という名前のリモートリポジトリが作成された。 次の記事 Windows10でGitHubを始める~⑤Githubにプッシュする 参考 GitHub無料プランでもリポジトリが非公開にできるようになったのは最近ぽい
- 投稿日:2022-02-28T17:36:03+09:00
未経験エンジニアが1年半で使ったgitコマンド一覧
私は誰? ・大学時代は非情報系の理系 ・新卒で営業職3年 ・1年半前に未経験からエンジニア転職 ・サーバーサイドの案件が多め 自分と同じように、未経験からエンジニアを目指している方に向けて 「最低限これだけは知っておいたら実務を乗り切れるよ!」 ということを伝えるための記事です。 対象の読者 未経験からエンジニアを目指している方 エンジニアになりたてホヤホヤの方 gitにいまいち自信のない方 本記事で得られるもの 未経験から実務に入った時に、何とか乗り切れるだけのgitコマンド 実務に入るまでにどれくらいのgitを知っておくべきかの目安 よく使うgitコマンドが並んでいるので、この記事からコピペできる 本記事は、「gitの概念を理解する記事」ではなく、「初心者向けのgitのチートシート」ですので悪しからず。 そもそもgitとは? Gitは、プログラムのソースコードなどの変更履歴を記録・追跡するための分散型バージョン管理システムである。 (引用:wikipedia) です。 チームで開発する時には必須と言っても過言ではありません。 実務に携わるまでは全然要らないのに、実務に入ったらいきなり要るやつです。 ちなみに 「git hub」というのは、gitを利用した「サービス」の1つです。 「git」が抽象的な仕組みの名前で、「git hub」が具体的なサービスの名前になります。 絶対使うgitコマンド 最初に手元にとってくる 実行例 $ git clone <URL> リモートの特定のブランチを手元にとってくる 実行例 $ git fetch origin <branch名> $ git checkout <branch名> ブランチの切り替え 実行例 $ git checkout <branch名> ブランチの新規作成+切り替え 実行例 $ git checkout -b <branch名> # ブランチの新規作成だけしたい時 $ git branch <branch名> 現在の変更を全てコミットする 実行例 $ git add . (一部のファイルのみの時は git add <file名> とする) $ git commit -m "コミットメッセージ" ブランチをリモートにプッシュする 実行例 $ git push origin <branch名> 別ブランチのコミットをコピーする 実行例 $ git cherry-pick <コミットID> # cherry-pickしたもののconflictして、やっぱ辞めたいとき $ git cherry-pick --abort 使えたら便利なgitコマンド コミットログを確認する 実行例 $ git log 直前のコミットを上書きする(commitしたもののtypoに気付いた時など) 実行例 $ git commit --amend コミットをまとめる コミットの粒度をどうするかはプロジェクトによってですが、細かくしすぎたコミットをまとめる方法。 実行例 # 直前2つのコミットをまとめる $ git rebase -i HEAD^^ # 直前4つのコミットをまとめる $ git rebase -i HEAD~4 下記のようなやつが出てくるので、単にまとめたいだけであれば、pick→squashと書き換える。 pick 23e47bc5 修正 pick feabc394 新機能実装 コミット間の差分を確認する 実行例 # 現在との差 $ git diff <コミットID> # 任意の2つのコミットの差 $ git diff <コミットID①> <コミットID②> タグを打つ 切り戻しをするとき用などに、タグ(目印)を打っておく。 実行例 $ git tag <tag名> # リモートへのプッシュ $ git push origin <tag名> コミットをなかったことにする 実行例 # 直前のコミットをなかったことにする(変更をステージングにしたところに戻る) $ git reset --soft HEAD^ # 直前のコミットの変更をまるごと消し去る $ git reset --hard HEAD^ 修正を一旦置いときたい 一旦置いとくのが長くなりそうな時は、一度commitしてしまって、後にreset --softして修正を続ける方が好き。 実行例 $ git stash # 直前にstashしたものを元に戻す $ git stash apply stash@{0} リモートブランチを強制的に上書きする 恥ずかしいミスを覆い隠す裏技 ※大事なbranchでやると大事故の危険があります。(※各自の自己責任でお願いします) 実行例 $ git push -f origin <branch名> 後書き 当記事では、実務未経験の方に「これくらい使えたら何とかなるという目安」を提供するために、 「gitの仕組み」や、「それぞれのコマンドの説明」は、ほとんどすっ飛ばしました。 個人的には、gitの勉強はそれほど優先度高くなく、 最低限のポイントだけつかんで、あとは実務を通して慣れていけばいいと思います。 本記事が、少しでも未経験からエンジニアを目指す方の一助となれば幸いです。 最後に少しだけ宣伝を、、 弊社は未経験者でもやる気と能力さえあれば、グングン成長できる環境です! 興味ある人はこちらより。
- 投稿日:2022-02-28T14:07:22+09:00
Power Appsをバージョン管理(Azure DevOpsのgitで)[2]
はじめに Power Apps で、gitリポジトリと連携する話の2回目です。 git用のボタンが増えているので、このボタンを押したらどうなるかやってみます。 増えたgit関連ボタンを押してみる 変更前 変更後。 FirstScreenを複製しました。 このあと、冒頭に話題にした回転のボタンをクリック。 ※ボタンラベルは「変更をコミットして、gitの更新を確認する」という名前 クリックしてみると、画面上の変化はありませんでした。 gitリポジトリのほうを見てみると、1バージョン更新がされていて、更新時のコメントは「Commit」でした。 これだと、確かにバージョン更新はされたのですが、何を更新されたかがわかりません。 メニューからコメント付きで保存する 代わりに、メニューから保存するときにコメント付きで保存ができるのでそちらをやってみます。 先ほど複製したScreenの名前を変更します メニューからコメント付きで保存します。 gitリポジトリのほうを見てみると、保存時のコメントが表示されました。保存時はこちらのほうが、過去の履歴を追うのに有効そうです。 次回について 今度は、gitにコミットされた内容を見ていくことにします。
- 投稿日:2022-02-28T10:47:22+09:00
GutHubにプログラムをあげてみました。
GutHub URL GutHubにプログラムをあげてみました。 GitHub Extension for Visual Studioを使いました。 GutHubに投稿される範囲はVisual Studioの新しいプロジェクトの作成で作成されるファイル内のすべてが対象です。 表示メニューの横に Gitメニューが増えている。 Gitメニュー内のGitリポジトリ作成で新しくGitHubに投稿できる。 更新はGitメニューのコミットまたは一時退避を開き、 コミットした後プルをすることにより、更新されます。 C# TODOlist 作成途中 記事更新2022/02/28 ToDoリスト 納品日と200文字のテキストを入力できる。 oracleデータベースを使用。 C+言語 Phone_book 一時作成完了 記事更新2022/02/28 電話帳 名前と電話番号を登録できる。 C+言語 edit_a_picture 作成途中 記事更新2022/02/28 画像編集ソフト サイズ変更 文字、線、多角形を描画可能
- 投稿日:2022-02-28T10:03:58+09:00
git コマンドの動作イメージ
はじめに 本記事は Gitを使ったことがない 使ったことがあるけどいまいちよくわかってない 今更質問するのは恥ずかしい という方向けに、業務で使ったことがあるGitコマンドを利用シーンごとに説明してみようというものです。 コマンドだけではイメージがわかないので、できるだけ図解していきたいと思います。 想定シーン 開発の開始から終了までの1サイクルの中で、一番使用頻度の高いコマンドを紹介していきます。 開発スタート ソースをローカルに持ってこよう(git clone) 新たにブランチを作ろう(git checkout) ブランチをリモートに反映させよう(git 開発途中 編集中のブランチのソースを最新化しよう 作業完了 編集したソースをリモートにプッシュしよう 何らかのトラブル(コンフリクト起こしちゃった、古い資産をマージしちゃった)については 事例があればそれをもとに書いていきたいところですが、 今のところは使う頻度が高いものから書いていこうと思います。 シーン別 git コマンド ■開発スタート 1. ソースをローカルに持ってこよう 開発が始まったら最初にやることは、 GitHub上にあるソースの保存場所から、 自分のPCに開発資産(ここでは主にソースコード)を持ってくることです。 GitHub上の保存場所を「リモートリポジトリ」 自マシン上に出来上がる保存場所を「ローカルリポジトリ」といいます。 コマンド git cloneを使って指定のURLから開発資産を持ってきます。 資産を配置するディレクトリ内で実行します。 git clone https://github.com/XXXXXX/YYYY_PROJECT.git <メモ> XXXXX、YYYY_PROJECT の部分は対象のリポジトリによって変わるので確認してから実行しましょう。 イメージ リモートリポジトリと同じ内容がローカルリポジトリに出来上がります。 2. 新たにブランチを作ろう ローカルリポジトリが準備できたら、開発用にブランチを作成します。 バグフィックス、プログラム改修など、ソースコードに手を入れる場合は、 原則としてブランチを作成すると覚えましょう。 リリース用の資産が入っているブランチを直接修正したりしないのが基本です。 コマンド git checkoutを使ってローカルにブランチを作成します。 資産を配置するディレクトリ内で実行します。 git checkout -b feature/fix-some-functions feature/fix-some-functions という名前のブランチを作成する例となります。 -b オプションを指定することで作成と同時に切り替えを実行します。 イメージ ローカルリポジトリに新しいブランチが作成されます。 この時点ではリモートリポジトリには反映されません。 3. ブランチをリモートに反映させよう ローカルに新たなブランチを作成したら、リモートにアップロードします。 これでチーム内の他のメンバーも新しいブランチで開発ができるようになります。 ローカルでのソースコードの編集が終わった後でも構いませんが、 その場合は、このコマンドを実行するまで他の開発者から作業中のブランチ が見えない状態であることに注意しましょう。 コマンド git pushを使ってリモートリポジトリにアップロードします。 資産を配置するディレクトリ内で実行します。 git push -u origin feature/fix-some-functions <メモ> feature/fix-some-functions というブランチをpushする例となります。 ブランチを新規作成して最初のpushでは-uを付けます。 originはリモートリポジトリの場所を表す別名です。 イメージ ローカルリポジトリにしかなかったブランチ(図内の赤破線) がリモートリポジトリに反映されます。 ■開発途中 1. ローカルのソースを最新にしよう チーム開発をしている場合、同じブランチで複数のメンバーがソースコードを編集します。 他メンバーが編集したソースコードは、そのままではローカル作業ブランチには反映されません。 リモートブランチから最新のソースコードを持ってきて、ローカル作業ブランチに反映してやる必要があります。 コマンド git pullを使ってローカル作業ブランチの資産を最新にします。 資産を配置するディレクトリ内で実行します。 git pull <メモ> 対象のブランチの資産のあるディレクトリで実行します。 ローカル作業ブランチの資産が、 リモートブランチの最新の資産で上書きされるので注意が必要です。 編集中の資産とリモートの資産とでコンフリクトがあるとエラーが出ます。 イメージ リモートリポジトリにある資産がローカルリポジトリに反映されます。 ■作業完了 1. 編集したソースをリモートにプッシュしよう ローカルで編集・コミットしたソースをリモートブランチに反映させる作業です。 コマンド git pushを使ってリモートブランチ及びリモート追跡ブランチに資産を反映させます。 資産を配置するディレクトリ内で実行します。 git push origin feature/fix-some-functions <メモ> feature/fix-some-functions というブランチをpushする例となります。 originはリモートリポジトリの場所を表す別名です。 イメージ ローカルリポジトリで編集・コミットしたブランチの状態がリモートリポジトリとリモート追跡リポジトリに反映されます。
- 投稿日:2022-02-28T01:55:53+09:00
Windows10でGitHubを始める~③'おまけユーザ名・メールアドレス設定について詳細
個人学習メモ。 前回の記事⇒Windows10でGitHubを始める~③GitHubでのメールアドレス設定とGitクライアントでのユーザ名・メールアドレス設定 1.GitHubのEmailsで設定するメールアドレスについて 1-1.[Settings]-[Emails]の「Primary」メールアドレス GitHubにログインし、アイコンをクリックし[Settings]-[Emails]から確認できる「Primary」メールアドレスは、 GitHubからの通知に使うメールアドレス である。 ここのメールアドレスは「Add email address」で複数追加することができ、主たる GitHubからの通知に使うメールアドレス は「Primary email address」で「Primary」として設定しておく必要がある。 こうすると、GitHubからの通知やパスワード再設定時のメールアドレスはPrimaryとした方のメールアドレスに通知されるようになる。 1-2.GitHub Web UIからのコミット操作に紐づくメールアドレス GitHubはWeb UIからもコミット操作が可能だが、その際使われるメールアドレスは基本的に「Primary email address」に設定したメールアドレスが使われる。 「Keep my email addresses private」のチェックボックスをオンにすると、どのリポジトリでWeb UIからコミットしても、紐づくメールアドレスはGitHub提供の非公開用のダミーメールアドレス***@users.noreply.github.com となる。 1-3.所属する組織(Organization)ごとに通知メールアドレス先を変えたい場合 自身が所属する組織(Organization)のリポジトリからの通知を別のメールアドレスで受信したい場合は、 別のメールアドレスを[Settings]-[Emails]の「Add email address」で追加しておく [Settings]-[Notifications]の「Custom routing」で、自身が所属する組織(Organization)リポジトリからの通知を受信したいメールアドレスを設定 することで、通知受信メールアドレスを分けることができる。 2.手元のWindows10端末にインストールしたGitクライアントで設定するメールアドレスについて 前回の記事「Windows10でGitHubを始める~③GitHubでのメールアドレス設定とGitクライアントでのユーザ名・メールアドレス設定」手順2-1で設定したGitクライアント側からコマンドで設定したメールアドレスについて。 2-1.「git config --global user.email ~」で設定したメールアドレスについて 前回の記事「Windows10でGitHubを始める~③GitHubでのメールアドレス設定とGitクライアントでのユーザ名・メールアドレス設定」手順2-1では以下のコマンドでメールアドレスを設定した。 git config --global user.email "GitHub提供の非公開用メールアドレス" このコマンドで設定される内容は、ホームディレクトリに生成されている「.gitconfig」というファイル内に追記される。 Visual Studio Codeで開くと↓ この「.gitconfig」は Gitの設定 であり、git configコマンドで設定したり内容を参照することができる。これは「gitconfig」とか「gitのconfig」とか呼ばれていて、他にも種類があり、3段階に分かれている。 gitconfigの種類 システム全体に作用するsystemのconfig ユーザ全体に作用するglobalのconfig 対象リポジトリのみに作用するlocalのconfig 設定はsystem⇒global⇒localの順に読み込まれ、最後に読み込まれた設定で上書きされるため、よりスコープの狭い設定が有効になる。前回の記事「Windows10でGitHubを始める~③GitHubでのメールアドレス設定とGitクライアントでのユーザ名・メールアドレス設定」手順2-1で設定したのはこの中のglobalにあたる。 システムデフォルトであるsystemを変更するケースはあまりないらしい。基本的にメインで使用するメールアドレスはglobalで設定し、リポジトリごとに細かくコミットアドレスを制御する必要がある場合はリポジトリごとにlocalを設定すればよい。 ※詳細は「git config 設定」などでググるとたくさん情報がある。参考にも貼っておく。 2-2.GitHub提供の非公開用ダミーメールアドレスを使用した場合 GitHubはCommitter(コミットした人)の判別に、Gitクライアントのgit configで設定されたメールアドレスを使用する。git configで設定されたメールアドレスがGitHub上に登録されているメールアドレスでないと、GitHub上のログに本人のアバターが出ない。 しかし、git configで設定した自分のメールアドレスはGitHubにpushしたときコミット履歴に残る。これは吸い出すことも可能で、吸い出す用のツールもあるらしい。 メールアドレスを設定しないとコミット履歴に自分のアバターもメールアドレスも残らず、誰が変更したのかわからない。 そこでGitHub提供の非公開用ダミーメールアドレスを使用すれば、自分のメールアドレスを公開することなく、コミット履歴に自分のアバターが表示され誰が変更したのか分かるようにできる。 ※ユーザ名・メールアドレスをGitHubアカウント作成時に登録もの以外でコミットしてGitHub上のリモートリポジトリにpushしたときどう表示されるのかはまだ試していない。 次の記事 Windows10でGitHubを始める~④リモートリポジトリの作成(GitHub) 参考
- 投稿日:2022-02-28T00:42:13+09:00
【Heroku】アプリを削除したい!(Heroku CLI)
要約 以下のコマンドでHeroku上のアプリを消せる。 $ heroku apps:destroy -a アプリの名前 概要 Heroku CLIを使ってサッとアプリを削除したいときの備忘録として。 環境 OS: Ubuntu 20.04(WSL2を使用) $ cat /etc/lsb-release DISTRIB_ID=Ubuntu DISTRIB_RELEASE=20.04 DISTRIB_CODENAME=focal DISTRIB_DESCRIPTION="Ubuntu 20.04.4 LTS" Heroku CLIのバージョン $ heroku --version heroku/7.59.2 linux-x64 node-v12.21.0 ※Heroku CLIのインストールは公式ドキュメントを参照 コマンド 以下のコマンドでHeroku上のアプリを消せる。また、git remoteの一覧からもリモートリポジトリが削除される。 $ heroku apps:destroy -a アプリの名前 例:「my-app」という名前のアプリを消したいとき $ heroku apps:destroy -a my-app ▸ WARNING: This will delete ⬢ my-app including all add-ons. ▸ To proceed, type my-app or re-run this command with --confirm my-app > my-app # アプリ名を入力 Destroying ⬢ my-app (including all add-ons)... done ちなみに作成済みのアプリの一覧は以下で取得できる。 $ heroku apps === hogehoge@gmail.com Apps my-app 参考 Heroku CLIコマンド
- 投稿日:2022-02-28T00:17:14+09:00
Gitのローカルブランチの消去
毎回ググってる気がするのでメモ # マージ済みの時 $ git branch --delete ブランチ名 $ git branch -d ブランチ名 # マージ済みでなくても消去できる $ git branch -D ブランチ名