20201121のGitに関する記事は11件です。

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 update

gitのインストール

$ sudo apt install -y git

dockerのインストール
 ※【Dockerコンテナ内のUbuntuではsystemctlは使えない】の手順1を参考に。

docker-composeのインストール

$ sudo apt install -y docker-compose 

問題なくインストールできているか確認

$ ddocker-compose --version
docker-compose version 1.25.0, build unknown

2.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/dev
Github上のソースをクローン
$ 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.yml
version: '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:80

4.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

 ※サービスが削除されると、startrestartで起動できなくなる。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

メモ 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
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

【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してもらって完了です。お疲れ様でした。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

【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してもらって完了です。お疲れ様でした。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

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) を登録してください。

:bulb: 公開鍵の登録方法: 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"

:bulb: フォルダー内の .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 が使われる

参考

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

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 statusgit branchで確認作業を行うと、思わぬミスが減ると思います。
最初のうちは手順通り忠実にやるべきだと思いますが、たまに不測の事態が起きることがあります。その際に闇雲にコマンドを打ってしまうと何をやっているのかが分からなくなってしまうので、起きている事態を冷静に把握し、必要であれば調べるなり、Udemyで該当箇所を復習するなりすれば解決できると思います。

GitHubでポートフォリオ管理をして感じたメリット

・Issueを立てることによって、一つのタスクに集中できる
他のタスクに目移りすることがなくなり、作業効率が爆上がりします。
・チーム開発を意識した管理ができる
Issueやプルリクエスト(本来はレビューが入りますが)など、チーム開発で使われる管理方法に慣れることができます。
・GitHubでContributionsが蓄積され、錯覚資産になる(かもしれない)
いわゆる「草をはやす」というやつです。初めて聞いたという方は「GitHub 草」でググってみてください。

最後に

実は初めに紹介したUdemyの講座では、Issueは出てこなかったり、pullよりもmergeからのfetchを推奨したりしています(きちんと理解していればどちらでもよいとのことです)。上述したポートフォリオ管理は、色々なところから集めた情報を組み合わせて行っている方法ですが、Udemyで基礎を学んだおかげで、何のためにこのコマンドを打っているのかということをしっかりと理解できている実感があります。慣れてきた方は色々試してみて、自分なりに最適な方法を見つけていただきたいです。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

【Git】git rebaseでコンフリクトした際の対応方法

はじめに

コマンドで操作しているときにエラーメッセージに遭遇すると、いつも以上にびっくりしちゃいますよね。
慌ててなんとかしようとすると思わぬミスをしてしまうことがあるので、まずは落ち着いて状況を判断していきましょう。

コンフリクトが解消できそうな場合

まずは以下を参考にコンフリクトの修正をしましょう。
参考:コマンドラインを使用してマージコンフリクトを解決する

コンフリクト箇所を修正してコミットしたら、中断しているリベースを再開しなければなりません。
以下コマンドで残りのリベースを再開しましょう。

 git rebase --continue

参考:Git リベース後のマージコンフリクトを解決する

リベース前に戻したい場合

自分で直すのが無理そうだったり、そもそもリベースする対象を間違えてたりする場合もあります。
そんな場合は、以下のコマンドでリベース直前の状態に戻すことができますよ。

 git rebase --abort

参考:Git リベース後のマージコンフリクトを解決する

よく分からない・判断できない場合

無理せず、周囲の方に相談しましょう。

「何をしようとしたら」「どうなったのか」「どこが分からないのか」ということをお伝えすると、伝わりやすいと思います。
例:「リベースしてmasterの変更を取り込もうとしたら、hogeファイルでコンフリクトしました。。直そうと思ったのですが、どのように修正すれば良いのか分からないので教えてください。」

報連相は大事です!

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

任意の複数ブランチを一括削除したい件

困ったこと

気づくと手元にブランチがたくさん存在した状態となり、一個ずつ git branch -d hoge としていくのは手間だなぁと感じることが多々ありました。同僚に同じような悩みがないか聞いたところ、masterなど特定のブランチ以外を一括で削除するスクリプトを使うとのことでしたが、それだと作業中のブランチも削除されてしまうので自分の期待通りではありませんでした。

$ git branch
  hoge
  hoge1
* hoge10
  hoge2
  hoge3
  hoge4
  hoge5
  hoge6
  hoge7
  hoge8
  hoge9
  master

やりたいこと

  1. 何かコマンドを叩く
  2. ブランチ一覧が表示される(絶対に削除しないブランチは事前にフィルターしておく
  3. ブランチ一覧上で任意のブランチ複数個を簡単に選択できる
  4. エンターキーを押したら任意のブランチが一括で削除される
  5. :tada:

解決方法

課題はブランチ一覧上で任意のブランチを複数個選択する方法だったが、 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, 便利ですね。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

ディレクトリによって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.email

2. .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に自作の関数を作って切り替えていました。
それだけでも十分感動したのですが、やっぱり自動で切り替えができる方がミスもしないのでいいですよね。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

あ!間違えてPRをマージしちゃった!ってときにリバートする方法

はじめに

Gitと使って開発しているとPRを作成してレビューしてもらうことがあると思います。
そして、間違えて自分でマージしちゃうこともあると思います。

そんなときのために、マージを取り消す方法をまとめて見ました。
Github上でボタンをポチポチ押すだけで簡単にできます。

ブランチとPR

ブランチ

今回はmasterブランチとtest1ブランチを用意します。
master: initial commitのみ
test1ブランチ: masterから切って、"test1"というメッセージでコミット

PR

test1をmasterに向けてPRを作成しました。(master ← test1)

リバート(revert)する方法

1. マージしてしまったPRからrevertボタンを押す

マージした後は下記のような画面になっていると思いますが、その中にあるrevertボタンを押します。

スクリーンショット 2020-11-21 11.01.06.png

2. mergeを打ち消すPRを作成する

revertボタンを押すと、mergeを打ち消すブランチとPRが自動的に作成されます。

スクリーンショット 2020-11-21 11.01.49.png

3. mergeを打ち消すPRをmergeする

PRを作成するとMerge pull requestボタンがあるのでそれを押します。

スクリーンショット 2020-11-21 11.02.11.png

4. mergeを打ち消すbranchを削除

必須ではないですが、mergeを打ち消すブランチを削除しておきます。(Delete Branchを押す)

スクリーンショット 2020-11-21 11.02.23.png

5. 確認

ブランチを見るとmastertest1のみでmergeを打ち消すブランチはありません

スクリーンショット 2020-11-21 11.02.48.png

コミットはこんな感じになっています。

  • 間違えてしまったマージ
  • リバート
  • マージを打ち消すマージ スクリーンショット 2020-11-21 11.02.59.png

revertしたブランチを再度PRに出したい時

revertしてもう一度PRを出そうとしても差分がなくPRが出せない状態になっています。

スクリーンショット 2020-11-21 15.26.39.png

もう一度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 commit

test1に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-21 15.52.37.png

おわりに

間違えてしまっても、戻す方法はあるので、落ち着いて対処しましょう。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

【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の際などに重要な問題を引き起こすこともあり危険です。

対策

こうした問題を避ける最も簡単な方法は、ファイルの中身に必ず差分を作ることです。

ファイル名やフォルダ名のみを変更することはせず、例えばコメントを入れるなどしてファイルの中身に差分を作ります。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む