What's New Qiita

20200315のGitに関する記事は6件です。

  • 投稿日：2020-03-15T22:52:21+09:00

【手抜き】STM32の使い方まとめ 4.STM32CubeIDEでGit

前書き

引用主体の記事です（ひどい）。
基本は今日の引用に沿って進めてください。
やっておきたい設定とignoreする・しないがこの記事の目玉です。

テーマ概要

Gitを扱うにはいろいろな方法(ソフト)がありますし、CUI,GUI論争もあるかと思います…
ともあれSTMを使うGUIユーザーにお勧めです。
一つのソフトですべてできることが、統合開発環境(IDE)の醍醐味ですね。

今日の引用

初めてQiitaの外からの引用になります。Qiitaでは記事が多すぎていいものが見つけられなかったです

EclipseでGitを使ってみる

引用の補足

PC

私の環境は
Windows10 1909
CubeIDE 1.2.1
Nucleo F303k8 or F446RE

ですが、特に問題は出ておりません。
以降ではCubeIDEを日本語化したもので説明しています。
3.STM32CubeIDEの日本語化

パースペクティブ

これはCubeIDEの母体であるEclipseの用語なのですが、きれいに説明されてませんね…

CubeIDEの画面にはフォルダマップやコード、コンソール画面などの「ビュー」がたくさん表示されます。
コードを書く＆ビルドするときは上記を使う一方、デバッグするときはデバッグ内容の表示など別のビューが表示されてほしいですよね？
そのために、そのビューの開き方、並べ方をプリセットする機能がパースペクティブで、画面の右上あたりにあります。

CubeIDEはデフォルトで、C/C++,Debug,DeviceConfigTool(CubeMX)の三つのパースペクティブが存在すると思います。
デバッグを走らせるとDebugパースペクティブに自動で切り替えたり、iocファイルを開くとCubeMXパースペクティブが開いたりするはずです。
(最初はそれをするか・しないかのプロンプトが出てくる)

参照
Eclipse用語「ワークベンチ」「パースペクティブ」「エディター」「ビュー」「ワークスペース」について

やっておきたい設定

1.クローン先ディレクトリ

デフォルトではgitのclone先ディレクトリがC:/users/[ユーザー名]/Gitになっています。
開いているワークスペースのディレクトリとは違う（参照状態）のは、後々のバグの原因となり得ます。
そこで、クローン先を開いているワークスペースに変えます。
上バー「ウィンドウ」→設定→チーム→Git から
「デフォルト・リポジトリ・フォルダ」を${workspace_loc}にする
image.png

2.必要なビューの表示

「Gitステージング」
コミットするときに使用しますが、最初に表示されてなかった気がします。
Gitパースペクティブを開いた状態で「ウィンドウ→ビューの表示→Gitステージング」です。
「ヒストリー」
「Gitリポジトリ―」にあるリポジトリを選択した時に、コミットとブランチのグラフが見えます。規模によっては重宝するかも？

3.Gitのツールバー表示

マージやチェックアウトなどをボタン一つでしたい
Gitパースペクティブにて
・「ウィンドウ→パースペクティブ→パースペクティブのカスタマイズ」から
「アクションセット可用性」及び「メニュー可用性」のGitに✅
・「Toolbar Visibility」にてツールバーにほしいアイテムを選択します
image.png
自分の選択ははこんな感じですね
image.png

ignoreする・しない

ちょっと問題になりますよね…ignoreして無かったら何もいじってないのに変更がかかってgit操作が面倒になるケース、
逆に必要なものがaddされてなくて面倒になるケース…

CubeIDEのGUI(Egit)でリポジトリを構築した場合、gitignoreが自動生成されます。

ignoreすべきもの

・/Debug/ /Release/
まあビルドした時に生成されるファイルですから本質の変更とは無関係な変更となります。
・/.settings/
単語辞書ファイルが入ってます。そのため環境依存
・.mxproject
iocからgenerateしたときに生成されるもの、中を見るとプロジェクトのパスが書かれていて環境依存です。
・*.launch
デバッグや実行（書き込み）の時の設定ファイルです。
人によってはSTLink（ライター・デバッガー）を複数挿すため、そのID指定をすることがあると思います。よって環境依存となります。

ignoreするべきでないもの

「しないべき」「してはいけない」という意味で
・.ioc
CubeMXのファイル（GUIピン設定など）
・.project
CubeIDE用語「プロジェクト」の設定ファイルです。これがあることでこのフォルダがプロジェクトであることを認識します。
これがないとクローンした時にワークスペースにインポート（表示）されないことがあります。
また、もしインポートされなかった場合、CubeIDEを開いた状態にしてエクスプローラで.projectをダブルクリックするときれいにインポートされます。
・.cproject
C/C++の設定ファイル（？）。プロジェクトの「プロパティ」にて設定した項目の一部はここに保存されてるようです。
-u_printf_float（printfのfloat表示）の設定が保存されていることを観測してます。

未確認

・*.ld
このファイル何か知らないので勉強します。

リポジトリの作り方と注意

お勧めはワークスペース丸ごとではなくて、その中のプロジェクトごとにリポジトリを作ることです。

問題はリモートにあるリポジトリをクローンするときですが、プロジェクトフォルダ名と.iocの名前を一致させる必要があるので、
リモートリポジトリ名によってはクローンのローカルパスの最後を修正する必要があります。

相互リンク(随時更新@2020/03/09)

【手抜き】STM32の使い方まとめ
（まだない記事は今後変更の可能性があります）

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-03-15T15:50:01+09:00

npmパッケージ公開の手順

プログラミング歴半年の素人が書いています。

間違いのないようご自身でも良く調べた上でお願いいたします。

以下の記事を参考にさせていただきました。
https://qiita.com/TsutomuNakamura/items/f943e0490d509f128ae2

npmにサインアップ

まずはnpmの公式サイトから、会員登録しましょう。

https://www.npmjs.com/

npm ユーザの作成

ターミナルからユーザー情報を登録します。

$ npm set init.author.name "Ai Uehara"
$ npm set init.author.email "ai-uehara@example.com"
$ npm set init.author.url "http://qiita.com/aiuehara"
$ npm adduser  # 会員登録情報の入力

npmパッケージの作成

npm initを実行するとpackage.jsonファイルが作成され、npmパッケージとしてディレクトリを管理することができるようになります。

$ npm init

npmパッケージに必要なプログラムを記述する

以下のようなファイル構成になります。
index.jsとpackage.jsonが必須。
その他に必要なファイルがあればもちろん追加してOK。

作業ディレクトリ/
  +-- index.js
  +-- package.json
  +-- test/
    +-- test-index.js

ライブラリの追加

自分のnpmパッケージに必要なライブラリをインストールするときは、以下のコマンドを使用することで、自動的にpackage,jsonに依存関係の記述が追加される。

$ npm i --save パッケージ名

開発環境のみで使用するライブラリの追加

テストなど開発環境のみで使用するパッケージは、以下のコマンドを使用する

$ npm i --save-dev パッケージ名

ライセンスファイルの作成

公開するnpmパッケージのライセンスについて、明記しておきます。
誰でも自由に使用できるライセンス（MIT）として公開することが一般的です。

LICENSE.txtファイルを作成し、The MIT Licenseから丸々コピーします。

Copyright <YEAR> <COPYRIGHT HOLDER>の部分を、書き換えて保存します。

npmに公開

$ git add -A
$ git commit -m "first commit"
$ git tag -a v1.0.0 -m "My first version v1.0.0"
$ git push origin tags/v1.0.0
$ npm publish ./

バージョンアップするとき

一度npmに公開したパッケージをパージョンアップさせる時には、バージョン情報も合わせて更新する必要があります。

パッチ バージョンアップ

$ npm version patch              # <- v1.0.0 からv1.0.1 にアップ
v1.0.1
$ git tag                        # <- git のtag も自動的に作成される
v1.0.0
v1.0.1
$ git push origin tags/v1.0.1    # <- ただし、git push まではやってくれないので、必要に応じて自分でgit push ...
$ npm publish ./                 # <- npm で公開

マイナーバージョンアップ、メジャーバージョンアップ

$ npm version minor    # v1.0.1 からv1.1.0 にアップ
v1.1.0

$ npm version major    # v1.0.1 からv2.0.0 にアップ
v2.0.0
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-03-15T15:05:21+09:00

[Git]Forkしたブランチを最新にする方法

はじめに

リポジトリをフォークするとフォークを同期する
を参考にして書いています！:sunny:

方法

:sunny:upstreamに本家のリモートを登録

$ git remote add upstream https://github.com/cakephp/docs.git

※https://github.com/cakephp/docs.gitはFork元のURLに変更してください。

※含まれているかの確認は$ git remote -vのようにしてください。以下画像はサンプルです。

スクリーンショット 2020-03-15 14.50.52.png

:sunny:本家の内容を持ってくる。
:man_tone3:今回の元のブランチが私は4.xなのでupstream/4.xに入ってくるらしい、、、

$ git fetch upstream

:sunny:あとは自分の最新にしたいブランチのところで持ってきたものをマージする。今回は4.xの部分で以下コマンドを打った感じです！

$ git merge upstream/4.x

※4.xのところは人それぞれです。

スクリーンショット 2020-03-15 15.04.07.png

なんとなくいらない部分隠してみました！

最後に

終わりです！

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

git初心者はこれだけ知っていればOKコマンド一覧

初めてgitを触る仕事する場合や、普通に自分で使いたい人など、git初心者の方が、「これだけ知っていればOK」というコマンド一覧です。

clone

リポジトリからファイル・フォルダを持ってくるコマンドです。

$ git clone git@リポジトリのURL/リポジトリ名.git

例

$ git clone git@github.com:rails/rails.git

init

ローカルリポジトリを作成します。

$ git init

git cloneしてプロジェクトを持ってきた場合には必要ありません。

add

ワーキングツリーのファイルをインデックスに登録します。

$ git add README.txt

また、変更したすべてのファイルを登録する際は

$ git add .

でいけます。

commit

addでインデックスに登録したファイルをローカルリポジトリに持ってきます。

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

push

ローカルリポジトリをリモートリポジトリに渡します。

$ git push リポジトリ名 ブランチ名

マスターブランチにpushする際は

$ git push origin master

とします。originというのはデフォルトのリポジトリのことです。
しかし、マスターに直接pushすることは基本的にないと思います。

$ git push origin feature

pull

リモートリポジトリをローカルリポジトリに持ってきてファイルのバージョンを上げます。

$ git pull origin ブランチ名

status

ローカルリポジトリのファイルの変更状態を確認します。

$ git status

branch

ブランチを作成・確認します。

$ git branch 作成するブランチ名

これでブランチを作成します。また、

$ git branch
* feature
  master

とすると、現在存在するローカルリポジトリのブランチが一覧で表示され、現在捜査しているブランチに「*」がつけられています。

checkout

ブランチを移動したりブランチの変更を取り消したりできます。

$ git checkout ブランチ名

また、存在しないブランチを作成して移動するときは

$ git checkout -b ブランチ名

と「-b」オプションを付けます。
これは

$ git branch ブランチ名
$ git checkout ブランチ名

と同じです。

これくらい知っておけばなんとかなると思います。

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

GitレポジトリをSubversionレポジトリにミラーリングする（Git Server-Side Hook編）

やりたいこと

gitレポジトリをsubversionレポジトリにミラーリングする。

git user -> git server -> svn server -> svn user

ポイントはgit serverとsvn serverのつなぎ。

さてどうしたものか。。。

とりあえず勉強だ！

Git Server-Side Hook（調査）

https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks#Server-Side-Hooks

Gitのサーバーサイドフックは以下の3種類がある。

  • pre-receive
    • Pushリクエストをクライアントから受け付けた時に発動する（まだPushは完了していない）。pre-receiveはPushリクエスト一つにつき一度しか発動しない。non-zeroを返せば、失敗となり、Pushの処理は中止される。0を返せば成功し、Pushの処理は継続される。
  • update
    • 発動タイミングや成功・失敗はpre-receiveと同様。updateはブランチごとに発動する（Pushリクエストに含まれるコミットがそれぞれ異なるブランチのコミットとなっているような場合）。
  • post-receive
    • Pushの処理完了後に発動する。

GitLabでサーバーサイドフックを使う場合には、以下を参照。

https://docs.gitlab.com/ce/administration/server_hooks.html#server-hooks-core-only

For Omnibus installs the path is usually /var/opt/gitlab/git-data/repositories/<group>/<project>.git.

とあるが、わたしの環境ではrepositoriesの下はHash値になっている。

GitLabのAdmin Area>Projects以下にプロジェクト毎のページがあり、Gitaly relative path:という項目を参照すればプロジェクトのHash値がわかる。

Git Server-Side Hook（作成）

私はDockerを使ってGitLabサーバーを構築している。まずはサーバーにログインする。（gitlabという名前のGitLabサーバーインスタンスの想定）

% docker exec -it gitlab /bin/bash

フックを作成する。

# cd /var/opt/gitlab/git-data/repositories/@hashed/<group>/<project>.git/
# mkdir custom_hooks
# cd custom_hooks
# touch pre-receive update post-receive
# chmod +x pre-receive update post-receive

pre-receiveフックに以下の内容を記載してクライアントからサーバーへPushしてみる。Pushに失敗することを確認する。

#/bin/bash
exit 1
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-03-15T07:24:24+09:00

GitレポジトリをSubversionレポジトリにミラーリングする（実験環境編）

やりたいこと

gitレポジトリをsubversionレポジトリにミラーリングする

git user -> git server -> svn server -> svn user

準備

  • GitLab
  • Redmine&Subversion

セットアップ

docker composeを使うと、、、あら楽ちん。このまま本番環境には持っていけませんが、実験するには十分です。

インスタンスを立ち上げたら、RedmineとGitLabそれぞれでユーザーやレポジトリを設定します。

version: '3.7'

services:
    redmine:
        container_name: redmine
        image: redmine
        restart: always
        networks:
            - mynetwork
        ports:
            - 80:3000
        volumes:
            - ./data/plugins:/usr/src/redmine/plugins
            - ./data/themes:/usr/src/redmine/public/themes
            - ./data/svn:/srv/svn
        environment:
            REDMINE_DB_MYSQL: redmine-db
            REDMINE_DB_PASSWORD: redmine

    remine-db:
        container_name: redmine-db
        image: mariadb
        restart: always
        environment:
            MYSQL_ROOT_PASSWORD: redmine
            MYSQL_DATABASE: redmine
        networks:
            - mynetwork
        volumes:
            - ./data/db:/var/lib/mysql
        command: mysqld --character-set-server=utf8 --collation-server=utf8_unicode_ci

    gitlab:
        container_name: gitlab
        image: 'gitlab/gitlab-ce:latest'
        restart: always
        environment:
            GITLAB_OMNIBUS_CONFIG: |
                gitlab_rails['gitlab_shell_ssh_port'] = 2224
        networks:
            - mynetwork
        ports:
            - '8929:80'
            - '2224:22'
        volumes:
            - ./gitlab/config:/etc/gitlab
            - ./gitlab/logs:/var/log/gitlab
            - ./gitlab/data:/var/opt/gitlab

    subversion:
        container_name: svn
        image: 'kuchida1981/subversion-httpd'
        restart: always
        environment:
            SVN_DEFAULT_USER: admin
            SVN_DEFAULT_USER_PASSWD: admin
        networks:
            - mynetwork
        ports:
            - 10080:80
        volumes:
            - ./svn:/var/svn/repos

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

日付別

タグ一覧