~/.zshrcに、1行追加するだけ。

~/.zshrc

function gm() { git commit -m "$*" }

以上。

使用方法

追加/反映してくれるコマンドをターミナルに打ち込む。

echo 'function gm() { git commit -m "$*" }' >> ~/.zshrc
source ~/.zshrc
(Gitリポジトリに移動、適宜編集、git addする。)
gm feat: commit msg

追加情報

公式ドキュメント/参考文献

http://zsh.sourceforge.net/Intro/intro_4.html
https://linuxjm.osdn.jp/html/GNU_bash/man1/bash.1.html

実行環境

MacBook Air (M1, 2020) 11.2.2（20D80)
zsh 5.8 (x86_64-apple-darwin20.0)

その他

1. 誤り/提案等がありましたら、ぜひコメント等頂けますと嬉しいです。
2. gm 部分は関数名=呼び出す際に打つコマンドとなりますので、お好みでご変更ください。

GitHub上でブランチを削除しても、「git fetch」や「git pull」では更新されても、ローカル上のリモートブランチ情報は削除されず、残ったままになります。Git環境を綺麗に保つために必要なコマンドを自己流でまとめました。

【準備】まずローカルブランチの確認

git branch

削除するブランチ名を確認しておきます。
このとき、対象がカレントブランチ(現在のブランチ)になっていると削除ができないので移動をします。

ブランチの移動

git checkout master

このとき移動するブランチは何でも良いです。

ローカルのGit環境でブランチを削除する

git branch -d feature/xxxxxx
git branch -D feature/xxxxxx

これでローカルのブランチは削除ができます。
もしmergeしていなかった場合は、警告が出るので下の「-D」オプションを付けて強制削除ができます。

ローカルにあるリモートブランチを確認する

git branch -a

このコマンド叩くと、リモートに「origin/feature/xxxxxx」がまだ残っていることに気付きます。

【本編】ローカルに残ったリモートブランチを削除する

git fetch --prune
git pull --prune

上記のどちらかのコマンドに「--prune」オプションを付けることでローカルに残ったリモートブランチ情報を削除することができます。

ローカルのリモートブランチが削除されていることを確認する。

git branch -a

再度、上記コマンドを叩いてローカルのリモートブランチが削除されていることを確認します。
何故こんなことをするのかというと、開発が進むにつれて過去と同名のブランチ名を付けてしまったり、プレフィックス(接頭辞)が同じブランチを作成しようとした際に、エラーに遭遇することを避けるためです。

参考文献

• いちばんやさしいGit&GitHuBの教本(著 横田紋奈、宇賀神みずき)
• GitHub実践入門(著 大塚弘記)
• 独習Git(著 Rick Umali)
  

Git&GitHubに関して色々、読んだのですが「--prune」オプションについてはあまり言及されていませんでした。やはり公式のリファレンスを読むことが遠回りに見えて近道だと感じました。

こんにちは、まゆみです。

今回の記事では、Gitで使うbranch について書いていきます。

branch = 枝

という言葉が示している通りbranchとは

今取り組んでいるプロジェクト(メインブランチ)から枝分かれさせ、新しい枝を作ることができる機能です。

その枝分かれさせたbranchのコードが上手く実行されるかどうか？を確かめて全てが上手くいくと分かった後、メインのプロジェクトに戻すことができます

イラストにすると下記のようになります

枝分かれさせたbranch は

• メインのbranch と同時に並行してコードを書き換えることができるし
• 書き換えたあとのコードを試してからメインのbranch と一緒にする(merge)ことができます

ではさっそくbranch の使い方を見ていきましょう

branchの使い方

branch を作ってみる

コマンドラインに

git branch 好きなbranch名

と入力すると、メインのbranch から枝分かれした新しいbranch を作ることができます

次に

git branch 

とコマンドラインに入力すると、今自分が

メインのbranch にいるのか？

または新たに作ったサブのbranch にいるのか？

を確かめることができます

今回、例としてseparate-file というbranch をメインとは別に作ってみました。

git branch で確かめると、master の前に＊がついているのが確認できると思います

これは、今あなたはまだメインのbranchで作業をしているということを示しています。

新たなbranchに移動する

今、あなたはメインのbranchの方にいるので新たなbranch の方に移動しましょう

git checkout 新たなbranch名

エンターキーを押した後、コマンドラインに

『Switched to branch "branch名"』と表示されれば、OKです。

実験してみよう

コマンドラインに『git checkout (branch名)』とうつと、メインのbranch とサブで作ったbranch を行き来できることが分かりました。

では、サブで作ったbranchの中にあるファイルを開いて、ファイルの中のコードやテキストを変えてみましょう。

そして『git checkout master』でメインのbranchに戻りファイルを開いてみてください。

以前のままファイルの内容は変わっていないはずです。

サブのbranchで書き換えた内容が気に入った！

サブのbranchで書き換えたコードが上手く実行された！

ではそれをメインのbranchと一緒にしたいですよね。

①コマンドラインに『git checkout master』と打ち込みメインのbranchにスイッチさせる

②『git merge　(メインbranchと一緒にしたいサブbranch 名)』とコマンドラインに打ち込み、サブのbranchをメインのbranchと一緒にする

merge が成功すると下記のように表示されます。(ちなみに私はWindows を使っています)

※merge が終わったあとも、サブのbranch は消えません。

GitHubにアップロードする

書き換えたファイルをGitHubにアップロードしましょう

git push origin master -u

(GitHubへのアップロードがいまいち分からない人はこちらの記事を参考にしてください。)

まとめ

今回は、他の人とコラボする時などにも役に立つ『branch・merge』について解説させていただきました。

お役に立てれば幸いです。<(_ _)>

はじめに

docker buildkit sshを試してみました。

ファイル

aaa/main.py

# pri_pjはprivateのライブラリ
from pri_pj import hello

print("start")
print(hello("aa"))

mainファイルではプライベートなGitHubリポジトリにあるライブラリ pri_pj の hello 関数を使うだけの簡単なpythonファイルです。

pyproject.toml

[tool.poetry]
name = "aaa"
version = "0.1.0"
description = ""
authors = ["va034600"]

[tool.poetry.dependencies]
python = "3.6.*"
# プライベートなGitHubリポジトリ
pri_pj = { git = "ssh://git@github.com/va034600/pri_pj.git" }

[tool.poetry.dev-dependencies]

[build-system]
requires = ["poetry>=0.12"]
build-backend = "poetry.masonry.api"

poetryを使ってプライベートなGitHubリポジトリにあるライブラリを使う設定をしています。

Dockerfile

FROM python:3.6.8

WORKDIR /usr/src/app

ENV POETRY_VERSION=1.0.10 \
    PATH="/root/.poetry/bin:$PATH"

RUN curl -sSL https://raw.githubusercontent.com/sdispater/poetry/${POETRY_VERSION}/get-poetry.py | python && \
    poetry config virtualenvs.create false

COPY ./pyproject.toml /usr/src/app/pyproject.toml

RUN mkdir -m 700 $HOME/.ssh
RUN ssh-keyscan github.com > $HOME/.ssh/known_hosts
RUN --mount=type=ssh poetry install

CMD tail -f /dev/null

Dockerfile では poetry install をしています。
RUN --mount=type=ssh poetry install
poetry install する際に --mount=type=ssh をつけることでprivateなリポジトリを参照することができます。

docker buildを実行

準備は整ったのでこれでbuildできるかと思います。

$ DOCKER_BUILDKIT=1 docker build -f docker/Dockerfile -t aaa --ssh default .

docker-composeを実行

docker-composeを直接 buildkitを使ってsshアクセスするやり方が見当たらなかったので、
仕方なく、docker build で作成したイメージをdocker-composeで使うことにしました。

docker-compose.yml

version: '3.5'
services:
  abc:
    image: aaa
    working_dir: /usr/src/app/aaa
    command: python main.py
    volumes:
      - ../aaa:/usr/src/app/aaa

$ docker-compose up

終わりに

以前、Dockerfileからprivateなリポジトリにアクセスするイメージを作った際には、ssh keyをDockerイメージに埋めましたが、これはimageの中にssh keyが残るアンチパターンだった様です。
docker-compose上でbuildkit sshがまだ実現出来なかったのが気になりますが、これで開発する上でdockerイメージにprivateなライブラリを埋め込むことが出来そうです。

参考

• https://www.slideshare.net/AkihiroSuda/docker-125002128
• https://qiita.com/shizuma/items/ab185db88f3ea1c037ce

こんにちは、まゆみです。

今回の記事では、

• .gitignore を使う時とは？
• .gitignore　の使い方

について書いていきます。

イラストやスクショも使いながら、誰にでもわかるように説明しますね。

gitignoreを使う時とは？

例えば、Project folder のなかに、GitやGitHubにアップロードしたいファイルに混ざって、『APIキー』など他人には知られたくないことが書かれたsecret.txtファイルがあるとします。

もしくはセッティングのファイルなどもアップロードしたくないですよね。

そのような時に使うのが『gitignore』です。

gitignoreを実際に使う

ではさっそくgitignoreを使っていきましょう

gitignore ファイルを作る

コマンドラインに

touch .gitignore

と入力してgitignore ファイルを作ります

gitignoreファイルは、隠しファイルなのでコマンドラインに『ls』(list) と入力しても表示されませんが、『ls -a』と入力する事で、隠しファイルも表示させることができます。

下記のようになります

もちろん.gitignore ファイルには今の時点では何も書かれていません。

なので今の時点で、『git add .』をコマンドラインに入力すると全てのファイルがStaging Area に入ってしまいます。(Staging Area の意味が分からない人はこちらの記事で説明しています。)

.gitignoreファイルに無視したいファイルを書く

.gitignore ファイルを開き Local Repositoryにアップロードしたくないファイル名を書きましょう

上記の様に書けばOKです。

(もし、『.txt』の拡張子のついたファイルを全て無視したい場合は.gitignore ファイルに　『*.txt』と書きます。)

コマンドラインでディレクトリ内の全てのファイルをStaging Area にアップロード

『git add .』でディレクトリ内にある全てのファイルをStaging Area にアップロードします。

でも、その前に.gitignore ファイルに無視したいファイル名は書いているので、『.git add .』で全てのファイルを指定しているにも関わらず、secret.txt ファイルは無視されてアップロードされます。

commitしましょう

ここまでくれば後は、普段通り

①Staging Area にあるファイルを

②commit してLocal Repositoryにアップロードする

まとめ

.gitignore ってすごく便利ですよね。

.gitignore ファイルを作る時には、必ず一番前に『. ドット』を忘れないようにお願いします！

では今回の記事はこれで終わりにします。

今回は、私が共同開発を経験し、開発前に知っていると開発がもっとスムーズだったなと思うことを５つにし記述していきたいと思います！

読むのをオススメする人

・共同開発をこれから始める人
・実務に初めて入る人

共同開発前に知っておかないと損すること5選

考え方

1. 抽象と具体

コミュニケーション

2. 進捗確認

3. メンバーとのコミュニケーション

技術面

4. 検索能力

5. Git・GitHubの使用方法

これらの５つです。

では一つ一つ説明をしていきます！

考え方：抽象と具体

これすごく大事です！！

抽象とは、解釈の自由度が高く・応用が効く
具体とは、解釈の自由度が低い・応用が効かない
ものです。

これを聞くと、どういう意味？？？

となると思いますので、今から抽象と具体について分けて説明していきます！

抽象とは

抽象とは、「いくつかの共通の事柄を一括りにしたもの」と考えてください

例：掃除
あるパーティの後、片付けをしないといけない時に支配人に
「テーブルにあるコップをゴミ箱に床に、落ちているゴミをゴミ箱に入れて、床をホウキではいてください」と言われると聞いていてとても煩わしくありませんか？

普通に掃除してというとすむ話なのにと

これこそが抽象です！

抽象を使うことによりお互いがある状況・知識を知っているととてもコミュニケーションが円滑に進める事ができます！

それに加えて思考がとてもシンプルに整理する事ができるというメリットつきです！

開発でわからないものがある時に要はこれは何と何を使って機能を実装するのかがわかると後で出てくる検索力が格段に上がります！

しかし、抽象概念だけを極めたとしてもそれだけでは、相手に何か質問をする時などに解釈の相違が出てきてしまいます！
その時に大事になってくるのが具体的な考え方です！

具体とは

具体とは、先ほどの抽象と逆の考え方で細かく細分化していく考え方になります！

私を例に出してみると
人間→男→Daichi
このDaichiというのが具体的な考え方ということになります!

具体的な考え方がなぜ必要なのか？？
それは質問をする時・何か機能を実装する時に必要になるからです！

プログラミング初学者は、必ずエラーに悩まされます←これは絶対です！

しかし、最初の方は何でエラーが起きているか全くわかりませんその時に誰かに相談する時大体Slackなどのアプリで文字ベースで質問になると思います！

質問内容が
「エラーが出てきてわかりません」
では質問された方も何の原因でエラーが起きているかがわかりません

その時に具体的に説明ができると回答者も回答がしやすくなります！

オススメの質問方法
1. エラーが起きた時点の状況←できるだけ詳細に書く
2. エラーのメッセージの画像とエラーメッセージのコードを貼り付ける←コピーができる様に
3. 何を試したか
4. そこまでに至ったかを書く←自分の理解度を深めるためにも良い

具体の考え方ができるととても質問がやりやすくなります！

これはどんな時にも言えます！
状況：算数の５＋５がわからない時の質問
A「算数がわからないです！」
B「算数の何がわからないの？？」
A「足算！！」
B「足算のどの問題がわからないの？？」
A「５＋５がわからない！！(何でわかってくれないの)」
B(初めからそう言ってくれれば良いのに)
↑
この様な状態が起きるのを避けるためにも具体的に状況を説明できる様にすると良いです！

なぜ抽象と具体を分ける必要があるのか

まとめると、
何か機能を作る時に
検索なら検索・いいね機能ならいいね機能とその機能を作るためのおおよそ作り方は検索するとわかりますが、検索機能であればそのまま自分の開発に貼り付けてうまく動きません個別により使うカラムとかが違うからです！

なので、何か機能を実装したいときは、どの様に作られているかの大枠を検索で学び、自分の機能には、それをどの様に使っていくかを考えていくのが大事になります！

なので、抽象的な考えだけでもダメですし、具体的な考えができるだけでもダメと言うことになります。

オススメ書籍:具体抽象トレーニング

コミュニケーション:進捗確認

ここからはコミュニケーションについて書いていきます！

プログラム書いていくだけなのにコミュニケーションと思った方もいるかもしれませんが、これはとても大事なことです！！

なぜなら、
プログラミング書いているのは、人だからです！

結局、
個人で作れるアプリには限界があります。
会社単位になるとみんなで一つのもの作るのにしっかりコミュニケーションを取らないと次の機能実装がやりにくいなどがあるからです。

進捗確認することは相手を安心させるのにもつながります！

そのためにオススメのアプリは、Trelloです！！

これは、ほとんどの方が使っていると思うのですが、軽く説明をすると
タスクごとにカードを作り
完成までの日にち・誰が作成中か・進捗報告もできる
優れものです。

僕も共同開発中は、とても使わせていただきました！！

メンバーとのコミュニケーション

これは、今どんなエラーで悩んでいるか・どこまで進んだかの共有するということです！

なぜ必要か？？
共同開発で大切なことは悩みの共有です！

正直、共同開発をしていると自分の知らないエラーが必ず出てきます。
その時に一緒に考える事ができるメンバーがいるのは、とても助けになります！

僕自身それで何度も救われてきました！

自分が知らなくても相手ならその問題を知っている事が多々ありますその逆に相手が知らないことを自分が知っている場合があります！

この様に悩みを共有することによりより効率的に作業を進める事ができます！

自分がわからないエラーが出た際には
相手は、アウトプットになるために勉強になるし、自分は相手になるべくわかりやすく質問をしないといけません。
お互いにメリットがあります！！

さらにプログラミングを書いていると1人の時間が多く投げ出してしまいたくなる時もメンバーとコミュニケーションをとっているとメンバーも頑張ってるし自分も頑張らなければという感情になります！

やる気も大事ですが、そのやる気を維持させるための環境づくりも同じくらい大事になってきます！

技術：検索能力

これは1番大事と言っても過言ではないと思います！

プログラミングで全ての機能を覚える事は不可能です！！

なので、基礎概念などをしっかりと覚えると後は、いろんな機能の実装の度に自分でわからないことを調べそれを自分の実装したい機能の時にはどの様に応用するかを考えないといけません！

その際にも必要になってくるのが、抽象と具体です！

調べる際に自分の機能の具体的な内容を書き綴ってもあなたの機能にそのまま使える物はありません！

なので、まず何がわからないか細分化する必要があります！

カレーを作りたい時は、カレーの作り方を調べてその後に必要な食材を一つずつ列挙していく様に

プログラミングの機能実装も実装したい機能を検索しそれに必要なことを一つづつ調べていく

必要があります！

疑問に思った時に使える検索エンジン・サイト：

• Google
  検索をする際は、Googleでほとんど全てを網羅できます！


• Udemy(有料)
  動画で学ぶ事ができとても内容が濃いいです！
  教材購入時期は、月に何度かくるセールの時がお得！！


• GitHub
  わからない事があれば他の人がすでに作った機能のコードを読み参考にする事ができます！


• Qiita(無料)
  まさに今僕が書いているサイトです！
  いろんな人が自分の経験・知見などを書いてくれています!

上記のものをしっかりと使いこなす事ができかつそれを自身の問題に応用ができる様になるとどんなことでも解決できるはずです！

Git・GitHubの使用方法

これまでは、個人でやってたからGitHubなんて使ったことないという人もいると思いますが、共同開発では必ず必要になってきます！

実際にGit・GitHubの使ったことありますかという質問は就職の面接でも聞かれるくらい大事です！

Git・GitHubとは何なのか？？

バージョン管理システムです！

どう言うこととなると思いますが、セーブ機能と考えてくれていると良いです！

これらを使うことによりいつでも戻りたい地点に戻ったり・エラーを確認したのちに新しく機能を実装できる様になります！

例えば、
アプリをリリースした際に他に追加機能を実装したい場合アプリをリリースしたファイルをそのまま編集をしていくと実装しきるまでそのアプリは、使えなくなる可能性があります！
さらに、追加機能をしている途中でファイルがぐちゃぐちゃになった際に前の状態に戻りたい時に一つ一つ戻すのは面倒ですし、大規模になるとどこを変更したかわからなくなり戻せなくなる可能性があります！

それを回避できるのがGit・GitHubです！
一つのタスクができるととりあえずセーブをしておき他のタスクに取り掛かる事ができます！
これをコミット・ブランチをきると言います

さらに、今やっているタスクがうまくいかなく前の状態に戻り作りたい際に前のセーブポイントに戻り再度作り直す事ができます！
これをチェックアウトと言います！

今回は、詳しくは書きませんがこれらはとても共同開発をする際には必須になりますので、共同開発をする前は必ず触りだけでもやっておくことをオススメします！


オススメの教材：
Udemy無料(Git：初めてのGitとGitHub)
Udemy有料(Git： もう怖くないGit！チーム開発で必要なGitを完全マスター)


こちらの2つの講座は、僕も受けましたが本当にわかりやすくかつ本質的な内容でしたのですごくオススメです！！

終わりに

今回は、共同開発前に僕がしておけばよかったなと思ったこと５選について書かせていただきました！

言語の基礎能力をつけるなどは、最低限ある状態を想定して書いたので今回の記事には書いておりません！
これが少しでも誰かに役に立つ幸いです！

最後までお読みいただきありがとうございました！！

＊この記事は、アフィリエイトリンクは使っておりません

こんにちは

一月に未経験で入社しましたミツキです。
今回は会社の研修で触れたgit revertについて記事を書きます。

git revert とは

git revert は、元に戻すコマンドの一種である。ただし、通常の元に戻すコマンドとは異なり、コミットがなかったことにするのではなく、「コミットによって加えられた変更を打ち消し、その結果を含む新しいコミットを追加」します。これは Git の履歴を保全するためであり、バージョン履歴の完全性の維持とコラボレーションの信頼性の確保のために重要です。参考

仕組み

git revert を使用すると、リポジトリのコミット履歴への変更を元に戻すことができます。git checkoutやgit resetなどの元に戻すコマンドではHEADと、refポインターが、指定したコミットに移動します。git revertでも指定したコミットを取得することができますが、refポインターが指定したコミットに移動することはありません。打ち消しコミットでは、指定したコミットを取得し、取得したコミットの変更を打ち消して、新しい打ち消しコミットを作成します。その後、ref ポインターは新しい打消しコミットをポイントするよう更新され、ブランチにもその情報が伝わります。

コマンド

ノーマルコマンド

$ git revert <打ち消したいコミットID>

メッセージを編集したいとき

オプションをつけないrevertでは、「Revert + 元のコミットにつけたメッセージ」といったメッセージがついてしまいます。任意のメッセージをつけたいのなら「-e」オプションをつけましょう。

$ git revert -e <コミットID>

コミットメッセージを編集しない

$ git revert --no-edit <コミットID>

コミットする前までもどる

$git revert -n <コミットID>

実際の動き

一つ前のコミットをrevertする

$ git log -1
commit 6f32bfc693eaa14e19248b34d8b0becc1d68f4e5 (HEAD -> feature/dev_1)
Author: *********** <******.***@example.com>
Date:   Sun Mar 7 22:45:54 2021 +0900

    feature/dev_1 に変更を加えました

2.変更を加える前にrevertする

-------------------git revert-------------------------------------
$ git revert 6f32bfc693eaa14e19248b34d8b0becc1d68f4e5
[feature/dev_1 f7b2069] Revert "feature/dev_1 に変更を加えました"
 1 file changed, 1 insertion(+), 3 deletions(-)
-------------------git log-------------------------------------
$ git log -2
commit f7b20691fd1cda34cb598f8f2ce4df71b93a90d6 (HEAD -> feature/dev_1)
Author: *********** <******.***@example.com>
Date:   Sun Mar 7 22:49:43 2021 +0900

    Revert "feature/dev_1 に変更を加えました"

    This reverts commit 6f32bfc693eaa14e19248b34d8b0becc1d68f4e5.

commit 6f32bfc693eaa14e19248b34d8b0becc1d68f4e5
Author: *********** <******.***@example.com>
Date:   Sun Mar 7 22:45:54 2021 +0900

    feature/dev_1 に変更を加えました

結果

logをみると「Revert "feature/dev_1 に変更を加えました"」と記録されています。また、初めに変更を加えたコミットも残っています。
コミット自体を消去するのではなく、指定したコミットの「内容」を打ち消し、尚且つrevertしたこともコミットすることになります。

3つ前のコミットをrevertする

$ git revert 462c0330cd7d48b2e91e41549896263eda75fa8d
error: could not revert 462c033... 変更1
hint: after resolving the conflicts, mark the corrected paths
hint: with 'git add <paths>' or 'git rm <paths>'
hint: and commit the result with 'git commit'

コンフリクト発生

git statusで状況を確認してみる

$ git status
On branch feature/dev_1
Your branch is ahead of 'origin/feature/dev_1' by 7 commits.
  (use "git push" to publish your local commits)

You are currently reverting commit 462c033.
  (fix conflicts and run "git revert --continue")
  (use "git revert --abort" to cancel the revert operation)

Unmerged paths:
  (use "git reset HEAD <file>..." to unstage)
  (use "git add <file>..." to mark resolution)

        both modified:   src/index.html

no changes added to commit (use "git add" and/or "git commit -a")

あなたのブランチは、7回のコミットで「origin / feature / dev_1」よりも進んでいます。
（「git push」を使用してローカルコミットを公開します）
現在、コミット462c033を元に戻しています。
（競合を修正し、「git revert --continue」を実行します）
（「git revert --abort」を使用して、元に戻す操作をキャンセルします）
マージされていないパス：
（「gitreset HEAD ...」を使用してステージングを解除します）
（「git add ...」を使用して解決をマークします）
両方とも変更：src / index.html
コミットに変更が追加されていません（「git add」および/または「git commit-a」を使用）

いくつか前のコミットをrevertした時、更新と削除どちらかを選ぶ必要があるっぽいです。（特定の変更のみをなしにすることはできない）
なので、「何回か追加の処理を加えてしまったけどn個前のコミットだけいらないなー」といった時は手動でコンフリクトを解消するほうが安全なのかな？?

現場がSVNリポジトリを使用していたので、ブランチで分けて開発をすすめて行きたかったのと
その後結局gitリポジトリに移行することになったので、この方法でリポジトリ移行をしました。

git-svnを使って、SVNリポジトリにあるコミットログごとごっそりgitリポジトリに移行しましたので備忘録です。
(コマンドとTortoiseGit使用)

※コミットログやデータ自体が多い場合は１０個ずつなどで分割しながらじゃないとエラーになってしまいますので注意です。

参考サイト：
https://www.karumado.com/2018/09/git-svnsubversiongit.html
https://qiita.com/toshikiw/items/56c57d12566cffa9e3fe

１．git-svnでSVNリポジトリをclone

２．ブランチの確認

git branch -a

３．予め用意しておいたgitのリモートリポジトリをリモート設定に追加(add)

git remote add origin [リポジトリURL]

４．gitのリモートリポジトリのほうにpush

git push -u origin --all

５．SVNで管理できてた空のディレクトリをgitでも管理する

→https://improve.backlog.jp/wiki/DEVELOPE/git%E3%81%A7%E7%A9%BA%E3%81%AE%E3%83%87%E3%82%A3%E3%83%AC%E3%82%AF%E3%83%88%E3%83%AA%E3%82%92%E7%AE%A1%E7%90%86%E3%81%97%E3%81%9F%E3%81%84%E3%81%A8%E3%81%8D

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
ここからさきは、間違えてSVN側にコミットしちゃわないようにSVNの設定を削除しておく方法

６．SVNの設定ファイルやgit-svnの設定ファイルを消す

・今のブランチがmasterであることを確認

・必要なSVNのブランチはgitのブランチとして作り直しておく

・ローカルのgit-svnブランチの削除
git branch -D [ブランチ名]

・リモートのsit-svnブランチの削除
設定ファイルからこの部分をまるごと削除

[svn-remote "svn"]
        url = <svnレポジトリurl>
        fetch = trunk:refs/remotes/trunk
        branches = branches/*:refs/remotes/*
        tags = tags/*:refs/remotes/tags/*

・リモートリポジトリ側からも削除
バックログの場合はブランチタブから削除可能
コマンドの場合は
git branch -r -d remotes/[trunk, tagsとか]

・ガベージコレクトする
git gc

・metadata削除
rm -rf .git/svn
rm -rf .svn

おまけ　gitkeepのはなし

参考：
https://blog.fukata.org/archives/6577
http://note.mokuzine.net/git-gitkeep/

gitは空のディレクトリはバージョン管理できない仕組みになっているので、
空のディレクトリには「.gitkeep」というファイルをおいて、それを管理することでバージョン管理対象にします。
ex)logディレクトリ

空のディレクトリの場合には.gitkeepを作成するシェル
for d in $(find [対象のディレクトリ] -type d -empty); do touch "$d/.gitkeep"; done

■ディレクトリは管理したいけど、その中のファイルまでは管理したくない場合
ex) logディレクトリは管理しておきたいけど、中のログファイルは管理したくない

.gitignoreファイル（バージョン管理を無視するファイルの設定ファイル）を下記の様に編集（なければ作成）

path/to/*
!.gitkeep

※無視ファイルの追加はGUIでも可能