- 投稿日:2020-11-21T22:05:33+09:00
docker-composeとGitを利用したWebシステム開発の効率化
はじめに
【コンテナとGitを利用したWebシステム開発の効率化】というタイトルで記事を投稿したが、その後
docker-compose
も試しに使ってみたので、その時の内容をメモとして残しておく。実行環境
【Docker導入環境】
・Ubuntu 20.04 LTS(GCP上)
・docker 19.03.13
・docker-compose 1.25.0【コンテナ環境】
・Image Ubuntu:20.04
・Apache 2.4.41 ※バージョン指定をしていないのでインストール時の最新試してみる事
以下の流れで、
docker-compose
を使ってWebサービスの立ち上げ・停止などを試してみる。1.環境準備
2.Github上にリポジトリを作成
3.ホスト側で用意するファイル
4.docker-compose
を使った操作確認1.環境の準備
GCP上にVMインスタンスを作成
※イメージはUbuntu20.4 LTSパッケージ管理ツールのアップデート
$ sudo apt updategitのインストール
$ sudo apt install -y gitdockerのインストール
※【Dockerコンテナ内のUbuntuではsystemctlは使えない】の手順1を参考に。docker-composeのインストール
$ sudo apt install -y docker-compose問題なくインストールできているか確認
$ ddocker-compose --version docker-compose version 1.25.0, build unknown2.Github上にリポジトリを作成
Github上で以下を実施する。
■Public用のリポジトリを作成
※手順3では、Github上のPublicリポジトリからクローンすることを前提としている。■作成したリポジトリ内の直下に『App』フォルダを作成
■『App』フォルダ内にindex.htmlを作成
※中身は適当に記載■開発用のブランチを切る
※手順3ではブランチ名はmain(本番用)
とdev(開発用)
を前提としている。3.ホスト側で用意するファイル
以下のディレクトリ構成でファイルを用意
./docker-compose.yml
./Dockerfile
./site_config/
- demo_site.conf
./mount/
- main/
- Github上のmain
ブランチをクローンする- dev/
- Github上のdev
ブランチをクローンするディレクトリ作成################################################# # サイトコンフィグの設定ファイルを入れるディレクトリ # ################################################# $ sudo mkdir ./site_config ################################ # マウント用のディレクトリを作成 # ################################ $ sudo mkdir ./mount # ソースコード格納場所 $ sudo mkdir ./mount/main $ sudo mkdir ./mount/devGithub上のソースをクローン$ sudo git clone --depth 1 -b main https://github.com/Smiler5617/test_websys.git ./mount/main $ sudo git clone --depth 1 -b dev https://github.com/Smiler5617/test_websys.git ./mount/dev以下の様に、各ファイルを作成
demo_site.conf<VirtualHost *:80> ServerAdmin webmaster@localhost DocumentRoot /var/www/html/App/ ErrorLog ${APACHE_LOG_DIR}/error.log CustomLog ${APACHE_LOG_DIR}/access.log combined </VirtualHost>Dockerfile# ベースイメージの取得 FROM ubuntu:20.04 # 必要パッケージのインストール RUN apt update RUN apt install -y tzdata RUN apt install -y apache2 # サイト設定の読み込み COPY ./site_config/demo_site.conf /etc/apache2/sites-available/ RUN a2dissite 000-default RUN a2ensite demo_site # マウント用のディレクトリを作成 RUN mkdir /var/www/html/App # ポート開放 EXPOSE 80 CMD ["apachectl", "-D", "FOREGROUND"]docker-compose.ymlversion: '3.7' services: web_main: build: context: . dockerfile: Dockerfile volumes: - ./mount/main/App:/var/www/html/App ports: - 8080:80 web_dev: build: context: . dockerfile: Dockerfile volumes: - ./mount/dev/App:/var/www/html/App ports: - 8081:804.
docker-compose
を使った操作確認全サービスの起動
$ docker-compose up
※初回起動時は、ビルドやイメージのダウンロードが自動で開始される。
以下の環境にアクセスできれば、ひとまず起動はできている。
http://[VMの外部IP(グローバルIPアドレス)]:8080/
http://[VMの外部IP(グローバルIPアドレス)]:8081/
起動停止
Ctrl + C
バックグラウンドで実行
$ docker-compose start Starting web_main ... done Starting web_dev ... done※
$ docker-compose up -d
でもOKだが、ログの確認したいならstart
がよい。停止
$ docker-compose stop Stopping 【Googleアカウント名】_web_dev_1 ... Stopping 【Googleアカウント名】_web_main_1 ...
指定してサービスの起動や停止も可能
$ docker-compose start web_main Starting web_main ... done $ docker-compose stop web_main Stopping 【Googleアカウント名】_web_main_1 ...サービスの停止&削除
$ docker-compose down
※サービスが削除されると、
start
やrestart
で起動できなくなる。
- 投稿日:2020-11-21T21:47:46+09:00
メモ git管理しているプロジェクトに別のリポジトリをgit cloneしたいとき
リモートから新たに何かクローンしたい
既にgit initされているフォルダに別のモジュールをリモートからクローンしてくる場合を考える
$ git clone https://github.com/usr/somethingこれでクローンされた。
statusを見てみる$ git status Untracked files: (use "git add <file>..." to include in what will be committed) something/git addすると警告が出る
$ git add . warning: adding embedded git repository: something hint: You've added another git repository inside your current repository. hint: Clones of the outer repository will not contain the contents of hint: the embedded repository and will not know how to obtain it. hint: If you meant to add a submodule, use: hint: hint: git submodule add <url> something hint: hint: If you added this path by mistake, you can remove it from the hint: index with: hint: hint: git rm --cached something hint: hint: See "git help submodule" for more information.入っている様に見えるが、中身は空!
$ git status On branch master Your branch is up to date with 'origin/master'. Changes to be committed: (use "git restore --staged <file>..." to unstage) new file: something #この中身が空!別リポジトリからクローンしてきた.gitを消して下記コマンドで解決
$ rm -rf something/.git $ git rm -f --cached something $ git add . $ git status On branch master Your branch is up to date with 'origin/master'. Changes to be committed: (use "git restore --staged <file>..." to unstage) new file: something/.env.example new file: something/.gitignore new file: something/LICENSE new file: something/Makefile new file: something/README.md new file: something/db/log/.gitignore new file: something/db/my.cnf new file: something/docker-compose.yml new file: something/php/Dockerfile new file: something/php/php.ini new file: something/web/default.conf
- 投稿日:2020-11-21T19:45:22+09:00
【Git】複数人開発で最低限できてほしいこと
概要
あなたがある開発チームの一員でとある仕事を任されたという状況を想定してGitの使い方を学んでいきます。
Gitのインストールはこちらを参考に
1. 仕事を任される
あなたは今とある仕事を任されました。
2. コードをクローンする
GitHubのページに飛びます。指定されたリポジトリのページに行き、右上の方にある緑の「Code」と書いてあるボタンをクリックします。HttpsタブをクリックしURLをコピーします。
ターミナルを開き、コードをおきたいディレクトリまで移動します。そこで次のコマンドを実行します。git clone [コピーしたURL]
コードが置かれたディレクトリが作成されます。
3. コードを編集する
任された部分のコードを編集します。しかしそのまえに、Gitにはブランチという重要な概念が存在します。とりあえず下記のコマンドを実行してください。
git branch -a
これは現在自分が作業しているブランチを確認するコマンドです。出力は、
* main remote/origin/main remote/origin/...
のようになっているはずです。赤文字がリモートブランチ、白文字がローカルブランチです。複数人で開発する時は基本的にmainブランチで作業はしない方がいいです。なぜなら、mainブランチにあるコードは本番用のコードであることが多いからです。作業をする時は必ず自身のブランチを作成して作業を進めるようにしましょう。そうすればmainブランチに変更を加えないまま作業を進めることができます。
それでは自分の作業用のブランチを作成しましょう。git branch feature/[どんな作業かわかる名前]
ブランチを切ったら自身が今いるブランチを確認しましょう。
git branch -a
* feature/[どんな作業かわかる名前] main remote/origin/main
となっていれば成功です。もしまだ自分がmainブランチにいるのであれば、
git checkout feature/[どんな作業かわかる名前]
としてブランチを移動しましょう。※もしそれでもできなければ
git stash
としてもう一度上のコマンドを実行してみてください。4. 変更内容をpushする
コードをが完成したらその変更内容をpushしましょう。
まずは変更内容を確認します。
git status
変更されたファイルパスの一覧が表示されます。
変更内容を確認したら、変更内容をaddします。
git add --all
もう一度
git status
を実行して緑色になっているものがaddされたファイルたちです。
変更内容をcommitしましょう。変更内容がわかるようにコメントも残しておきましょう。git commit -m "〇〇を編集しました"
成功したらpushします。
git push -u origin feature/[どんな作業かわかる名前]
成功したら完了です。リモートにfeature/[どんな作業かわかる名前]という名前のブランチが作成されコードがそこに置かれます。GitHubのページに飛んで実際に確認できます。
注意すべきは、自分の変更はまだmainブランチに反映されてないということです。5. プルリクエストを作成する
プルリクエストとはコードの管理者にコードをmainブランチに反映(merge:マージ)して欲しいと依頼するためのものです。実際に作成しましょう。
GitHubに飛びます。Pull requestsタブを選択し、New pull requestボタンをクリックします。compairの部分で自分のブランチを選択します。あとは手順に従って適当にコメントを残しながら作成ボタンをクリックして完了です。
6. 担当の人から修正を依頼される
プルリクエストのなかでコードを変更して欲しいとお願いされる場合があります。その場合は手順3に戻って再度pushしプルリクエストを作成しましょう。
7. 完了
全てよしと判断されたら担当者にmergeしてもらって完了です。お疲れ様でした。
- 投稿日:2020-11-21T19:45:22+09:00
【Git】複数人開発で仕事を任され、終えるまで
概要
あなたがある開発チームの一員でとある仕事を任されたという状況を想定してGitの使い方を学んでいきます。
Gitのインストールはこちらを参考に
1. 仕事を任される
あなたは今とある仕事を任されました。
2. コードをクローンする
GitHubのページに飛びます。指定されたリポジトリのページに行き、右上の方にある緑の「Code」と書いてあるボタンをクリックします。HttpsタブをクリックしURLをコピーします。
ターミナルを開き、コードをおきたいディレクトリまで移動します。そこで次のコマンドを実行します。git clone [コピーしたURL]
コードが置かれたディレクトリが作成されます。
3. コードを編集する
任された部分のコードを編集します。しかしそのまえに、Gitにはブランチという重要な概念が存在します。とりあえず下記のコマンドを実行してください。
git branch -a
これは現在自分が作業しているブランチを確認するコマンドです。出力は、
* main remote/origin/main remote/origin/...
のようになっているはずです。赤文字がリモートブランチ、白文字がローカルブランチです。複数人で開発する時は基本的にmainブランチで作業はしない方がいいです。なぜなら、mainブランチにあるコードは本番用のコードであることが多いからです。作業をする時は必ず自身のブランチを作成して作業を進めるようにしましょう。そうすればmainブランチに変更を加えないまま作業を進めることができます。
それでは自分の作業用のブランチを作成しましょう。git branch feature/[どんな作業かわかる名前]
ブランチを切ったら自身が今いるブランチを確認しましょう。
git branch -a
* feature/[どんな作業かわかる名前] main remote/origin/main
となっていれば成功です。もしまだ自分がmainブランチにいるのであれば、
git checkout feature/[どんな作業かわかる名前]
としてブランチを移動しましょう。※もしそれでもできなければ
git stash
としてもう一度上のコマンドを実行してみてください。これでいよいよコーディング作業か開始できます。
担当者の指示通りのコードを作成しましょう。4. 変更内容をpushする
コードが完成したらその変更内容をpushしましょう。
まずは変更内容を確認します。
git status
変更されたファイルパスの一覧が表示されます。
変更内容を確認したら、変更内容をaddします。
git add --all
もう一度
git status
を実行して緑色になっているものがaddされたファイルたちです。
変更内容をcommitしましょう。変更内容がわかるようにコメントも残しておきましょう。git commit -m "〇〇を編集しました"
成功したらpushします。
git push -u origin feature/[どんな作業かわかる名前]
成功したら完了です。リモートにfeature/[どんな作業かわかる名前]という名前のブランチが作成されコードがそこに置かれます。GitHubのページに飛んで実際に確認できます。
注意すべきは、自分の変更はまだmainブランチに反映されてないということです。5. プルリクエストを作成する
プルリクエストとはコードの管理者にコードをmainブランチに反映(merge:マージ)して欲しいと依頼するためのものです。実際に作成しましょう。
GitHubに飛びます。Pull requestsタブを選択し、New pull requestボタンをクリックします。compairの部分で自分のブランチを選択します。あとは手順に従って適当にコメントを残しながら作成ボタンをクリックして完了です。
6. 担当の人から修正を依頼される
プルリクエストのなかでコードを再度変更して欲しいとお願いされる場合があります。その場合は手順3に戻って再度pushしプルリクエストを作成しましょう。
7. 完了
全てよしと判断されたら担当者にmergeしてもらって完了です。お疲れ様でした。
- 投稿日:2020-11-21T19:41:10+09:00
GitHub で2つのアカウントのSSH鍵とレポジトリを使い分ける方法
GitHub で2つのアカウントを使い分けているエンジニアは多いことでしょう。例えば、組織用アカウントと個人用アカウントを持っているエンジニアは、それぞれのアカウントで異なるリポジトリーに対して作業しているはずです。
1つのアカウントで作業している時は、ユーザー名やSSH鍵の使い分けを意識することはありません。しかし、2つになると、コミットログに書き込まれるユーザー名やメールアドレスを使い分けたり、
git pull/push
時に使うSSH鍵を使い分ける必要が出てきます。以下に、自動で設定を使い分ける方法を記します。
やりたいこと
- それぞれの作業フォルダーでコミット時、対応するユーザー名とメールアドレスを使う
git pull/push
などリモート操作をする時、アカウントに対応するSSH鍵を自動で使い分ける
- リポジトリAでは、ユーザーAのSSH鍵を使う
- リポジトリBでは、ユーザーBのSSH鍵を使う
今回は以下のように、2つのアカウントを使い分ける想定で進めます。
仕事用 個人用 アカウント名 john bob リポジトリ john/project-john.git bob/project-bob.git 設定方法
アカウントに対応する公開鍵を作成する
まずはそれぞれのアカウントに対応するSSH鍵ペアが必要です。
ssh-keygen
で作成してください。今回は鍵ファイルにid_rsa_<アカウント名>
という名前を付けます。cd ~/.ssh ssh-keygen -t rsa -f id_rsa_john (パスフレーズを入力、またはそのまま Enter 2回) ssh-keygen -t rsa -f id_rsa_bob (パスフレーズを入力、またはそのまま Enter 2回)これで秘密鍵と公開鍵のペアが作成されます。
公開鍵を GitHub にセットする
ユーザーA,B それぞれのアカウントで GitHub にログインし、 "Settings > SSH and GPG Keys" 画面から、対応する公開鍵 (
id_rsa_<アカウント名>.pub
) を登録してください。公開鍵の登録方法: Adding a new SSH key to your GitHub account - GitHub Docs
ローカル git config を設定する
それぞれの作業フォルダーで使用するユーザー名とメールアドレスを設定します。これらはコミットメッセージに記録されます。
cd ~/project-john git config --local user.name "John" git config --local user.email "john@example.com" cd ~/project-bob git config --local user.name "Bob" git config --local user.email "bob@example.com"フォルダー内の
.git/config
を直接編集しても OK です。~/.ssh/config を設定
続いて、リポジトリ毎にSSH鍵を使い分けるようにするため、
~/.ssh/config
ファイルを編集しします。以下のように
Host
行とIdentityFile
行を書き分けてください。# 会社用: SSH鍵 id_rsa_john を使う Host github.com.john Hostname github.com User git IdentityFile ~/.ssh/id_rsa_john # 個人用: SSH鍵 id_rsa_bob を使う Host github.com.bob HostName github.com User git IdentityFile ~/.ssh/id_rsa_bobリモート URL に、上で設定したホスト名を指定する
最後に再び git config を設定します。以下のように、リモートURLに
git@<ホスト>:<リポジトリURL>
を指定してください。cd ~/project-john git remote set-url origin git@github.com.john:john/project-john.git cd ~/project-bob git remote set-url origin git@github.com.bob:bob/project-bob.gitこれで、
~/.ssh/config
で設定した Host に対応するSSHキーが使われるようになります。設定確認&動作確認
cd ~/project-john git pull # => id_rsa_john が使われる cd ~/project-bob git pull # => id_rsa_bob が使われる参考
- 投稿日:2020-11-21T18:28:43+09:00
GitHubでIssueを活用してポートフォリオを管理する方法
まずはUdemyでGitとGitHubの基礎を学ぼう!
・GitおよびGitHubを一度も触ったことがない
・一応使ってはいるが、コマンドは意味も分からずコピペ
・何となく苦手意識があるこのような方は、GitHubでポートフォリオを管理する前に、Udemyで以下の講座を受講してみてください。1に関しては無料、2もセール時に買えば1500円程度で購入できます。
1. Git:はじめてのGitとGitHub
2. Git: もう怖くないGit!チーム開発で必要なGitを完全マスター非常に丁寧でわかりやすい説明で、初心者でも内容がスッと入ってきます。
「Git, GitHubって何?」「なんか難しそう、、」「今日もコピペでpushするか、、」
こんな状態から、
「Git, GitHubって楽しい!」「全然難しくないじゃん!」「今やっている操作の意味がわかる!」
こんな状態になります(実体験)。上記の講座で基礎学習を終えた方、または既に別で終えている方は、以下を見ていただきたいです。
この記事の対象者
「GitHubでポートフォリオを管理したいけど、情報がいろいろあってわからん!簡潔に手順を教えてくれ!」という方。
この記事を書いた理由
上記Udemy講座にて一通りGitおよびGitHubの学習を終え「いよいよGitHubでのポートフォリオ管理だ」と意気込み、具体的な手順を色々調査していましたが、体系的かつシンプルにまとめられた「とりあえずこれをやれ」という記事がなかったため、書いてみることにしました。
今回はGitHubのIssueを使ってポートフォリオ管理に必要なコマンドを簡潔にまとめました。
環境構築や初期設定は省き、実際に管理したいファイルに対して行う操作のみを示しています。GitHubでポートフォリオを管理する手順
ここから、僕が実際に行っているポートフォリオの管理手順を記述します。
一応、それぞれの操作で何を行っているかがわかるように、簡単に説明を入れています。
出てくるコマンドはググればすぐに出てくるので、詳しい説明は省きます。初回のみの操作
1. GitHubの「New」より、ポートフォリオを管理するリモートリポジトリを新規作成
2. GitHubで管理したいフォルダにREADME.mdファイルを作成し、リポジトリの説明を記述
3. ターミナルにてcdコマンドでGitHubで管理をしたいディレクトリに移動
4. リモートリポジトリの「…or create a new repository on the command line」に記述してある通りにターミナルでコマンドを入力
git init
(git管理下に置く)
git add README.md
(先ほど作成したREADME.mdファイルをステージング)
git commit -m "first commit"
(コミットメッセージをつけてコミット)
git branch -M main
(ローカルブランチの名前をmainに変更)
git remote add origin リモートリポジトリのURL.git
(「origin」という名前でリモートリポジトリを登録、今後は「origin」を使ってプッシュしたりプルしたりすることができる)
git push -u origin main
(mainブランチをpush、-uをつけておくと、次回以降git push
だけでプッシュすることができる)
5. ブラウザを更新し、pushされていることを確認以降開発をする際の操作
1. GitHubの該当のリポジトリで「Issues」→「New Issue」より、Issueを作成(Issue...Todoのようなもの)
2. タイトルのところにタスクを入力((例)ログイン機能の実装、モーダルの実装)、詳細があれば本文に記述し「Submit new issue」(タイトルの末尾に「#番号」がつく、今回は例として#1とする)
3. ターミナルで開発ディレクトリに移動し、git checkout -b develop#1
(mainブランチから開発用ブランチを切って移動する、末尾に先ほど作成したIssueの#番号をつけることで、Issueと対応したブランチを判別しやすくなる)
4. Issueで作成したタスクに沿って開発を行う
5. タスクが完了したらgit add .
(変更したすべてのファイルをステージング)
6.git commit -m "#1 コミットメッセージ"
(ステージングした変更をコミット、コミットメッセージに#1 と入れることでIssueと紐づく)
7.git push origin develop#1
(origin(リモートリポジトリ)にdevelop#1(ローカルブランチ)をプッシュ)
8. GitHubで「Compare & pull request」が表示されているのでクリック
9. タイトルを入力し、末尾にclose #1とつける(close #1をつけることで、プルリクエストが閉じられると自動的に#1に対応したissueがcloseされる(後から手動で閉じることもできる)、詳細があれば本文に記述する)
10. 「base: main ← compare: develop#1」であることを確認して、「Create pull request」→「Merge pull request」→「Confirm merge」(develop#1ブランチをmainブランチにマージ)
11. GitHub上で「Delete branch」(用済みのdevelop#1ブランチを削除)
12.git checkout main
(ローカルでmainブランチに移動)
13.git pull origin main
(リモートのmainブランチをローカルのmainブランチに統合、先ほどpushした内容がローカルに反映される)
14.git branch -d develop#1
(ローカルの用済みのdevelop#1ブランチを削除)手順14の後、新たに開発をしたい場合は手順1に戻り新たにIssueを立て、同様に進めます。
また、上の手順では省いていますが、適宜git status
やgit branch
で確認作業を行うと、思わぬミスが減ると思います。
最初のうちは手順通り忠実にやるべきだと思いますが、たまに不測の事態が起きることがあります。その際に闇雲にコマンドを打ってしまうと何をやっているのかが分からなくなってしまうので、起きている事態を冷静に把握し、必要であれば調べるなり、Udemyで該当箇所を復習するなりすれば解決できると思います。GitHubでポートフォリオ管理をして感じたメリット
・Issueを立てることによって、一つのタスクに集中できる
他のタスクに目移りすることがなくなり、作業効率が爆上がりします。
・チーム開発を意識した管理ができる
Issueやプルリクエスト(本来はレビューが入りますが)など、チーム開発で使われる管理方法に慣れることができます。
・GitHubでContributionsが蓄積され、錯覚資産になる(かもしれない)
いわゆる「草をはやす」というやつです。初めて聞いたという方は「GitHub 草」でググってみてください。最後に
実は初めに紹介したUdemyの講座では、Issueは出てこなかったり、pullよりもmergeからのfetchを推奨したりしています(きちんと理解していればどちらでもよいとのことです)。上述したポートフォリオ管理は、色々なところから集めた情報を組み合わせて行っている方法ですが、Udemyで基礎を学んだおかげで、何のためにこのコマンドを打っているのかということをしっかりと理解できている実感があります。慣れてきた方は色々試してみて、自分なりに最適な方法を見つけていただきたいです。
- 投稿日:2020-11-21T14:53:34+09:00
【Git】git rebaseでコンフリクトした際の対応方法
はじめに
コマンドで操作しているときにエラーメッセージに遭遇すると、いつも以上にびっくりしちゃいますよね。
慌ててなんとかしようとすると思わぬミスをしてしまうことがあるので、まずは落ち着いて状況を判断していきましょう。コンフリクトが解消できそうな場合
まずは以下を参考にコンフリクトの修正をしましょう。
参考:コマンドラインを使用してマージコンフリクトを解決するコンフリクト箇所を修正してコミットしたら、中断しているリベースを再開しなければなりません。
以下コマンドで残りのリベースを再開しましょう。git rebase --continue
リベース前に戻したい場合
自分で直すのが無理そうだったり、そもそもリベースする対象を間違えてたりする場合もあります。
そんな場合は、以下のコマンドでリベース直前の状態に戻すことができますよ。git rebase --abort
よく分からない・判断できない場合
無理せず、周囲の方に相談しましょう。
「何をしようとしたら」「どうなったのか」「どこが分からないのか」ということをお伝えすると、伝わりやすいと思います。
例:「リベースしてmasterの変更を取り込もうとしたら、hogeファイルでコンフリクトしました。。直そうと思ったのですが、どのように修正すれば良いのか分からないので教えてください。」報連相は大事です!
- 投稿日:2020-11-21T14:17:44+09:00
任意の複数ブランチを一括削除したい件
困ったこと
気づくと手元にブランチがたくさん存在した状態となり、一個ずつ
git branch -d hoge
としていくのは手間だなぁと感じることが多々ありました。同僚に同じような悩みがないか聞いたところ、masterなど特定のブランチ以外を一括で削除するスクリプトを使うとのことでしたが、それだと作業中のブランチも削除されてしまうので自分の期待通りではありませんでした。$ git branch hoge hoge1 * hoge10 hoge2 hoge3 hoge4 hoge5 hoge6 hoge7 hoge8 hoge9 masterやりたいこと
- 何かコマンドを叩く
- ブランチ一覧が表示される(絶対に削除しないブランチは事前にフィルターしておく
- ブランチ一覧上で任意のブランチ複数個を簡単に選択できる
- エンターキーを押したら任意のブランチが一括で削除される
解決方法
課題はブランチ一覧上で任意のブランチを複数個選択する方法だったが、 peco を使うことで簡単にできた。peco には複数行選択機能があったので、それによりブランチの複数選択ができた。あとはgitのブランチ削除コマンドに渡してあげれば解決。gitのalias設定をしておくことですぐに呼び出せるようにした。
select-delete-branch
は好みに設定してください。[alias] select-delete-branch = !git b -D $(git branch | grep -v '*' | grep -v master | sed 's/ //g' | peco)実行例
$ git branch aaa bbb ccc ddd eee fff * master $ git select-delete-branch # 以下が表示されるので Control + Space で複数選択をする QUERY> IgnoreCase [6 (1/1)] aaa bbb ccc ddd eee fff # エンターキーを押すと以下のように一括で削除される Deleted branch aaa (was 3d9df20). Deleted branch bbb (was 3d9df20). Deleted branch ccc (was 3d9df20). Deleted branch ddd (was 3d9df20). Deleted branch eee (was 3d9df20). Deleted branch fff (was 3d9df20)めっちゃ便利〜!
もし
Control + Space
が他でアプリで使用している場合は、peco のキーマップ設定を変更することも可能です。まとめ
実は最初はシェルスクリプトで同じことをしていたのですが、既存ライブラリでもっと楽にできるのでは?と考えていたら、pecoでサクッとできた。peco, 便利ですね。
- 投稿日:2020-11-21T12:48:39+09:00
ディレクトリによってgitアカウントを自動で切り替える設定(includeIf)
はじめに
gitのアカウントの切り替えってめんどくさいですよね?
切り替えを忘れて、仕事のgitにプライベートのアカウントでpushして直すのに苦労した方もいると思います。そんなことが起こらないように自動でアカウントを切り替える設定を紹介します。
gitアカウントを切り替える設定
特に設定をしていないと.gitconfigの設定が適用されます。(global)
そこで、仕事用のディレクトリ(work)と私用のディレクトリ(private)によって
gitのアカウントを自動で切り替えられるように設定ファイルを追加します。やることは2つです。
1..gitconfig
と同じ階層に.gitconfig_work
と.gitconfig_private
を作成してuser.name, user.emailを設定する
2..gitconfig
でディレクトリごとにパスを指定する1.
.gitconfig_work
と.gitconfig_private
を作成下記のファイルを作成してnameとemailをそれぞれ設定します。
~.gitconfig_work[user] name = workで使用したいuser.name email = workで使用したいglobalのuser.email~.gitconfig_private[user] name = privateで使用したいuser.name email = privateで使用したいglobalのuser.email2.
.gitconfig
でディレクトリごとにパスを指定するアカウントが切り替わるように
.gitconfig
でディレクトリごとにパスを指定する
includeIf
がめっちゃ重要!~.gitconfig[user] name = globalのuser.name email = globalのuser.email # workディレクトリの時に.gitconfig_workが読み込まれる [includeIf "gitdir:~/work/"] path = ~/.gitconfig_work # privateディレクトリの時に.gitconfig_privateが読み込まれる [includeIf "gitdir:~/private/"] path = ~/.gitconfig_private確認
まずはworkディレクトリ
workディレクトリの任意のプロジェクト内で下記のコマンドを打つとworkのname,emailになっていると思います。ターミナル$ git config user.name workのuser.name $ git config user.email workのuser.email次にはprivateディレクトリ
privateディレクトリの任意のプロジェクト内で下記のコマンドを打つとprivareのname,emailになっていると思います。ターミナル$ git config user.name privateのuser.name $ git config user.email privateのuser.email終わりに
これを知る前はshellに自作の関数を作って切り替えていました。
それだけでも十分感動したのですが、やっぱり自動で切り替えができる方がミスもしないのでいいですよね。
- 投稿日:2020-11-21T11:25:31+09:00
あ!間違えてPRをマージしちゃった!ってときにリバートする方法
はじめに
Gitと使って開発しているとPRを作成してレビューしてもらうことがあると思います。
そして、間違えて自分でマージしちゃうこともあると思います。そんなときのために、マージを取り消す方法をまとめて見ました。
Github上でボタンをポチポチ押すだけで簡単にできます。ブランチとPR
ブランチ
今回は
master
ブランチとtest1
ブランチを用意します。
master
: initial commitのみ
test1ブランチ
: masterから切って、"test1"というメッセージでコミットPR
test1をmasterに向けてPRを作成しました。(master ← test1)
リバート(revert)する方法
1. マージしてしまったPRから
revert
ボタンを押すマージした後は下記のような画面になっていると思いますが、その中にある
revert
ボタンを押します。2. mergeを打ち消すPRを作成する
revert
ボタンを押すと、mergeを打ち消すブランチとPRが自動的に作成されます。3. mergeを打ち消すPRをmergeする
PRを作成すると
Merge pull request
ボタンがあるのでそれを押します。4. mergeを打ち消すbranchを削除
必須ではないですが、mergeを打ち消すブランチを削除しておきます。(
Delete Branch
を押す)5. 確認
ブランチを見ると
master
とtest1
のみでmergeを打ち消すブランチはありませんコミットはこんな感じになっています。
revertしたブランチを再度PRに出したい時
revertしてもう一度PRを出そうとしても差分がなくPRが出せない状態になっています。
もう一度PRを出せるようにするには、revertをrevertする必要があるらしい。。。(何をしているかは正直わかっていません。。。)
masterに移動してまずはlogを確認。
(何度か試していて違うコミットになっているので、私の場合上の写真のcommit idと下のcommit idが異なっています。通常は一緒です。)$ git checkout master $ git pull # git上でmerge/revertしているのでpullが必要です。 $ git log --oneline 50b197d (HEAD -> master, origin/master) Merge pull request #2from shungo0525/revert-1-test1 0373b56 Revert "test1" 44a8c4b Merge pull request #1 from shungo0525/test1 13740b6 (origin/test1, test1) test1 a78da6f initial committest1にmasterをmergeします。
$ git checkout test1 $ git merge master $ git log --oneline # logで確認 50b197d (HEAD -> master, origin/master) Merge pull request #2 from shungo0525/revert-1-test1 0373b56 Revert "test1" 44a8c4b Merge pull request #1 from shungo0525/test1 13740b6 (origin/test1, test1) test1 a78da6f initial commitここからがrevertをrevertする手順
$ git revert 50b197d -m 1 $ git log --oneline 2fb9657 (HEAD -> test1) Revert "Merge pull request #2 from shungo0525/revert-1-test1" 50b197d (origin/master, master) Merge pull request #2 from shungo0525/revert-1-test1 0373b56 Revert "test1" 44a8c4b Merge pull request #1 from shungo0525/test1 13740b6 (origin/test1) test1 a78da6f initial commitそして最後にpush
$ git pushすると無事にPRが出せるようになりました。
おわりに
間違えてしまっても、戻す方法はあるので、落ち着いて対処しましょう。
- 投稿日:2020-11-21T01:05:54+09:00
【Git】Gitでフォルダの大文字・小文字を区別・ハマった時の対処方【Case Sensitive】
はじめに
知らないとハマることがあります。例えば以下のような場合です。
- Gitで大文字・小文字を区別して管理したい
- 小文字のフォルダ名の一部を大文字に変更したい
Configに設定
以下のコマンドを実行することで、Gitをcase-sensitiveにすることができます。
$ git config core.ignorecase falseしかしながら、これだけでは解決しないこともあります。
フォルダ・ファイル名の変更 -> リモート
以下の場合、個人の設定では防げない問題が発生することがあります。
- GitHubやGitLabなどのサービスでソース管理を行う場合
- 複数人での開発の場合
フォルダ名の変更を差分としてPushしたつもりでも、他の人にはその差分がうまく取り入れられない場合があります。
例えば、GitLabからクローンしたプロジェクトで、
nestedfolder
というフォルダ名を`nestedFoler
とキャメルケースに直したい場合。フォルダ名のみを修正しPushすると、GitLab上では差分が出ているように見えますが、別の人がPullしてもフォルダ名が変更されていないことがあります。
Gitでうまく管理できていないフォルダ名は、モジュールの
import
の際などに重要な問題を引き起こすこともあり危険です。対策
こうした問題を避ける最も簡単な方法は、ファイルの中身に必ず差分を作ることです。
ファイル名やフォルダ名のみを変更することはせず、例えばコメントを入れるなどしてファイルの中身に差分を作ります。