この記事を作成したきっかけ... MENTAのあだちんさんに環境構築を見てもらう機会があり、知らないコマンドや手順が多くいくらコードが書けるようになってもグループ開発ではgitが使えないと感じたので備忘録として残します。 プルリクエストとは プルリクエストとは、開発者のローカルリポジトリでの変更を他の開発者に通知する機能です。プルリクエストは次のような機能があります。 ・機能追加や改修など、作業内容をレビュー担当者や 　に通知される。 ・ソースコードの変更箇所をわかりやすく表示 自分-->pull request-->レビュー担当-->Merge-->main 1.mainブランチに移動 ブランチを作る時は基本的にmainブランチからにする $ git checkout main 2.現在のブランチを確認 $ git branch *マークがついているのが参照中のカレントブランチ main * module1 module2 3.現在のブランチを元に新しいブランチを作成 $ git checkout -b module3 $ git branch main module1 module2 module3* 4.ファイルを変更してコミット $ git add file-name $ git commit -m "メッセージ" 5. GitHub上にPush $ git push origin module3 参考記事

この記事を作成したきっかけ... MENTAのあだちんさんに環境構築を見てもらう機会があり、知らないコマンドや手順が多くいくらコードが書けるようになってもグループ開発ではgitが使えないと感じたので備忘録として残します。 プルリクエストとは プルリクエストとは、開発者のローカルリポジトリでの変更を他の開発者に通知する機能です。プルリクエストは次のような機能があります。 ・機能追加や改修など、作業内容をレビュー担当者や 　に通知される。 ・ソースコードの変更箇所をわかりやすく表示 自分-->pull request-->レビュー担当-->Merge-->main 1.mainブランチに移動 ブランチを作る時は基本的にmainブランチからにする $ git checkout main 2.現在のブランチを確認 $ git branch *マークがついているのが参照中のカレントブランチ main * module1 module2 3.現在のブランチを元に新しいブランチを作成 $ git checkout -b module3 $ git branch main module1 module2 module3* 4.ファイルを変更してコミット $ git add file-name $ git commit -m "メッセージ" 5. GitHub上にPush $ git push origin module3 参考記事

git lfs インストール手順 Git LFS の検証をするためにインストールする 手順を残しておく 完全にメモ用 環境 Cloud : Google Cloud Platform (GCP) Service : Google Compute Engine (GCE) OS : CentOS Stream 8 type : e2-standard-2 (2core 8GB) installするもの git-lfs : v2.13.3(2021/08/02 時点最新) depenency : git_v2.27.0 , git-core , git-core-doc , perl-Git , perl-Error , perl-TermReadKey ←インストールされる 手順 dnf update しておく # dnf -y update git-lfs最新版yumrepoを取得 CentOS8のリポジトリのやつはバージョン2.11.0 最新インストールは packagecloud.ioのRPMのinstructionに書かれてるコマンドを実行する # curl -s https://packagecloud.io/install/repositories/github/git-lfs/script.rpm.sh | sudo bash すると、/etc/yum.repos.d/ に yumrepo が追加されて、gpgキーがインストールされる [root@hoge yum.repos.d]# ls | grep git github_git-lfs.repo # cat github_git-lfs.repo [github_git-lfs] name=github_git-lfs baseurl=https://packagecloud.io/github/git-lfs/el/8/$basearch repo_gpgcheck=1 gpgcheck=0 enabled=1 gpgkey=https://packagecloud.io/github/git-lfs/gpgkey sslverify=1 sslcacert=/etc/pki/tls/certs/ca-bundle.crt metadata_expire=300 [github_git-lfs-source] name=github_git-lfs-source baseurl=https://packagecloud.io/github/git-lfs/el/8/SRPMS repo_gpgcheck=1 gpgcheck=0 enabled=1 gpgkey=https://packagecloud.io/github/git-lfs/gpgkey sslverify=1 sslcacert=/etc/pki/tls/certs/ca-bundle.crt metadata_expire=300 この状態でdnf install git-lfsで最新をインストールできる dnf でインストール # dnf install git-lfs github_git-lfs 409 B/s | 833 B 00:02 github_git-lfs-source 405 B/s | 833 B 00:02 Dependencies resolved. ================================================================================================================================================= Package Architecture Version Repository Size ================================================================================================================================================= Installing: git-lfs x86_64 2.13.3-1.el8 github_git-lfs 3.2 M Installing dependencies: git x86_64 2.27.0-1.el8 appstream 164 k git-core x86_64 2.27.0-1.el8 appstream 5.7 M git-core-doc noarch 2.27.0-1.el8 appstream 2.5 M perl-Error noarch 1:0.17025-2.el8 appstream 46 k perl-Git noarch 2.27.0-1.el8 appstream 77 k perl-TermReadKey x86_64 2.37-7.el8 appstream 40 k Transaction Summary ================================================================================================================================================= Install 7 Packages Total download size: 12 M Installed size: 55 M Is this ok [y/N]: y ... Installed: git-2.27.0-1.el8.x86_64 git-core-2.27.0-1.el8.x86_64 git-core-doc-2.27.0-1.el8.noarch git-lfs-2.13.3-1.el8.x86_64 perl-Error-1:0.17025-2.el8.noarch perl-Git-2.27.0-1.el8.noarch perl-TermReadKey-2.37-7.el8.x86_64 Complete! インストール確認 # git lfs --version git-lfs/2.13.3 (GitHub; linux amd64; go 1.16.2; git a5e65851) OK! MEMO gitはすでにv2.31.0が入ってたけど、dnfでインストールしたときにバージョンが下がっちゃうとかは特になかった

【Git】git stashでコンフリクトが起きたときの対処 git stashは現在のブランチで変更をコミットせずに退避・一時保存できるコマンド たまに遭遇するケース 結構前に退避したものをgit stash popやgit stash applyで元に戻そうとした時、色々なコミットを取り込んでしまっていると、場合によっては以下のような感じでコンフリクトが起きることがある # 1 退避 git stash # 2 別の人のコミットなどを取り込んだ後に元に戻そうとする git stash apply stash@{0} # 3 コンフリクトが起きる error: Your local changes to the following files would be overwritten by merge: ~/ファイル名 Please commit your changes or stash them before you merge. Aborting そんな時に使うコマンドがgit stash branch <newbranch>コマンド git stash branch <newbranch>の使い方 これは新しいブランチを作成し、作業スタックに退避した時点のコミットを再現して、スタックにある作業を再適用してくれる つまりstashコマンドを実行した時点のブランチの状態に戻せるようなイメージ # new-branchブランチを作成し、そっちのブランチに適用 git stash branch new_branch stash@{0}

問題 Xserver上でGitを使いたいが、ちょっと、古いので、最新のバージョンを利用したい。 TL;DR OpenSSLまでリビルドする必要があるので、バージョンアップは諦めるかな。。。 同じく、HomeBrew(LinuxBrew)を入れてみたけど、GitとCurlのバージョンが古いのでこちらもインストールにコケたりする。 この辺、Xserverの運営者のギリギリのラインになるのかな？って思いました。 作業内容 こちらの記事を参考にさせていただいて作業を行う。 Xserverへgitの最新版をインストールする こんな感じでgitのバージョンアップをしました。 git cloneをしようと思うと、httpsが使えなくてエラーとなります。 [hirotae@ git-2.32.0]$ ./git --version git version 2.32.0 [hirotae@ git-2.32.0]$ ./git clone https://github.com/surmon-china/vue-quill-editor.git Cloning into 'vue-quill-editor'... fatal: unable to access 'https://github.com/surmon-china/vue-quill-editor.git/': Protocol https not supported or disabled in libcurl libcurlでSSLが使えないのが問題。 curlをリビルドすることになるけど、今度は、OpenSSLがないと言い出す。。。 ./configure --with-openssl --prefix=$HOME/local ・・・ checking for HMAC_Update in -lcrypto... no checking for HMAC_Init_ex in -lcrypto... no checking OpenSSL linking with -ldl... no checking OpenSSL linking with -ldl and -lpthread... no configure: OPT_OPENSSL: yes configure: OPENSSL_ENABLED: configure: error: --with-openssl was given but OpenSSL could not be detected OpenSSLを入れるところになるので、Gitのアップデートは諦めた方がいいかな？

gitとは 分散型のバージョン管理システムのこと。 複数人で共有するリポジトリ（=リモートリポジトリ）・ユーザ1人に作業リポジトリ（ローカルリポジトリ）があり、、普段の作業はユーザそれぞれのローカルリポジトリ上で変更を管理する。 公開可能な状態になれば、リモートリポジトリに対してアップをする。対して、リモートリポジトリから更新が必要になった際には、各ユーザのタイミングでローカルリポジトリへ反映が可能。 ※ソースコードのバージョン管理システムにgitを使用したソフトウェア開発のプラットフォームとして特に有名なのが"GitHub"であり、プライベートリポジトリ（履歴管理を行う場所）を無料で使用可能。 バージョン管理システムがなぜ必要なのか バージョン管理システムがなかった時代は、ファイル名やフォルダ名で差別化を図ったり、ソースコードにコメントで修正内容や日時をメモしていたが、こうしたやり方では特に管理に気を使わなければならないことが多く、問題発生のリスクが非常に高かった（作業者によって手法や表現方法が異なったり、見落としが増えやすかった）。 gitによる問題解決は多く、特に効果的なのは以下の3点。 1.履歴管理 ⇒バグの発生日時、コード編集者の特定、過去のコード内容など 2.リリース管理 ⇒どのバージョンのコードがいつリリースされたかを記録・管理 3.昨日の管理 ⇒該当の機能に関する修正範囲を把握し、機能単位でコードを追うことが可能 Ubuntuでgitをインストールする はじめに UbuntuとはOS（WindowsやMacなどのOSと呼ばれるパソコンの基本ソフトの1つ）としてのLinux（LinuxもOSの1つで、無償で改変可能なオープンソースのOS）の1つ。LinuxをOSとして使うために必要なソフトウェアとLinuxが一緒になったパッケージを"Linuxディストリビューション"といい、その1つでもある。 インストール手順 Windowsならコマンドプロント、MacならTerminalを使用してコードを実行していく。 ・インストール $ sudo apt-get install git ※sudoとは、管理者権限（スーパーユーザ=rootユーザ）で実行を行う宣言のこと。 ・gitの設定 　変更をコミット（=変更対象のファイルをローカルリポジトリに反映させる）する際に表示される自身の名前と、変更を加えた内容に他の人が問い合わせるときに使えるメールアドレスを設定する。 $ git config --global user.name "a bc" $ git config --global user.email "abc@email.com" ・上手く設定されたか確認 $ git config --global --list user.name=a bc use.email=abc@email.com 内容を変更したい場合には、再度コマンドを実行して上書きをする。 ・gitをTerminal（Windowsならコマンドプロンプト）で見るときの出力をカラー表示にする設定 $ git config --glibal color.ui "auto" ・リポジトリの設定 既存の管理したいファイルがあるディレクトリ（作業ツリーとも言い、ファイルなどを格納している場所を指す）又は今からファイルを作成していくディレクトリを新規作成し、そのディレクトリへ移動し、そのディレクトリで実行。 // ディレクトリのある場所まで移動 $ cd ディレクトリ名 // もしくはディレクトリのある階層まで追っていく $ cd /階層1/階層2/階層3/.../ディレクトリ名 // リポジトリの設定の実行 $ git init ".git"というディレクトリが作られ、リポジトリに必要なすべてのファイルが格納され、これで管理準備が完了した。 ・更新内容を登録 登録は2段階で行い、まず更新対象とするファイルを選択し、選択したファイルを更新（コミット）することで登録が完了。 $ git add index.html "."を指定することで、全てのファイルを追加可能。 $ git commit -m "add new file." "-m"オプションを付けると、コミットメッセージを指定してコミットが可能。 コミットすることで、リポジトリに格納される1つ1つの履歴となる。 // 履歴の確認 $ git log ~ ~ ~ add new file. ・更新の追跡 コミットするためには、変更したファイルをインデックス（コミットしたいファイルやファイルの一部を登録する場所）に移動させなければならない。 // コミットするためにインデックスに移動させる $ git add index.html // 再度確認 // 変更されたファイルの一覧を表示 $git status ファイルを更新すると、gitはファイルが変化したことを認識する。 参考サイト Ubuntu インストールしたらやること

これはなに 元々、CircleCI でデプロイした後に、手動でタグを作成して GitHub に push していたのですが、タグ作成部分を GitHub Actions で自動化したので、本記事でまとめておこうと思います。（リリースノートはついで・・） 事前準備 GitHubの個人アクセストークンを作成する（repo権限が必要なので、権限を選択する際にチェックを入れてください） 取得したトークンをCircleCI側に設定する（本記事では、GITHUB_TOKENという名前で設定していることを前提で進めます） git tagについて git tag については、本筋ではないのでさらっと。git tag を使うことによって、特定のコミットに対してタグをつけることができるので、バージョン(v1.0.0のようなもの)を管理したい時に便利です。詳細な使い方については下記を参照ください。 https://git-scm.com/book/ja/v2/Git-%E3%81%AE%E5%9F%BA%E6%9C%AC-%E3%82%BF%E3%82%B0 設定していく！ GitHub Actionsでタグとリリースノートを作成するワークフローを追加 タグを作成できるアクションがないか探していたところ、GitHub Tagというアクションを見つけました。GitHub Tag を使うと、簡単にタグを作成できるようになるので、こちらを使用していきます。この後少し説明しますが、タグの他にリリースノートも自動で作成してくれます。（ありがたい・・） https://github.com/marketplace/actions/github-tag 設定方法 ほとんどサンプル通りですが、下記のように設定しました。 .github/workflows/create_tag.yml jobs: create_tag: runs-on: ubuntu-latest steps: - name: Checkout uses: actions/checkout@v2 - name: Bump version and push tag id: tag_version uses: mathieudutour/github-tag-action@v5 with: github_token: ${{ secrets.GITHUB_TOKEN }} default_bump: "minor" - name: Publish release uses: actions/create-release@v1 env: GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} with: tag_name: ${{ steps.tag_version.outputs.new_tag }} release_name: Release ${{ steps.tag_version.outputs.new_tag }} body: ${{ steps.tag_version.outputs.changelog }} CircleCIでデプロイが終わった後に、GitHub Actionsのワークフローを実行できるようにする CircleCI と GitHub Actions の連携部分です。 GitHub Actions側 まずは、GitHub Actions 側から設定していきます。 repository_dispatch GitHub Actions で外部イベントをトリガーにワークフローを実行するには、repository_dispatch を使用します。GitHubリポジトリのエンドポイントに対して、POSTすることでワークフローを実行することができます。更にワークフロー側、POSTする側でevent_typeを指定することで、特定のワークフローのみ実行することが可能になります。 repository_dispatchの設定をワークフローに追記する 先ほど作成したワークフローを以下のように修正しました。 これにより、create_tagというevent_typeを含むリクエストがあったときのみ、ワークフローを実行できるようになりました。 .github/workflows/create_tag.yml # 追加 name: Create Tag on: repository_dispatch: types: [create_tag] jobs: create_tag: runs-on: ubuntu-latest steps: - name: Checkout uses: actions/checkout@v2 - name: Bump version and push tag id: tag_version uses: mathieudutour/github-tag-action@v5 with: github_token: ${{ secrets.GITHUB_TOKEN }} default_bump: "minor" - name: Publish release uses: actions/create-release@v1 env: GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} with: tag_name: ${{ steps.tag_version.outputs.new_tag }} release_name: Release ${{ steps.tag_version.outputs.new_tag }} body: ${{ steps.tag_version.outputs.changelog }} CircleCI側 次に CircleCI 側の設定です。 GitHub リポジトリのエンドポイントに対して、POSTできるようにする POST する際、気にする必要があるのは、以下の3点です。 1. 事前準備で取得しておいた $GITHUB_TOKEN 2. 対象のリポジトリのURL 3. event_type .circleci/config.ymlに追記 自分は下記のようにデプロイ周りの設定の下に追記しました。 .circleci/config.yml # 既存のデプロイ周りの設定 ... - run: name: Create Tag command: | curl -X POST -H "Authorization: token $GITHUB_TOKEN" -H "Accept: application/vnd.github.everest-preview+json" --data '{"event_type": "create_tag"}' <リポジトリのURL>/dispatches 以上で設定周りは終わりになります。 使い方 次に使い方について説明します。 詳しくは GitHub Tag のドキュメントを見てほしいのですが、ざっくり説明すると、コミットメッセージに特定のプレフィックスをつけておくと、良い感じにバージョンを振ってくれます。 下記は対応しているプレフィックスの一部です。 コミットメッセージに以下のプレフィックスを設定すると、タグのバージョンを良い感じに更新してくれます。（Xの部分がインクリメントされる） BREAKING CHANGE: 〇〇 → X.0.0 feat: 〇〇 → 1.X.0 fix: 〇〇 → 1.0.X また、上記のプレフィックスをつけることで、以下のような簡易的なリリースノートも作成してくれます。（下記はテスト用に作成してみたもの） まとめ 今回は GitHub Actions のワークフローで、タグとリリースノートの作成を行いました。現状、コミットを元にリリースノートを作成する形になっていますが、コミット単位だと細かすぎるので、できればプルリク単位でリリースノートをまとめたいなーという気持ちがあります。もし、プルリク単位でまとめることができたら、別途記事を書こうと思います。もし、良い方法をご存知の方がいたら、コメントいただけると嬉しいです！ 参考 https://git-scm.com/book/ja/v2/Git-%E3%81%AE%E5%9F%BA%E6%9C%AC-%E3%82%BF%E3%82%B0 https://docs.github.com/en/actions/reference/events-that-trigger-workflows https://docs.github.com/ja/github/authenticating-to-github/keeping-your-account-and-data-secure/creating-a-personal-access-token https://circleci.com/docs/ja/2.0/env-vars/#setting-an-environment-variable-in-a-project