こんにちは。takpiyoです。今回はgitでドローンの開発をバージョン管理できる環境を作っていきます。gitのインストール,vscodeのgitの拡張機能,githubの連携については終わった前提で進めます。

	コマンド	参照するros
mbed	make	~/ros/lib/ros_lib/
pcのrosノード	catkin build	/opt/ros/melodic/

一つのワークスペース内でmbedとpcのrosノードを管理できるディレクトリ構成を作ります。

~
├── catkin_ws/
│　　   └── src/
│　　       └── drone_mbed/
│　　           ├── .git/
│　　           ├── mbed/
│　　           ├── include/
│　　           ├── src/
│　　           ├── Cmakelists.txt
│ 　　          └── package.xml
├── gcc4mbed/
└── ros/

こんなイメージです。
mbed/でmakeコマンドでコンパイル
drone_mbed/でcatkin build --thisでビルド

これで安心してバージョン管理下で開発が行なえます。

次回はESCを使ってブラシレスモータを回してみます。

こんにちは。takpiyoです。今回はgitでドローンの開発をバージョン管理できる環境を作っていきます。gitのインストール,vscodeのgitの拡張機能,githubの連携については終わった前提で進めます。

	コマンド	参照するros
mbed	make	~/ros/lib/ros_lib/
pcのrosノード	catkin build	/opt/ros/melodic/

一つのワークスペース内でmbedとpcのrosノードを管理できるディレクトリ構成を作ります。

~
├── catkin_ws/
│　　   └── src/
│　　       └── drone_mbed/
│　　           ├── .git/
│　　           ├── mbed/
│　　           ├── include/
│　　           ├── src/
│　　           ├── Cmakelists.txt
│ 　　          └── package.xml
├── gcc4mbed/
└── ros/

こんなイメージです。
mbed/でmakeコマンドでコンパイル
drone_mbed/でcatkin build --thisでビルド

これで安心してバージョン管理下で開発が行なえます。

次回はESCを使ってブラシレスモータを回してみます。

Linux,conda,ssh,git 関連個人的メモ

あまりにも技術力がなさすぎてあらゆる媒体で僕の知識不足が露呈しました。
自分が調べたそれぞれの基礎コマンドをまとめました。基本的には僕のメモ代わりなので、詳細な説明はありません。
随時追加していきます。

ssh関連

ssh起動方法

$ ssh [ユーザー名]@[ipアドレス]

ipアドレスは172.16. で続くアレ

Linux関連

ディレクトリの移動

$ cd ディレクトリ名

前のディレクトリ戻る

$ cd ..

ディレクトリ内のファイル表示

$ ls

ファイル削除

$ rm ファイル名 

ディレクトリ削除

$ rm -r ディレクトリ名

簡単にディレクトリが消せたらまずいから特殊なコマンドが必要なのかもしれない

ディレクトリ作成

$ mkdir ディレクトリ名

conda関連

condaのコマンドで、-eや-nという条件を追記するときがあるが、これは省略表記。
--env 、--name　ともそれぞれ書くことができる。

conda環境確認

$ conda info -e

conda環境作成

$ conda create -n 環境名

conda環境削除

$ conda remove -n 環境名 -all

conda環境起動

$ conda activate 環境名

conda環境閉じる

$ conda deactivate

ライブラリインストール

$ pip install ライブラリ名

ライブラリ名の後に==を入れればバージョンを指定できる
例えばこんな感じ

$ pip install pandas==0.19.2

git関連

gitのクローン作製

$  git clone https://github.com/ユーザー名/git名(?).git

参考文献

【初心者向け】Anacondaで仮想環境を作ってみる
[Python]Anacondaで仮想環境を作る

Gitの詳しい記事はいくらでもあるので初心者向けの内容です。
最近良く使うのでまとめてみました。

feature/bに変更を入れたいのに、実はaddをfeature/aでやってしまっていた！！

これでaddを取り消しできます。

git reset HEAD

1ファイルだけの場合は、ファイル名をつけましょう。

git reset HEAD test.txt

その後、stashで変更を保存し、

git stash

ブランチをfeature/bに変更

git checkout feature/b

これで、feature/b保存した変更を反映

git stash pop

後は、改めて、addし直すだけです。

feature/bに変更を入れたいのに、実はcommitをfeature/aでやってしまっていた！！

これでcommitを取り消しできます。
（HEAD^でローカルブランチのHEADを1つ手前に移動、しかし、--softなのでローカルのファイルはいじらない、というコマンドです）

git reset --soft HEAD^

その後の流れはaddのときと一緒。stashで変更を保存し、

git stash

ブランチをfeature/bに変更

git checkout feature/b

これで、feature/b保存した変更を反映

git stash pop

困りごと

試行錯誤を重ね、途中にデバッグコードが入ったりしているコミットが大量に含まれた状態で、そのままプルリクに出されるとレビュアーの労力が大きくなってしまう

注意事項

この記事は、
「統合ブランチのコミットはプロジェクトの履歴であり、個人の記録ではない」という思想に重きを置いて動いているプロジェクトに限った話になります。

取り扱わないこと

• コミットの粒度や単位をどのくらいの大きさにするべきか

１つのPRに対して、分岐点から最新コミットまでを、１つのコミットに纏めてしまう考え方を取り上げます。

今回の対象ケース

• 試行錯誤を重ね途中にデバッグコードが入ったりしているコミットが大量に含まれた状態で、そのままプルリクに出されるとレビュアーの労力が大きくなってしまう

今回の対象外のケース

• コミット粒度を細かく残しておくことに重きを置かれたプロジェクトなど。

▼Squash作業前▼ コミットの並び

$ git log --oneline


3jr0efj (HEAD -> topic) Last Commit
gdeq394 Comment 05
49rso9d Comment 04
7f4339j Comment 03
2f201gd Comment 02
s7d4jd7 Comment 01
9sae3ox (tag: release-v1.2.1) Merge pull request #53 from Foo/Bar 

Interactiveなrebaseコマンドの挙動

$ git rebase -i {分岐点のコミットID} {纏めたい最新コミットID}

rebaseの開始点と終了点の指定

• {第一引数}

  • (必須パラメータ)
  • コミットIDで指定 (ブランチ名指定も可能)

• {第二引数}

  • (省略可)
  • [省略した場合：デフォルト値 = HEADのコミットID]
  • コミットIDで指定 (ブランチ名指定も可能)

(手順1) 分岐点のコミットIDで、Interactive Rebaseを実行

# git rebase -i {分岐点のコミットID}
$ git rebase -i 9sae3ox

(手順2) デフォルトエディタ起動(vim)が自動起動

pick s7d4jd7 Comment 01
pick 2f201gd Comment 02
pick 7f4339j Comment 03
pick 49rso9d Comment 04
pick gdeq394 Comment 05
pick 3jr0efj Last Commit

# Commands:
# p, pick = use commit
# s, squash = use commit, but meld into previous commit

(手順3) pickをsquashに変える (１行目はpickにすること)

pick s7d4jd7 Comment 01
s 2f201gd Comment 02
s 7f4339j Comment 03
s 49rso9d Comment 04
s gdeq394 Comment 05
s 3jr0efj Last Commit

# Commands:
# p, pick = use commit
# s, squash = use commit, but meld into previous commit

• 上書き保存 (vimなら、:wq)
  

(手順4) ２度目のvimの自動起動

• Squashで纏めあげたコミットメッセージを編集
  • 「#」がついているところは、コメントアウト
    

今回は例として、コミットメッセージを以下のようにします。

Squashで１つに纏めたコミットです

• 上書き保存 (vimなら、:wq)
  

(手順5) 完了

▼Squash作業後▼ コミットの並び

$ git log --oneline

83vdkwf (HEAD -> topic) Squashで１つに纏めたコミットです
9sae3ox (tag: release-v1.2.1) Merge pull request #53 from Foo/Bar 

あとがき

コードをレビューしてもらう側の立場にいる際には
コードレビューをしてくださるレビュアーさんに
配慮したプルリクを送りたいですね。(自戒も込めて)

そして、レビュアーさんの負担を
減らすことができれば、
コードレビューの精度も上がり
結果的にチーム全体として
恩恵を受けられることに繋がるのかもしれません。