What's New Qiita

20200706のGitに関する記事は9件です。

  • 投稿日：2020-07-06T23:12:15+09:00

仕組みから理解するGit 入門 〜ひとり開発でも便利〜 参加レポート

仕組みから理解するGit 入門 〜ひとり開発でも便利〜の参加レポートです。

感想

めっちゃわかりやすかったです！
30分でこんなにGitのことを理解できるのかと普通に感動します。

動画中の図も非常に柔らかい雰囲気でとっつきやすいと思います。

  • 今までGitを使ったことがなかった方
  • GitクライアントツールでしかGit操作をしたことがなかった方

に非常にお勧めできます！

仕組みから理解する git 入門 〜ひとり開発でも便利〜
Youtube Liveへのリンクを上記イベントページから参照できます。

Gitとは

  • バージョン管理をするツール

バージョン管理とは

  • 変更履歴を管理すること

バージョン管理のメリット

変更履歴があるので元に戻せる

  • バージョン1
    • →バージョン2に変更
      • →やっぱりバージョン2に戻す
        といったことが可能

変更履歴があるので振り返れる

いつ誰がどんな変更をしたのかを振り返れる

個人開発であっても「昨日の自分は他人」という観点でバージョン管理をした方がいい

「この意味不明なコード、誰が書いたんだ？」→「あ、昨日の自分だった・・」

バージョン管理のやりかた

原始的な管理

ファイルコピー

  • 記事.txt
  • 記事_20200701.txt
  • 記事_20200702.txt

酷い場合

  • 記事_最新.txt
  • 記事_最終修正済み.txt

→結局なにが最新なん？

Gitの管理イメージ

  • ファイルの変更履歴データがGitに管理され、蓄積されていく

→何が最新なのか、いつ誰がどのような修正をしたのかわかる

メジャーなGitコマンド

初期化

git init

カレントディレクトリ以下のフォルダ、ファイルをGit管理の対象にする

ファイル追加

git add ファイル名

変更履歴を記録する対象に追加する
ファイル名はワイルドカード指定や.で全ファイルという指定が可能

git add *.txt

コミット

git commit -m 'コミットメッセージ'

Repositoryに変更を記録する
※変更内容を文章で記載しておく必要がある
→コミットメッセージ

コミットまでの流れ

git add zaru.txt

git commit -m 'zaru のプロフィールを編集'

ログ確認

git status

ファイルの状況を確認する
修正してaddされたファイルや修正したけどaddしてないファイルを見分けるために使う

git log

commitで記録した差分を確認する

ブランチ

うまくいっている状態のコードを残していろいろ試したい

masterブランチ

→featureブランチ
masterブランチの状態は残したまま、コピーして新しくブランチを作る

git switch ブランチ名

ブランチを切り替える

git switch -c 新しいブランチ名

新しいブランチを作成して切り替える

git branch

ブランチ一覧を表示する

git -d branch

ブランチを削除する

マージ

別のブランチのコミットを持ってきて反映させることをマージ（merge）という

git merge ブランチ名

試した成果をmergeで反映

リストア

git restore . --source 戻したい場所

指定した位置まで変更履歴を戻す

git restore . --source HEAD~2

２個前のコミットまで全て戻す

終わりに

私はいつもGitクライアントをメインで使っていましたが、内部でどのようなことが起きているのかをしるためにコマンドベースでGit管理してみようかな？
と思えるような勉強会でした。
主催のムーザルちゃんねるさんには感謝しかありません?
ムーザルちゃんねる

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-07-06T18:23:49+09:00

Terminal Bot / 面倒なTerminal操作を自動化したい！

環境

Mac OS(64bit)
Max8(https://cycling74.com/downloads)

概要

Maxを使ったターミナルをコントロールする便利なBotパッチです。長いターミナルのコマンドをワンクリック化したり、複数サーバーを同時にコントロールするような複雑な工程、またサーバーのログインをまたいだ処理などをワンクリック化できます。
image.png
terminalbot / download
https://github.com/sw-sw-sw/terminalbot

なぜ作ったか？

アプリ用サーバーや、ディープラーニングのGPUサーバーインスタンスをコントロールするとき、毎回、長い呪文のようなコマンドをドキュメントで確認したり、打ち続けるのに徒労を感じていました。Maxでそれらのプロセスを事前登録して、自動化できないかと思いつくってみました。

アプローチ

Max用にはshellというサードパーティーのパッチがあります。
https://github.com/jeremybernstein/shell
ただ出力が出なかったり、いろいろなクセがあるため上記の目的には使えませんでした。そこで、applescriptを中継して、mac標準のTerminalをダイレクトにコントロールする方法でやってみました。
Screen Shot 2020-07-07 at 15.20.50.png
terminalが立ち上がります。

こんなときに便利

  • さまざまなコマンドをMaxのパッチ上に並べておくと、ワンクリックで実行できます。google cloud platformのsdkのコマンドなど、コマンドやパスを入力するのも時間がかかるので便利。

  • タイマーを組んでおけば、所定の時間にサーバーを起動、シャットダウンできます。GCPのインスタンスは、使わなくても立ち上がっていると課金されてしまうので節約になります。

  • サーバーのログインをまたぐ作業など、バッチファイルにまとめられない作業を一括操作できます。（ログインするのに必要な時間をdelayパッチなどで設定しておくことで、ログインしてから操作するようなプログラムもできます。）下記は、朝、10時になったら、gcpのGPUインスタンスを立ち上げて、sshのポートフォワーディングでログインし、devフォルダーに移動し、仮想環境を立ち上げてからjuputer labを実行するという一連のコマンド操作をワンクリックにまとめています。
    image.png

  • 大量のサーバーインスタンスに同じ作業を毎回も実行するようなプロセスも、パッチ化しておくと便利。

Download & 使い方

下記gitからDLしてください。実行パッチmax_terminal.maxpatの中のmax_shellインレットにコマンドを書いたメッセージをつないでクリックするだけです。
https://github.com/sw-sw-sw/terminalbot

image.png

  • サンプルコマンドが並んでいるので、適当に編集して使って下さい。
  • プログラムは複数のスクリプトファイルでできています。すべてのファイルを実行パッチterminalbotと同じフォルダーを置いて下さい。

サンプルパッチ / terminalbot.maxpat について

基本的なterminalのコマンド

自分のよく使うコマンドをカスタマイズして使って下さい。
image.png

ディレクトリーパス

よく使うディレクトリーパスを並べておくと便利。
image.png

インスタンス操作

ディープラーニングで使うGCPのGPUインスタンスのスタート/ストップ、ログイン、仮想環境のオン/オフのコマンド。
image.png

仮想環境の操作コマンド

image.png

タイマーパッチ

毎日、時間が来たら、サーバーをオンにしたり、オフにしたりします。サンプルパッチterminalbot.maxpatでは、gcpのインスタンスのスタートとストップを制御するように結線しています。
image.png

直接入力

フォームに直接コマンドを入力することもできるようになっています。
image.png

gitパッチ

gitのコマンド操作を順に並べたパッチです。ファイル名は入力フォームに入れるようになっています。
image.png

開発のポイント

興味のある方は、こちらもどうぞ。

  • maxでshellが使えるパッチは、Max用にサードパーティーのshellパッチがいくつか出ていますが、catelina以降使えるのは、こちらだけ。動かないコマンド、パスのズレ、結果の表示がされない、など多少クセがあるようです
    　https://github.com/jeremybernstein/shell

  • そこでmaxからosascriptを使って、applescriptを呼び出して、terminallを起動し、コマンドをpipeするようなアプローチを取っています。下記は、shellのモジュールパッチです。主に文字列操作をして、shellにわたすためのosascriptのコマンドを生成処理しています。

  • image.png

image.png

下記はapplescriptです。terminalを起動し、受け取ったコマンドの文字列を渡し実行しています。osascriptの引数が、argvに入ります。argvは配列になっていて、item 1 of argvは、一個目の配列の値を示しています。それをcommandをいう変数に入れます。tell applicationでterminalアプリを呼び出します。activateでウィンドウをアクティブにして、一つめのwindowにコマンドを文字列として渡して実行します。

script.scpt

on run argv

    set command to item 1 of argv

    tell application "Terminal"

        activate
        log command
        do script command in window 1

    end tell

end run

応用

同じ考え方でmacのアプリケーションをapplescript経由で、bot操作することができるのでいろいろ応用が効きそう。applescriptは、mac上のアプリケーションやシステムを操作できる便利なスクリプトですが、書式が独特です。ネット上にもいくつか有益な日本語リファレンスがありましたので、興味のある方はご覧になってください。
https://seraphy.hatenablog.com/entry/20100408/p1
https://maku77.github.io/mac/applescript/terminal.html
http://piyocast.com/as/archives/3984
http://java.boy.jp/pukiwiki/index.php?ターミナルをAppleScriptで制御
https://www.it-swarm.dev/ja/macos/applescriptを使用してコマンドと文字列をterminalappに送信する/968622894/

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-07-06T18:23:49+09:00

Terminal Bot / 面倒なTerminal操作をワンクリックで自動化しよう

環境

Mac OS(64bit)
Max8(https://cycling74.com/downloads)

概要

Maxを使ったターミナルをコントロールする便利なBotパッチです。長いターミナルのコマンドをワンクリック化したり、複数サーバーを同時にコントロールするような複雑な工程、またサーバーのログインをまたいだ処理などをワンクリック化できます。
image.png
terminalbot / download
https://github.com/sw-sw-sw/terminal_bot

なぜ作ったか？

アプリ用サーバーや、ディープラーニングのGPUサーバーインスタンスをコントロールするとき、毎回、長い呪文のようなコマンドをドキュメントで確認したり、打ち続けるのに徒労を感じていました。Maxでそれらのプロセスを事前登録して、自動化できないかと思い、自分用につくってみました。結果、いい感じにできたので、みなさまにも共有しようと思いました。コーディング時間を節約しましょう！

アプローチ

Max用にはshellというサードパーティーのパッチがあります。
https://github.com/jeremybernstein/shell
ただ出力が出なかったり、いろいろなクセがあるため上記の目的にはすぐ使えませんでした。そこで、applescriptを中継して、Terminalアプリをダイレクトにコントロールする方法でやってみました。

こんなときに便利

  • さまざまなコマンドをMaxのパッチ上に並べておけば、ワンクリックで実行できます。google cloud platformのsdkのコマンドなどは、毎回ドキュメントを確認したり、パスを入力するのも時間がかかるので事前にパッチに並べて置けると便利。

  • タイマーを組んでおけば、所定の時間にサーバーを起動、シャットダウンできます。GCPのインスタンスは、使わなくても立ち上がっていると課金されてしまうので、時間でシャットダウンを登録しておけると安心で節約になります。

  • サーバーのログインをまたぐ作業など、バッチファイルにまとめられない作業を一括操作できます。（ログインするのに必要な時間をdelayパッチなどで設定しておくことで、ログインしてから操作するようなプログラムもできます。）下記は、朝、10時になったら、gcpのGPUインスタンスを立ち上げて、sshのポートフォワーディングでログインし、devフォルダーに移動し、仮想環境を立ち上げてからjuputer labを実行するという一連のコマンド操作をワンクリックにまとめています。
    image.png

  • 大量のサーバーインスタンスに同じ作業を毎回も実行するようなプロセスも、ワンクリックで実行できます。

Download & 使い方

下記gitからDLしてください。実行パッチmax_terminal.maxpatの中のmax_shellインレットにコマンドを書いたメッセージをつないでクリックするだけです！
https://github.com/sw-sw-sw/terminalbot

image.png

  • サンプルコマンドが並んでいるので、適当に編集して使って下さい。
  • プログラムは複数のスクリプトファイルでできています。すべてのファイルを実行パッチterminalbotと同じフォルダーを置いて下さい。

サンプルパッチ / terminalbot.maxpat について

基本的なterminalのコマンド

自分のよく使うコマンドをカスタマイズして使って下さい。
image.png

ディレクトリーパス

よく使うディレクトリーパスを並べておくと便利です。
image.png

インスタンス操作

ディープラーニングで使うGCPのGPUインスタンスのスタート/ストップ、ログイン、仮想環境のオン/オフのコマンドが並んでいます。（インスタンス名や、リージョン名などは毎回打つのは面倒ですよね）
image.png

仮想環境の操作コマンド

image.png

タイマーパッチ

毎日、時間が来たら、サーバーをオンにしたり、オフにしたりできる簡易タイマーです。サンプルパッチterminalbot.maxpatでは、gcpのインスタンスのスタートとストップを制御するようなプログラムになっています。p @timerというモジュールが時刻をカウントしています。実行時間をメッセージオブジェクトで与えると、残り時間が秒数で出力され、時間が来るとbangを出力します。（時間がすぎると、値がマイナスになりますが、0時をすぎると+に戻ります）実行したいコマンドのメッセージオブジェクトに線をつないでおきます。
image.png

直接入力

フォームに直接コマンドを入力することもできるようになっています。
image.png

gitパッチ

gitのコマンド操作を順に並べたパッチです。ファイル名は入力フォームに入れるようになっています。フォルダーに移動して、init、add、commit、push、webサイト側の確認まで順にコマンドが並んでいます。この一枚のパッチでできるので、結構便利です！
image.png

開発のポイント

興味のある方は、こちらもどうぞ。

  • maxでshellが使えるパッチは、Max用にサードパーティーのshellパッチがいくつか出ていますが、catelina以降使えるのは、こちらだけ。動かないコマンド、パスのズレ、結果の表示がされない、など多少クセがあるようです
    　https://github.com/jeremybernstein/shell

  • そこでmaxからosascriptを使って、applescriptを呼び出して、terminallを起動し、コマンドをpipeするようなアプローチを取っています。下記は、shellのモジュールパッチです。主に文字列操作をして、shellにわたすためのosascriptのコマンドを生成処理しているだけです。微妙な書式の違いがあるので、ファイアルパスを取得して加工したり、コマンドを文字列化したりしています。

  • image.png

maxのshellパッチにosascriptを使ってapplescriptにコマンドの文字列情報を引数として渡し実行しています。

image.png

下記はapplescriptです。terminalを起動し、受け取ったコマンドの文字列を渡し実行するだけです。osascriptの引数が、argvに入ります。argvは配列になっていて、item 1 of argvは、一個目の配列の値を示しています。それをcommandをいう変数に入れます。tell applicationでterminalアプリを呼び出します。activateでウィンドウをアクティブにして、一つめのwindowにコマンドを文字列として渡して実行します。

script.scpt

on run argv

    set command to item 1 of argv

    tell application "Terminal"

        activate
        log command
        do script command in window 1

    end tell

end run

応用

同じ考え方でmacのアプリケーションをapplescript経由で、bot操作することができるのでいろいろ応用が効きそうです！applescriptは、mac上のアプリケーションやシステムを操作できる便利なスクリプトですが、書式が独特すぎてかなり面倒です。ネット上にもいくつか有益な日本語リファレンスがありましたので、興味のある方はご覧になってください。
https://seraphy.hatenablog.com/entry/20100408/p1
https://maku77.github.io/mac/applescript/terminal.html
http://piyocast.com/as/archives/3984
http://java.boy.jp/pukiwiki/index.php?ターミナルをAppleScriptで制御
https://www.it-swarm.dev/ja/macos/applescriptを使用してコマンドと文字列をterminalappに送信する/968622894/

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-07-06T18:23:49+09:00

Terminal Bot / 面倒なTerminal操作を自動化

環境

Mac OS(64bit)
Max8(https://cycling74.com/downloads)

概要

Maxを使ったターミナルをコントロールする便利なBotパッチです。長いターミナルのコマンドをワンクリック化したり、複数サーバーを同時にコントロールするような複雑な工程、またサーバーのログインをまたいだ処理などをワンクリック化できます。
image.png
terminalbot / download
https://github.com/sw-sw-sw/terminal_bot

なぜ作ったか？

アプリ用サーバーや、ディープラーニングのGPUサーバーインスタンスをコントロールするとき、毎回、長い呪文のようなコマンドをドキュメントで確認したり、打ち続けるのに徒労を感じていました。Maxでそれらのプロセスを事前登録して、自動化できないかと思いつくってみました。

アプローチ

Max用にはshellというサードパーティーのパッチがあります。
https://github.com/jeremybernstein/shell
ただ出力が出なかったり、いろいろなクセがあるため上記の目的にはすぐ使えませんでした。そこで、applescriptを中継して、Terminalアプリをダイレクトにコントロールする方法でやってみました。

こんなときに便利

  • さまざまなコマンドをMaxのパッチ上に並べておくと、ワンクリックで実行できます。google cloud platformのsdkのコマンドなど、コマンドやパスを入力するのも時間がかかるので事前にパッチに並べて置けると便利。

  • タイマーを組んでおけば、所定の時間にサーバーを起動、シャットダウンできます。GCPのインスタンスは、使わなくても立ち上がっていると課金されてしまうので、時間でシャットダウンを登録しておけると安心で節約になります。

  • サーバーのログインをまたぐ作業など、バッチファイルにまとめられない作業を一括操作できます。（ログインするのに必要な時間をdelayパッチなどで設定しておくことで、ログインしてから操作するようなプログラムもできます。）下記は、朝、10時になったら、gcpのGPUインスタンスを立ち上げて、sshのポートフォワーディングでログインし、devフォルダーに移動し、仮想環境を立ち上げてからjuputer labを実行するという一連のコマンド操作をワンクリックにまとめています。
    image.png

  • 大量のサーバーインスタンスに同じ作業を毎回も実行するようなプロセスも、ワンクリック化できます。

Download & 使い方

下記gitからDLしてください。実行パッチmax_terminal.maxpatの中のmax_shellインレットにコマンドを書いたメッセージをつないでクリックするだけです。
https://github.com/sw-sw-sw/terminalbot

image.png

  • サンプルコマンドが並んでいるので、適当に編集して使って下さい。
  • プログラムは複数のスクリプトファイルでできています。すべてのファイルを実行パッチterminalbotと同じフォルダーを置いて下さい。

サンプルパッチ / terminalbot.maxpat について

基本的なterminalのコマンド

自分のよく使うコマンドをカスタマイズして使って下さい。
image.png

ディレクトリーパス

よく使うディレクトリーパスを並べておくと便利。
image.png

インスタンス操作

ディープラーニングで使うGCPのGPUインスタンスのスタート/ストップ、ログイン、仮想環境のオン/オフのコマンド。
image.png

仮想環境の操作コマンド

image.png

タイマーパッチ

毎日、時間が来たら、サーバーをオンにしたり、オフにしたりします。サンプルパッチterminalbot.maxpatでは、gcpのインスタンスのスタートとストップを制御するように結線しています。
image.png

直接入力

フォームに直接コマンドを入力することもできるようになっています。
image.png

gitパッチ

gitのコマンド操作を順に並べたパッチです。ファイル名は入力フォームに入れるようになっています。
image.png

開発のポイント

興味のある方は、こちらもどうぞ。

  • maxでshellが使えるパッチは、Max用にサードパーティーのshellパッチがいくつか出ていますが、catelina以降使えるのは、こちらだけ。動かないコマンド、パスのズレ、結果の表示がされない、など多少クセがあるようです
    　https://github.com/jeremybernstein/shell

  • そこでmaxからosascriptを使って、applescriptを呼び出して、terminallを起動し、コマンドをpipeするようなアプローチを取っています。下記は、shellのモジュールパッチです。主に文字列操作をして、shellにわたすためのosascriptのコマンドを生成処理しています。

  • image.png

image.png

下記はapplescriptです。terminalを起動し、受け取ったコマンドの文字列を渡し実行しています。osascriptの引数が、argvに入ります。argvは配列になっていて、item 1 of argvは、一個目の配列の値を示しています。それをcommandをいう変数に入れます。tell applicationでterminalアプリを呼び出します。activateでウィンドウをアクティブにして、一つめのwindowにコマンドを文字列として渡して実行します。

script.scpt

on run argv

    set command to item 1 of argv

    tell application "Terminal"

        activate
        log command
        do script command in window 1

    end tell

end run

応用

同じ考え方でmacのアプリケーションをapplescript経由で、bot操作することができるのでいろいろ応用が効きそう。applescriptは、mac上のアプリケーションやシステムを操作できる便利なスクリプトですが、書式が独特です。ネット上にもいくつか有益な日本語リファレンスがありましたので、興味のある方はご覧になってください。
https://seraphy.hatenablog.com/entry/20100408/p1
https://maku77.github.io/mac/applescript/terminal.html
http://piyocast.com/as/archives/3984
http://java.boy.jp/pukiwiki/index.php?ターミナルをAppleScriptで制御
https://www.it-swarm.dev/ja/macos/applescriptを使用してコマンドと文字列をterminalappに送信する/968622894/

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-07-06T16:14:56+09:00

Terminal Bot(by Max)

環境

Mac OS(64bit)
Max8(https://cycling74.com/downloads)

概要

Maxを使ったターミナルをコントロールする便利なBotパッチです。長いターミナルのコマンドをワンクリック化したり、複数サーバーを同時にコントロールするような複雑な工程、またサーバーのログインをまたいだ処理などをワンクリック化できます。
image.png
terminalbot / download
https://github.com/sw-sw-sw/terminal_bot

なぜ作ったか？

アプリ用サーバーや、ディープラーニングのGPUサーバーインスタンスをコントロールするとき、毎回、長い呪文のようなコマンドをドキュメントで確認したり、打ち続けるのに徒労を感じていました。Maxでそれらのプロセスを事前登録して、自動化できないかと思ったのがキッカケです。結果、いい感じにできました。

アプローチ

Max用にはshellというサードパーティーのパッチがあります。
https://github.com/jeremybernstein/shell
ただ出力が出なかったり、いろいろなクセがあるため上記の目的にはすぐ使えませんでした。そこで、applescriptを中継して、Terminalアプリをダイレクトにコントロールする方法でやってみました。

こんなときに便利

  • さまざまなコマンドをMaxのパッチ上に並べておけば、ワンクリックで実行できます。google cloud platformのsdkのコマンドなどは、毎回ドキュメントを確認したり、パスを入力するのも時間がかかるので事前にパッチに並べて置けると便利。

  • タイマーを組んでおけば、所定の時間にサーバーを起動、シャットダウンできます。GCPのインスタンスは、使わなくても立ち上がっていると課金されてしまうので、時間でシャットダウンを登録しておけると安心で節約になります。

  • サーバーのログインをまたぐ作業など、バッチファイルにまとめられない作業を一括操作できます。

  • 大量のサーバーインスタンスに同じ作業を毎回も実行するようなプロセスも、ワンクリックで実行できます。

[ 使い方 ]

  • 実行パッチmax_terminal.maxpatの中のmax_shellインレットにコマンドを書いたメッセージをつないでクリックするだけです！
    （サンプルコマンドが並んでいるので、適当に編集して使って下さい）
    下記gitからDLしてください。
    https://github.com/sw-sw-sw/terminal_bot

  • プログラムは複数のファイルでできておりlibフォルダーにまとまっています。自分のコマンドを並べて組んでおく、実行パッチterminalbotと同じ階層にlibフォルダーを置いて下さい。

  • サンプルパッチの説明です。
    基本的なterminalのコマンドが並んでいます。自由にエディットできるので、自分のよく使うコマンドをカスタマイズして使って下さい。
    image.png
    よく使うディレクトリーパスを並べておくと便利です。
    image.png

インスタンス操作

ディープラーニングで使うGCPのGPUインスタンスのスタート/ストップ、ログイン、仮想環境のオン/オフのコマンドが並んでいます。（インスタンス名や、リージョン名などは毎回打つのは面倒ですよね）
image.png

仮想環境の操作コマンド

image.png

タイマーパッチ

時間が来たら、サーバーをオンにしたり、オフにしたりできます。簡易的につくったものなので、こちらも自由にパッチをカスタマイズしてください。gitに上げたサンプルパッチterminalbot.maxpatでは、gcpのインスタンスのスタートとストップを制御するようなプログラムになっています。p @timerというモジュールが時刻をカウントしています。実行時間をメッセージオブジェクトで与えると、残り時間が秒数で出力され、時間が来るとbangを出力します。実行したいコマンドのメッセージオブジェクトに線をつないでおけば、実行をタイマー予約することができます。
image.png

直接入力

フォームに直接コマンドを入力することもできるようになっています。
image.png

gitパッチ

gitのコマンド操作を順に並べたパッチです。ファイル名は入力フォームに入れるようになっています。結構便利！
image.png

開発のポイント

興味のある方は、こちらもどうぞ。

  • maxでshellが使えるパッチは、Max用にサードパーティーのshellパッチがいくつか出ていますが、catelina以降使えるのは、こちらだけ。
    　https://github.com/jeremybernstein/shell
    　動かないコマンド、パスのズレ、結果の表示がされない、など多少クセがあるようです。こちらがコアなshellモジュールパッチです。

  • そこでmaxからosascriptを使って、applescriptを呼び出して、terminallを起動し、コマンドをpipeするようなアプローチを取っています。
    下記は、shellのモジュールパッチです。主に文字列操作をして、shellにわたすためのコマンドを生成処理しているだけです。微妙な書式の違いがあるので、ファイアルパスを取得して加工したり、コマンドを文字列化したりしています。

  • image.png

maxのshellパッチでosascriptを呼びます。osascriptを使ってapplescriptにコマンドの文字列情報を引数として渡しています。

image.png

applescriptからterminalを起動し、受け取ったコマンドを渡し実行する。osascriptの引数に値を渡すとargvに入ります。argvは配列になっていて、item 1 of argvは、一個目の配列の値を示しています。それをcommandをいう変数に入れます。tell applicationでterminalアプリを呼び出します。activateでウィンドウをアクティブにして、一つめのwindowにコマンドを文字列として渡して実行します。applescriptは、mac上のアプリケーションやシステムを操作できる便利なスクリプトですが、書式が独特すぎてかなり面倒です。ネット上にもいくつか有益な日本語リファレンスがありましたので、興味のある方はご覧になってください。

script.scpt

on run argv

    set command to item 1 of argv

    tell application "Terminal"

        activate
        log command
        do script command in window 1

    end tell

end run
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-07-06T16:14:56+09:00

Terminal Botでターミナル操作を自動化

環境

Mac OS(64bit)
Max8(https://cycling74.com/downloads)

概要

Maxを使ったターミナルをコントロールする便利なBotパッチです。長いターミナルのコマンドをワンクリック化したり、複数サーバーを同時にコントロールするような複雑な工程、またサーバーのログインをまたいだ処理などをワンクリック化できます。
image.png
terminalbot / download
https://github.com/sw-sw-sw/terminal_bot

なぜ作ったか？

アプリ用サーバーや、ディープラーニングのGPUサーバーインスタンスをコントロールするとき、毎回、長い呪文のようなコマンドをドキュメントで確認したり、打ち続けるのに徒労を感じていました。Maxでそれらのプロセスを事前登録して、自動化できないかと思い、自分用につくってみました。結果、いい感じにできたので、みなさまにも共有しようと思いました。コーディング時間を節約しましょう！

アプローチ

Max用にはshellというサードパーティーのパッチがあります。
https://github.com/jeremybernstein/shell
ただ出力が出なかったり、いろいろなクセがあるため上記の目的にはすぐ使えませんでした。そこで、applescriptを中継して、Terminalアプリをダイレクトにコントロールする方法でやってみました。

こんなときに便利

  • さまざまなコマンドをMaxのパッチ上に並べておけば、ワンクリックで実行できます。google cloud platformのsdkのコマンドなどは、毎回ドキュメントを確認したり、パスを入力するのも時間がかかるので事前にパッチに並べて置けると便利。

  • タイマーを組んでおけば、所定の時間にサーバーを起動、シャットダウンできます。GCPのインスタンスは、使わなくても立ち上がっていると課金されてしまうので、時間でシャットダウンを登録しておけると安心で節約になります。

  • サーバーのログインをまたぐ作業など、バッチファイルにまとめられない作業を一括操作できます。（ログインするのに必要な時間をdelayパッチなどで設定しておくことで、ログインしてから操作するようなプログラムもできます。）下記は、朝、10時になったら、gcpのGPUインスタンスを立ち上げて、sshのポートフォワーディングでログインし、devフォルダーに移動し、仮想環境を立ち上げてからjuputer labを実行するという一連のコマンド操作をワンクリックにまとめています。
    image.png

  • 大量のサーバーインスタンスに同じ作業を毎回も実行するようなプロセスも、ワンクリックで実行できます。

Download & 使い方

下記gitからDLしてください。実行パッチmax_terminal.maxpatの中のmax_shellインレットにコマンドを書いたメッセージをつないでクリックするだけです！
https://github.com/sw-sw-sw/terminal_bot

image.png

  • サンプルコマンドが並んでいるので、適当に編集して使って下さい。
  • プログラムは複数のスクリプトファイルでできておりlibフォルダーにまとまっています。実行パッチterminalbotと同じ階層にlibフォルダーを置いて下さい。

サンプルパッチ / terminalbot.maxpat について

基本的なterminalのコマンド

自分のよく使うコマンドをカスタマイズして使って下さい。
image.png

ディレクトリーパス

よく使うディレクトリーパスを並べておくと便利です。
image.png

インスタンス操作

ディープラーニングで使うGCPのGPUインスタンスのスタート/ストップ、ログイン、仮想環境のオン/オフのコマンドが並んでいます。（インスタンス名や、リージョン名などは毎回打つのは面倒ですよね）
image.png

仮想環境の操作コマンド

image.png

タイマーパッチ

毎日、時間が来たら、サーバーをオンにしたり、オフにしたりできる簡易タイマーです。サンプルパッチterminalbot.maxpatでは、gcpのインスタンスのスタートとストップを制御するようなプログラムになっています。p @timerというモジュールが時刻をカウントしています。実行時間をメッセージオブジェクトで与えると、残り時間が秒数で出力され、時間が来るとbangを出力します。（時間がすぎると、値がマイナスになりますが、0時をすぎると+に戻ります）実行したいコマンドのメッセージオブジェクトに線をつないでおきます。
image.png

直接入力

フォームに直接コマンドを入力することもできるようになっています。
image.png

gitパッチ

gitのコマンド操作を順に並べたパッチです。ファイル名は入力フォームに入れるようになっています。フォルダーに移動して、init、add、commit、push、webサイト側の確認まで順にコマンドが並んでいます。この一枚のパッチでできるので、結構便利です！
image.png

開発のポイント

興味のある方は、こちらもどうぞ。

  • maxでshellが使えるパッチは、Max用にサードパーティーのshellパッチがいくつか出ていますが、catelina以降使えるのは、こちらだけ。動かないコマンド、パスのズレ、結果の表示がされない、など多少クセがあるようです
    　https://github.com/jeremybernstein/shell

  • そこでmaxからosascriptを使って、applescriptを呼び出して、terminallを起動し、コマンドをpipeするようなアプローチを取っています。下記は、shellのモジュールパッチです。主に文字列操作をして、shellにわたすためのosascriptのコマンドを生成処理しているだけです。微妙な書式の違いがあるので、ファイアルパスを取得して加工したり、コマンドを文字列化したりしています。

  • image.png

maxのshellパッチにosascriptを使ってapplescriptにコマンドの文字列情報を引数として渡し実行しています。

image.png

下記はapplescriptです。terminalを起動し、受け取ったコマンドの文字列を渡し実行するだけです。osascriptの引数が、argvに入ります。argvは配列になっていて、item 1 of argvは、一個目の配列の値を示しています。それをcommandをいう変数に入れます。tell applicationでterminalアプリを呼び出します。activateでウィンドウをアクティブにして、一つめのwindowにコマンドを文字列として渡して実行します。

script.scpt

on run argv

    set command to item 1 of argv

    tell application "Terminal"

        activate
        log command
        do script command in window 1

    end tell

end run

応用

同じ考え方でmacのアプリケーションをapplescript経由で、bot操作することができるのでいろいろ応用が効きそうです！applescriptは、mac上のアプリケーションやシステムを操作できる便利なスクリプトですが、書式が独特すぎてかなり面倒です。ネット上にもいくつか有益な日本語リファレンスがありましたので、興味のある方はご覧になってください。
https://seraphy.hatenablog.com/entry/20100408/p1
https://maku77.github.io/mac/applescript/terminal.html
http://piyocast.com/as/archives/3984
http://java.boy.jp/pukiwiki/index.php?ターミナルをAppleScriptで制御
https://www.it-swarm.dev/ja/macos/applescriptを使用してコマンドと文字列をterminalappに送信する/968622894/

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-07-06T05:20:49+09:00

Gitについて無知だったので体験したことをまとめます

はじめに

今回6週間でチームビルディングからプロダクト公開までやるプロジェクトに参加させて頂きました。
プロジェクト全体に関しては以下のリンクでまとめておりますのでそちらを御覧ください。
私についてはその記事や過去記事等ご覧になっていただければと思いますが、端的に言うと未経験でエンジニアを目指して就職活動をしているものです。

プロジェクトについてはこちら

この記事ではGit(GitHub)について初めてチームで本格的に使うことになったのでそれについてまとめたものになります。
Git(GitHub)に関しては以前こういうもの を作った際にリポジトリを作ってpushをしたことはありますが、今回本格的に使うにあたって慣れるのに苦労したので
そういうところを含めて少し、アウトプットをしておこうかなと思います。

そもそもGitHubとは？

難しいことは抜きにして簡単にいうとアプリやサービスのソースコードをネット上に公開できるサービスです。
例えばPythonのフレームワークであるDjangoも下の画像のようにまるまる公開されています。

GitHub.参考.png

開発者の人たちはこれをそのまま自分のローカル環境に引っ張ってきたりなんだりして開発を行ったり、そのアプリの環境を再現したりするわけですね。

そして、それを応用するとチームでの開発をより円滑にできるよというのがこのサービスの肝であるというわけです。

じゃあ具体的にどうやってチームでGitHubを使っていくの？

リポジトリを作る

まず、代表者(多分、設計を担当されている方なはす。今回のプロジェクトではそうでした)がマスターとなるディレクトリをGitHubに上げます。
すると先程の画像のような状態になります。

画像を見るとBranch:masterというところが見えると思います、ブランチとは日本語でいうと枝ですがまさにGitHubでの開発は枝分かれをしながら進めていくというイメージを持つとわかりやすいです。
Branch:masterは枝分かれ元かつオリジナルだと思ってください。
ちなみにこうやってGitHubにソースコードを公開している状態のものをリポジトリと呼称したりします。

リポジトリをクローンし、機能ごとに作業ブランチを切る

さて、Branch:masterにあたるブランチ(別にmasterに拘る必要はなくdevelopなどとつけてもいい)ができたら、コードを書いて機能を実装していく人達(語弊があるかもしれませんが以降PGと略します)は
このブランチを枝分かれさせて、作業をしていくことになります。
枝分かれのさせ方には色々ありますが、今回のプロジェクトでは認証なら認証で1ブランチと担当する機能ごとにその都度枝分かれをさせていきました。1機能1ブランチというわけです。
ちなみに枝分かれさせる行為のことは「ブランチを切る」と言われるみたいなので、以降そう呼ぶことにしますね。

ではブランチを切るというのはどういうことなのかというと

  1. 作業ディレクトリを用意してBranch:masterにあたるブランチをクローンする。
  2. 作業ブランチを作成する

という手順の作業のことを指します。
クローンをするというのは簡単にいうとコピペをするということですね、やり方は後ほど。
そうなるとまずローカルにBranch:masterにあたるブランチのコピーができて、さらにそのコピーとして作業ブランチができるということになります。
ところで、ここでまず私と同じ初学者の方にここで聞きたいのですがこの時点でブランチの数はいくつだと思いますか？
おそらく2個または3個と答える方が多いと思います、私もプロジェクトの途中までそう思っていました。
ところがこれが違うわけで、ここがGitHubというかGitを理解する上での一つの壁になるのだと思いました。

では何を言っているのだ？ ということになりますが、結論からいうとこの時点でのブランチの数は4つになります。
上位関係にあたる順から挙げていくと

  1. Branch:masterにあたるブランチ(GitHub上のブランチ、リモートブランチと呼ばれます)
  2. リモートブランチを追跡するブランチ(masterブランチに対してならorigin/masterなどと呼ばれたりします)
  3. クローンしてきたBranch:masterにあたるブランチ
  4. 作業ブランチ

ということになります。
2のブランチがいきなり出てきましたのでこれがどういうものなのかというとリモートブランチで変更があった場合にまず、その変更を直接ローカルに適用する前にこのブランチで預かるということができるわけです。
リモートブランチはチームで開発していると他の人の作業結果や設計の修正やバグや不具合の対応などで日に日に変わっていきます。
なので、随時その変更をローカルのブランチ(この例だと3のブランチですね)に反映していかないといけません。
さりとて、いきなりリモートブランチの内容をローカルに反映させるのは意外に危険です。なぜならそれを実行した瞬間ローカルで作業していた内容が吹き飛ぶ可能性がままあるからです。
Branch:masterにあたるブランチは元となるブランチであり、後々説明しますが設計などの責任者や管理者にあたる人が管理するのでPGが直接どうこうするということはあまりないため直接下ろしてきても問題ないですが、これが例えば後ほどまた触れることになるのですが、作業ブランチをpushというコマンドでGitHubの方に上げて、作業ブランチのリモートブランチを作るといったことをする過程があるのですがその場合

  1. 作業ブランチのリモートブランチ
  2. 1のリモートブランチを追跡するブランチ
  3. ローカルのBranch:masterにあたるブランチ
  4. ローカルの作業ブランチ

という構成になるのはここまでやるとわかると思います。
厳密には3の部分では先述のBranch:masterにあたるブランチのリモートや追跡ブランチがあるのですが割愛します。
で、この状態でリモートブランチを一旦またローカルにおろしてくださいなんてことになったとき無遠慮にやってしまうとローカルの作業環境をふっとばしてしまう場合があります。
詳しくは以後のGitのコマンドについてのところで触れますが、私はこのあたりの理解が曖昧だったために都合3回位環境をふっとばして大変な思いをしました。
この事故は初学者故の事故とも言えますが、それ以外にもトラブルが起こる可能性があるのでそれを回避するためにも2のようなブランチがあるわけです。
ちなみに、作業ブランチにBranch:masterにあたるブランチの変更を反映させるといったこともできますがそれは後ほど触れることにします。

作業ブランチをリポジトリにあげる

さて、作業ブランチを作って作業をしていると自分の担当する機能を書いて完全にできあがった！ またはある程度は出来上がったけど進捗上聞きたいところや指示、指摘をもらいたいところがある……
といった場面が訪れると思います。
そういったときにGitHubにはPull requestという機能があります。
どういうものかというと、ローカルブランチをリポジトリに上げるとあるブランチとそのブランチとを比較して、その差分を表示してくれます。
その差分をもとにコメントを書いてBranch:masterにあたるブランチの管理者に指示を仰ぐことができるができるのがPull requestという機能です。

プルリク差分.png

現場によりけりにはなるという話は聞きますが真っ当な現場、特に私のような経験の浅い人間がチームにいる場合はメンターと言われる謂わば教育担当だったりする人にコードレビューを受けることになります。
コードレビューというのは自分の書いたコードを他者に評価してもらうことですね。
個々の部分は処理をわけて～とかこの部分のコードの書き方は少し汚いからもう少しキレイに～とかその他不備があれば都度指摘を受けて改善をしていくわけです。
なので作業ブランチをリポジトリにあげるというこの工程は1度で完結するものではなく、何度か行われることになることもあります。
そのレビューの工程をチャット形式で残していくのもPull requestという機能の1つです。
2020-06-19_03h29_02.png

作業ブランチをBranch:masterにあたるブランチに合流させる

レビューを繰り返し、レビュアーの人によしじゃあこの機能に関してはこのコードでOKだよと了承得たとします。
そうなるとこの作業ブランチでの作業は完了したことになるので、この作業ブランチで変更したファイルをBranch:masterにあたるブランチに適用させます。
枝分かれしていたものを取り込んで1本にするイメージがわかりやすいですね。
このように枝分かれさせたブランチの変更内容をオリジナルのブランチに取り込んでブランチを統合することを「ブランチをマージする」と呼ぶそうです。
この作業はチームで行う場合はレビュアーもしくは、設計の担当者が行います。
先述の通りブランチの変更を安易に適用させるのはトラブルの元になるので、チームでやる場合はオリジナルのブランチにマージできるのはこのように権限がある人のみだったり、
権限を持つ人に許可をもらった場合のみとなっているみたいです。

以上おおまかにはなりますが、この工程を機能の数など必要な回数行うことでアプリだったりシステムだったりが出来上がっていくというわけですね。

Gitの操作方法(コマンド)

さて、ここまででなんとなくチームでのGitを使った開発について流れは理解できたと思いますのでここからは操作方法を見ていきましょう。
実は今回このプロジェクトに参加してVScodeを使った環境構築を教えて頂いて、そのVScodeの拡張機能を使ったほうがわかりやすかったのですが正規のやり方をしっかり覚えることは大切なので
ここではターミナルでコマンドを打つやり方を紹介します。

なお、ターミナルでGitのコマンドを実行するにはGitをインストールしている必要があります。
やり方などは割愛しますので、インストールされていない方はgit for windowsなどとググってインストールしてみてください。
あとは当然ですが、ここからのコマンドはGitHubでアカウントを作っていないとダメなので持ってない方は登録しておきましょう。

リポジトリをfork(フォーク)する

厳密にはコマンドではないのですがリポジトリをクローンではなくフォークするとという場合があります。
クローンが先述の通り、リポジトリをローカル環境に複製するという処理だったのに対して、フォークはリポジトリを自分のリモートリポジトリとして複製するという処理になります。
私も最初フォークをして作業をしようとしたのですが、メンターの方から

フォークはOSS(オープンソースソフトウェア)などに対して、追加機能の実装やバグの改修など、オリジナルのリポジトリへ貢献することが前提で行うもの

といったようなご指摘があってクローンでやり直したということがありました。
フォークするとオリジナルのリポジトリ管理者には通知が行くようになっているみたいです。
なので1から自分たちで開発というときにはクローン、既存のOSSなどを改修するといったときにはフォークと使い分けが必要なので一応覚えておきましょう。
ちなみにフォークするには下記の画像のForkの部分をクリックするだけでできます。

GitHub fork.png

リポジトリをclone(クローン)する

では、改めてクローンについてです。
実はクローン自体は下記の画像のclone or downloadの部分を押すとZipで落とせたりします。

2020-06-19_19h32_36.png

ただ、それでは意味がないので以下の工程を覚えましょう。

  1. 作業用のディレクトリを用意する
  2. 1にリポジトリをクローンする

たった2つです、簡単ですね。
Gitを導入したけどGitHubのアカウントの情報を入れていないとかだと2のあとにユーザ名(メールアドレス)・パスワードの入力を求められる場合があります。

コマンドは2で行う。

# cloneの例(Djangoのリポジトリをクローンする場合)

git clone https://github.com/django/django.git

という形を覚えておきましょう。
git clone URL……という形ですね。
URLの部分はclone or downloadのボタンを押すと画像のように出てきますのでそれをコピペです。
2020-06-19_19h36_20.png

最初のクローンの前には必ずgit initというリポジトリを新たに作成・または既存のリポジトリの場合は再初期化するコマンドを打つことをおすすめします。
これをやっておかないと、例えば複数のリポジトリを管理していた場合、後ほど作業ブランチをリポジトリにあげるときに予期せぬものや別のリポジトリにまた別のリポジトリの作業をあげてしまうなど
トラブルの原因になるからです。
私は2回ほどやらかしてます。みなさんはやらないようにしましょう。

作業ブランチを切る

次はブランチを切っていきます。
クローンしたリポジトリのルートディレクトリにディレクトリを合わせたあと

# 現在のブランチを確認
git branch --contains=HEAD

# ブランチの作成
git branch feature/~

# ブランチの移動
git checkout feature/~

## 作成と移動を同時に行う場合
git checkout -b feature/~

とコマンドを打ってください。
feature/~の部分はブランチ名を決める部分なのですが、
通例としてどの機能の作業ブランチなのかというのを表すために、feature/機能名とかfeature/設計書で定義してある機能番号などと定義するみたいです。
ブランチ名自体は自由に決めることができます。

ファイルの編集や追加などローカルでの作業内容をローカルリポジトリに反映させる

さて、クローンして作業ブランチを切りそこで実際にガリガリとコードを書いてCtrl+Sなどで保存をしたとします。
しかし、このままでは厳密にはローカルのリポジトリ(feature/~ブランチ)には変更や追加は反映されていません。
そのために以下のコマンドを打ちます。
ちなみにローカルリポジトリに反映するべき変更や追加を行ったファイルを指定することをステージングするなんて言ったりするそうです。

# 現在のディレクトリ以下すべてをステージングする
git add .

# 特定のファイルをステージングする(例 ルート/test/test.py)
git add ./test/test.py

# 特定のディレクトリをステージングする(例 ルート/testにおいてtestフォルダすべてをステージングしたい)
git add ./test

ちなみに初めてのステージングの際はgit add .で実行すると思います。
しかし、中には必ずaddを適用したくないファイルがあるんだけども……という場合があるかもしれません。
Gitではクローンした段階でクローンしたファイルは追跡といって常に差分を確認されている状態になります。
この状態で今回の記事の工程を完了してしまうと、当然addの対象外としたいファイルを含んだ状態で作業が完了してしまいます。
なので、そうしたことを防ぐために.gitignoreというファイルをルートディレクトリに作成し、そこで追跡の対象から外したいディレクトリやファイルを定義しておきましょう。
詳細は私が解説するよりも以下の参考記事を参照される方がわかりやすいので紹介させていただきます。
ちなみにチームで開発している場合、責任者の許可なしに.gitignoreを変更しないのがベターです。私はやってしまって余計なタスクを増やしてしまいました……

[Git] .gitignoreの仕様詳解
.gitignoreについて

ステージングで変更部分を指定したら、今度はそれをコミットしてローカルリポジトリに反映します。
コマンドは以下の通りです。

git commit -m "コメント"

-mオプションの後にはこのコミットがどういうコミットなのかということを書くことができます。
例えば最初のコミットならばfirst commit、レビューを受けてそれを修正したものをコミットするならレビュー1を受けて修正といった感じです。
これでローカルリポジトリに変更が反映されて、あとはもう1つ工程を踏むとリモートリポジトリに作業ブランチをあげることができます。
しかし、ここで例えば間違えてaddしてたとかcommitしたら想定外のファイルがcommitされていた……といったように、
ここまでのaddやcommitを取り消したい……といった状況が出てくるかもしれません。

その場合はgit resetコマンドを使うのですがオプションによって挙動が違いますので注意してください。
今回はコミットした直後にaddやcommitを取り消したくなったということを例に説明します。

# commitを取り消したい
git reset --soft HEAD

# commitだけでなくaddも取り消したい
git reset HEAD

# add`やcommitどころかいっそのことファイルの変更や追加までなかったことにしたい
git reset --hard HEAD

--softや--hardがオプションでどこまで取り消したいのかの指定、HEADの部分がどのコミットを取り消したいのかという指定になります。
つまり、オプションをつけなかった場合はそのコミット中のadd及びcommitまでなかったことになるということですね。
ちなみにHEAD^とすると一つ前のコミットを指定することができます、またそれらの代わりにコミットにはIDが振られるのでそのIDを入れると特定のコミットを指定できるみたいです。

作業ブランチ(ローカルリポジトリ)をリモートリポジトリへあげる

さていよいよ作業ブランチをリモートリポジトリにあげていきます。
まず、その前にgit statusコマンドで現在のリポジトリの状態を確認しましょう。
このコマンドを打つと例えばaddはしてるけど、commitはまだだよ？といったように現在そのリポジトリがどういう状態なのか教えてくれます。
問題なさそうなら次の工程に進みます。

まずはBranch:masterにあたるブランチ、つまりオリジナルのリモートリポジトリの最新版を作業ブランチに反映させます。
チームで開発していると他の人の作業ブランチがマージされていたり、仕様の変更や細かい修正などなどBranch:masterにあたるブランチは日々更新されていきます。
この更新を無視してしまうとレビューのときに不都合がおきたり、いざ自分の作業ブランチのレビューでOKをもらいマージをしてもらう……というところで後述の競合が起きてしまうなんていうトラブルの原因になります。
なので、できるだけこの段階でBranch:masterにあたるブランチの更新をこちらに取り込んでおこうということになるわけです。

で、リポジトリをクローンし、機能ごとに作業ブランチを切るの項で説明したとおり、ブランチは階層になっていて段階的に更新を受け取ったり、渡せたりできます。
渡し方は今やっているところですが、一旦ここで受け取り方を見てみましょう。

# `Branch:master`にあたるブランチ(リモートリポジトリのmasterブランチ)の変更をリモートリポジトリ追跡ブランチ(この場合はorigin/masterブランチ)に受け取る
git fetch origin master

# リモートリポジトリ追跡ブランチ(この場合はorigin/masterブランチ)に受け取った変更を現在のブランチに反映する
git merge origin/master

# 上記の2つの過程を同時に行う
git pull origin master

ちなみにmergeコマンドはorigin/masterブランチとローカルリポジトリとで競合があった場合はエラーが発生して実行できません。
ただし、pullでやってしまうとmergeまで一気にやってしまうためかたまに実行されてしまった先でエラーが発生してしまうこともあるみたいです。
なので、これら取り消し方も覚えておきましょう。

# fetchを取り消す
git reset --hard HEAD

# merge取り消す
git merge --abort

fetchの取り消しのコマンドは先程出てきたので割愛します。
ちなみにpullの取り消しはmergeの取り消し→fetchの取り消しという順でやることでできます。
競合とは？ というところやその解消のやり方についてはやや例を挙げるには難しいので以下の参考記事がわかりやすかったのでそちらを参照してみてください。

Git コンフリクト解消手順

では、ここまでで無事にmasterブランチの変更を現在のブランチに反映できたなら

git push origin feature/~

というコマンドを打てば作業ブランチ(ローカルリポジトリ)をリモートリポジトリにあげることができます。
このように作業ブランチのようにローカルで作ったブランチをリモートにも反映させることをプッシュすると呼ぶそうです。
これでリモートの方でもmasterブランチからfeature/~ブランチが枝分かれしている状態となるわけです。

Pull Requestを出す

先述の通り、チームで開発している場合はメンターや責任者・管理者・設計担当……etc からコードレビューをしてもらい、承認を得ないと作業は完了しません。
なので、初めてのプッシュの際は必ずPull Requestを出します。
といってもGitHubの場合は初めてプッシュした場合、必ずリモートリポジトリ上にガイドが出るのでその通りに進めていけば問題ありません。
詳しく知りたい方は以下の参考記事を参照してみてください。

[実践] はじめてのPull Requestをやってみよう

トラブルシューティング

プッシュした後、レビューを受けてそれに基づいて修正をしていたらわけがわからなくなってしまった……etcの事情でプッシュ直後の環境に戻したい

→
1. .gitignoreを削除する。
2. 未追跡のファイルをすべて削除する
3. git branch -D [ブランチ名]でローカルの作業ブランチを削除する
4. もう一度、作業ブランチを切る。(その前に一応ローカルのmasterブランチを最新にしておくのがいいかも)
5. 切ったブランチでgit pullを行う

私の場合はプッシュした後に.gitignoreを削除するというアクロバットなことをやらかした結果、この工程を実行することになりました。

最後に

ここまで書いてきましたが、これでようやくGitの基本が理解できたというような状態です。
Gitはまだまだ奥が深いな……と思わざるをえないというのはもちろん、プロジェクトに今回参加してなかったらこれだけのことを身を以て理解することはできなかっただろうなと感じました。

参考サイト

君には1時間でGitについて知ってもらう(with VSCode)
図解！ Gitのブランチ・ツリーをちゃんと読む
【やっとわかった！】gitのHEAD^とHEAD~の違い
Gitを使ってPull Requestを投げるまで
git-resetは結局何を戻すのか
【初心者向け】git fetch、git merge、git pullの違いについて
Gitでローカルブランチを削除する
[Git] .gitignoreの仕様詳解
.gitignoreについて
Gitプルリクエストでコンフリクトが発生した場合の対応
Git コンフリクト解消手順
[実践] はじめてのPull Requestをやってみよう

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-07-06T05:07:45+09:00

初心者がDjangoによる6週間でチームビルディングからプロダクト公開までやるプロジェクトに参加した話

はじめに

今回6週間でチームビルディングからプロダクト公開までやるプロジェクトに参加させて頂きました。
プロジェクトにおいて私が担当したことや特に学んだスキルなどは以下の通り個別に記事を書きましたのでそちらを参照してください。

認証周りは甘く見ると痛い目を見るという話(django-allauthを使った認証を導入してみて編)
初めてVScodeを導入して作業をしたときの感想及び覚書
Gitについて無知だったので体験したことをまとめます
pandasと私がプロジェクトで担当した機能の話

ここではプロジェクト全体のことや作った成果物、及び私個人についての記事になります。

作ったもの

EARY MORING STAR

プロジェクトの企画はSaku731さん によるものです。
参加者の中に現職会計士の方やデータサイエンティストを専攻されてる方がいらっしゃったことからWebスクレイピングを使った投資信託サポートツールを作ろうということで話が決まりました。

利用方法としては

  1. 簡単なアンケートに答えて自分の投資タイプを知る
  2. 会員登録

これだけです。

機能としては

  • 投資タイプの簡単な自己分析
  • 投資ポートフォリオの作成
  • 投資ポートフォリオの分析
  • ある銘柄に対してのリスク・リターンの似た銘柄の表示
  • ある銘柄に対してその銘柄を持っているユーザーが他に持っている銘柄の表示
  • ポートフォリオDBから人気の銘柄を取得(「実際に買われている銘柄」の人気度)
  • 閲覧履歴DBから人気銘柄を取得(「よく見られている銘柄」の人気度)
  • 投資信託閲覧履歴の追加

といったところが挙げられます。
以下いくつかのスクリーンショットになります。

2020-07-06_03h30_32.png
2020-07-06_03h30_25.png
2020-07-06_03h31_37.png
2020-07-06_03h32_50.png
2020-07-06_03h33_27.png

スクレイピングについては私は担当ではなく、スキルとしてもない部分なので詳しいことはわかりませんが

  1. スクレイピング結果をCSV出力する
  2. CSVをUtilでDBに登録
  3. ローカルでDBに出力+GithubにPush

という形で実現しているそうです。
なぜかというと担当の方が諸事情でプロジェクトから離脱してしまい、この機能に限らずタスクがキャリーオーバーになってしまい結果、時間切れとなったしまっがゆえの苦肉の策という印象をMTGからは受けました。
引き継いだ方はかなり強い人でしたが時間が足りなかったみたいです。

なお、このプロジェクトに関しては上記URLの成果物はそのまま参加者が各々のポートフォリオとして就活・転職などに用いることが可能になっています。

ですが、その都合上リポジトリは公には公開しないという決まりになっているのでそのあたりご了承頂ければと思います。
これは公にすることで仮に参加者内で複数人が今回の成果物を就職活動に利用した場合に万が一にもいわゆるパクリなのでは？ と採用者側にいらぬ誤解を与えないようにするための処置だそうです。

ただし、そのうち参加者個人でEC2などでサーバーを立てて運用をしていくことになるので、そうなった場合は経緯を説明した上で採用者側に求められた場合は自分のリポジトリにクローンしたものを公開することはあるのかもしれません。
自分の担当した部分についてのコードは公開してもよいとのことなのでそれは各機能のページでちらほらと公開しています。

私について及びプロジェクトの参加の動機

参加の動機

現在、未経験からWebエンジニアへの就職を目指しているのですが経歴と未経験というハンデから中々うまく行かない中である面接の中で

「チームでの開発を経験していないとわからないことが沢山ある」

という言葉を頂いたのと、個人で成果物を作るにもどういうプロダクトが他にあるのかとかそもそもどこまで作り込むのか……などといった疑問が実際にまがりなりにも成果物を自分で作ったときに少なからずあったので

「チーム開発の経験とプロダクトのモデルケース及び開発手順についての知見を得たい」

というのとちょうどPythonに興味はあったのでこの機会に触れてみるのがいいのではないか？ という思いで参加を決めました。

プロジェクトに参加するにあたっての私のスキルとやったこと

今回のプロジェクトはPython及びDjangoを使ってのチーム開発ということですが5月中旬のプロジェクト開始時における私のスキルは

未経験からweb系エンジニアになるための独学履歴~初めてのポートフォリオ作成記録 製作記録編~

この程度のものが作れる程度でした。

Python及びDjangoについてはプロジェクトの始まる1ヶ月前から勉強を初めて以下の記事程度のレベルでした。
Python及びDjangoの学習履歴はこちらです

それ以外の私個人については上記の記事で少し触れているので参照していただけると嬉しいです。

プロジェクトの流れ

プロジェクトは全6週で行われ、その週の初めに毎度MTGがありそこで進捗の確認やタスクの調整などを行っていくという形式でした。
以下、大まかにその週毎にやったことを書いていきます。

第1週(5/16～)

やったこと

  • プロジェクトの全体説明
  • プロジェクトのゴールの設定
  • 個人目標設定シート記入
  • プロジェクト開始前理解度チェック
  • プロジェクトで開発するサービスの決定

ここで予想外に人数が集まったことと、集まった人たちが強い人ばかりだったのもあって当初やらないはずだったWebスクレイピングをガッツリやっていくという方向性のサービスに決定したので、
上記の他に設計担当の方はこの週は要件定義と設計を、PG担当や私のようなスキルに乏しい方はpandasの使い方の基本を覚えるような課題に取り組むということをやりました。

第2~4週(5/23～)

やったこと

  • タスクの割り振り
  • 実装作業

ここから各々割り当てられた担当機能を実装していく工程でした。
私の担当は

  • リスク・リターンが類似してる銘柄を抽出して表示をする機能
  • この銘柄を持っている人がほかに持っている銘柄を抽出して表示する機能
  • 認証機能(リリース時に本番環境でソーシャルログインの障害が発生してそれを解消できず、その部分はカット)
  • 以上3機能の仮画面の作成
  • 認証画面の清書(レスポンシブ・スマホ表示対応)

以上の3つです、各機能について個別の記事にてやったことを書いています。

第5週(6/13)

やったこと

  • 各画面の清書作業とリリースに向けての細かい部分の改修

私の担当は以下の通りです

  • 認証に関わる画面(ログイン・アカウント作成・ログアウト確認画面)の清書

第6週(6/20)

やったこと

  • リリースに向けての最終調整

私の担当は以下の通りです。

  • 作成ボタン押下時にセッションからアンケート結果を登録ユーザーに紐づけ

第7週(6/27)

作業終了、最終MTGによる振り返り・感想戦

プロジェクトで学べたこと

  • チーム開発のプロセス
  • GitHubを使ったチーム開発
  • VScodeを使った開発
  • pandasについてのスキル
  • 要件定義・設計についての基礎知識及びプロセス
  • PipEnvの基本的な使い方
  • Djangoでの実装作業
  • Djangoでのデータベース操作
  • ドックストリングなどを含めたコードコメントのしきたり
  • EC2環境の構築及びデプロイのやり方

最後に関しては説明を受けてもAWSについての前提知識が0なのとPipEnvでリポジトリを展開することへの理解が浅く、まだ自分ではやれてないないのでこれからそのあたりを詰めてからやっていこうと思います。

やってみた感想

まず、実際にプロジェクトに取り組み始めて思ったことは

自分があまりにもモノを知らなすぎる(特にGitHubやVScodeなどのインフラ周りの知識)

ということでした。
今回参加者の方々はかなり強い方々ばかりだった上に、そもそも雪山を裸で登山するような状態で参加しているような私にとっては私が知らないことは向こうの常識のような状態だったので、圧倒的に戦力になっていないというプレッシャーがプロジェクトを通してものすごくありました。
これは別に参加者の方々が特別私に圧力をかけたとか、いじめをしたとかそういうことではなく、「役に立つどころかお手間を取らせてしまうことが多いな……」という私の罪悪感によるものです。
2~3月のあたりに就活のためになんどか企業様と面接をしましたが、その際に折に触れて

未経験のエンジニアを雇うということはリスクが高すぎる

仮に採用したとしても、1年は最低でも下積み。でもその期間でも給料はもらうわけで、そうなると実際に現場の人たちに対して戦力に慣れていないことにプレッシャーを感じてだめになってしまうことが怖い

というようなことを仰っていただいたのですが、なるほどこれはこういうことなのかというのを実感しました。
そんな中でもなんとか毎週せめて自分の担当した部分だけは遅れないように……とあくせくとやった結果、テックリードの方々の協力もあり、ソーシャルログイン部分だけが本番環境でエラーを出して削除ということになりましたが一応最低限の仕事だけはこなせた……と思いたいです。
概ね反省点や足りないところなどなどは今回の記事や個別の記事で書いたとは思いますが、それ以外で一つ心残りなのはテストコードを書く余裕がなかったなぁという点になります。
実際はテストはGitHub Actionsにおいて自動化してくださった方がいたのでそれで行われていたのですが、やっぱりそういう事ができるのはかっこいいなぁというのと、テストまでかけてようやく一人前という印象があるのでやはりそこまで手が回らない自分に歯がゆさを感じました。

といったように辛いことのように書きましたが、別に辛かったわけではなくプロジェクト自体はとても勉強になりましたし、何よりやっぱりチームでの開発を体験できたことはとても貴重で楽しいものでした。
Pull Requestなどで他の方が書いたコードが見れるのですが、実際自分が担当した機能でここどうやってるんだ？ ってところを参考にさせていただけたり、そもそもコードレビューを受けたこともなかったのでやることなすこと全部新鮮でした。

今後はこれをそのうちEC2環境にデプロイしなければならないのでそのための知識の補充を行いつつ、その際に今回のリリースでは省くことになったソーシャルログインあたりを復活させたり、もう少しユーザー情報周りを整備したり、そもそも今回ウェブスクレイピングはノータッチだったので、コードを眺めてどんなものか見てみるのもいいなと思っています。

あとは再度就活に向けて動いていかないといけないなといろいろ模索中です……就職について何かお声をかけていただければそれについては幸いです。

最後になりますが、私のような初心者もいいとこな人間でも快く受け入れて頂いた企画者、及びプロジェクト参加者の皆様、本当にありがとうございました。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-07-06T00:18:05+09:00

【私メモ１】GitとGitHub【必須の基本操作らしいのに概念が最高に初心者泣かせなgitを理解する】

作業手順

・ターミナルでの作業内容

mkdir newfile（フォルダの名前）
ターミナルで現在いる場所に新しいディレクトリ作成

touch hello.rb(ファイルの名前)
ファイル作成（拡張子に注意）

・VScode(コードエディタ)での作業内容

git init
gitリポジトリを作成する

git add .
インデックスにファイルを登録

add .だと作業中のフォルダに入っている全てのファイルをインデックスに登録
add hello.rb←特定のファイル（この場合だとhello.rb
）だけ登録することもできる！

git commit -m "ここにコメント"
変更内容の保存
自分がした作業内容とかをコメントに残す


・GitHubでの作業内容

＊Google等からGitHubを開いて自分のページでnew repositoryから
リモートリポジトリを作成する

＊出来たらurlをコピー


・VScode(コートエディタ）に戻って行う作業内容

git remote add origin URL
ローカルリポジトリとリモートリポジトリを関連付ける

originの部分は好きな名前でOK！

git push origin master
ファイルがプッシュされる
origin masterの部分省略可能


・branchの使い方

git branch
自分が今作業してるブランチを確認

git checkout -b new_branch_name
新しいブランチの作成
new_branch_nameのところが新しいブランチの名前になる
名前は_で繋ぐ


コードに変更加えたら
git add　→　git commit -m "変更内容" →　git push
この流れで新しく書き換わる！

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

日付別

タグ一覧