初投稿です。
お手柔らかにお願いします。

経緯

masterをデフォルトブランチとして開発を進めていたが、Githubページを見ると、
mainという名のブランチが、リポジトリ作成時から手つかずの状態で残っているのを発見。

そういえば差別表現云々で、masterからmainに名称変更になった話があったなあと今更ながらに思い出しました。

リモートリポジトリにmasterとmainが両方残っているのも気持ち悪いので、mainのみに変更しようと思い立ちました。

結論

今回のケースでは、リモートリポジトリのmasterとmainは全くの別物(共通の祖先がない)なので、
--allow-unrelated-historiesオプションを付けてマージすれば万事解決です。

実際の流れ

当方初心者につき、上記の結論に至るまでに紆余曲折ありました。
せっかくなので、備忘録も兼ねて、解決までに実際にやったことを残しておきます。

(0)
Railsチュートリアルを進めていたところ、Github上に謎のmainブランチを発見。
これがリポジトリ作成時にできたデフォルトブランチであったことに気付く。

【登場人物】
master：ローカルではこいつをデフォルトとして開発していた。
origin/master：リモートではこいつをデフォルトのつもりで開発していた。内容はローカルのmasterと同じ。
origin/main：リポジトリ作成に生成されていた本当のデフォルトブランチ。内容は.gitignoreとReadme.mdのみ。

(1)
以下の記事を参考に、ローカルのブランチ名をmainに変更。
参考URL：
https://qiita.com/masakinihirota/items/1a657674e609be112fc6

$ git branch -m master main

※この時点でローカル・リモート双方にmainブランチがあることになるが、
お互い全く関係のない、つまり共通の祖先がないブランチ同士の状態。

(2)
ローカルで変えたブランチをリモートへpush。

$ git push -u origin main

ところが、以下のエラー。

To https://github.com/shu-illy/xxxxxxx
 ! [rejected]        main -> main (non-fast-forward)
error: failed to push some refs to 'https://github.com/shu-illy/xxxxxxx'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

(3)
この時点ではエラー文の意味をほとんど理解できず。
「もしかしてHerokuでアプリが動いてるからあかんのか？」などと的外れな推測をして、
以下のコマンドでHeroku上でアプリを停止しようとする。

$ heroku ps
$ heroku ps:scale web=0

(4)
(2)と同じ試み。当然同じエラー。

(5)
何故かリモートのmasterを消してしまう。

$ git push origin :master

(6)
git pullを試して以下のエラー。

fatal: refusing to merge unrelated histories

このエラー文に重要なヒントがあるにも関わらず、あっさり見過ごす。

(7)
的外れ推測その2
「gitのバージョンがあかんのか？」

以下の通りgitを最新版にアップデート。

$ git --version
git version 2.24.3 (Apple Git-128)

$ brew install git

$ export PATH=/usr/local/Cellar/git/2.27.0/bin:$PATH

$ git --version
git version 2.30.0

(8)
(4)に同じ。

(9)
とりあえず今後のためにローカルリポジトリでのデフォルトブランチ名の設定をmainに変更した。

$ git config --global init.defaultBranch main

このあたりでようやく(1)※に気付く。
リモートのmainブランチに紐付けたローカルブランチを用意し、ローカルのmainをマージすれば良いと悟る。

ここで登場人物を一旦おさらいしましょう。

【登場人物】
main：最新の状態。こいつをorigin/mainにプッシュしたい。
master：mainに名前変更済。
origin/main：リポジトリ作成時から手付かず(.gitignoreとReadme.mdだけがある状態)。
origin/master：(5)で消されてしまった可哀想な人。

(10)
ローカルのブランチ名をmainからmasterに戻す。

$ git branch -m main master

(11)
origin/mainと紐付けるために、ローカルのmainを復活させる。

$ git checkout -b main

(12)
作成したmainブランチに、リモートのmainを強制上書きする。
参考URL：
http://www-creators.com/archives/1097

$ git fetch origin main
$ git reset --hard origin/main

(13)
mainブランチにmasterをマージ。
共通の祖先を持っていないブランチ同士のマージなので、以下のコマンド。
参考URL：
https://qiita.com/mei28/items/85bc881ac1f26332ac15

$ git merge --allow-unrelated-histories master

(14)
当然コンフリクトが起こるので手作業で解消。

(15)
コミット・プッシュして無事ローカル/リモートともにデフォルトのブランチ名がmainになりました。
めでたしめでたし。

$ git add .
$ git commit -m "Change default branch name"
$ git push origin main  

参考URL(再掲)

masterからmainに変更する（githubのリモート＆ローカルブランチ）:
https://qiita.com/masakinihirota/items/1a657674e609be112fc6

git pull を強制し、リモートでローカルを上書きする方法:
http://www-creators.com/archives/1097

[Git] fatal: refusing to merge unrelated histiesを解決する話:
https://qiita.com/mei28/items/85bc881ac1f26332ac15

GitHub APIのreleaseオブジェクトから、tagを取り出してtagに紐づくコミットハッシュを取得したい、という場面がありました。

releaseオブジェクトの中身は以下のような具合でコミットハッシュを持っていません（APIはこちらを参照）。

[
  {
    "url": "https://api.github.com/repos/octocat/Hello-World/releases/1",
    "html_url": "https://github.com/octocat/Hello-World/releases/v1.0.0",
    "assets_url": "https://api.github.com/repos/octocat/Hello-World/releases/1/assets",
    "upload_url": "https://uploads.github.com/repos/octocat/Hello-World/releases/1/assets{?name,label}",
    "tarball_url": "https://api.github.com/repos/octocat/Hello-World/tarball/v1.0.0",
    "zipball_url": "https://api.github.com/repos/octocat/Hello-World/zipball/v1.0.0",
    "id": 1,
    "node_id": "MDc6UmVsZWFzZTE=",
    "tag_name": "v1.0.0",
    "target_commitish": "master",
    "name": "v1.0.0",
    "body": "Description of the release",
    "draft": false,
    "prerelease": false,
    "created_at": "2013-02-27T19:35:32Z",
    "published_at": "2013-02-27T19:35:32Z",
    "author": {
      "login": "octocat",
      "id": 1,
      "node_id": "MDQ6VXNlcjE=",
      "avatar_url": "https://github.com/images/error/octocat_happy.gif",
      "gravatar_id": "",
      "url": "https://api.github.com/users/octocat",
      "html_url": "https://github.com/octocat",
      "followers_url": "https://api.github.com/users/octocat/followers",
      "following_url": "https://api.github.com/users/octocat/following{/other_user}",
      "gists_url": "https://api.github.com/users/octocat/gists{/gist_id}",
      "starred_url": "https://api.github.com/users/octocat/starred{/owner}{/repo}",
      "subscriptions_url": "https://api.github.com/users/octocat/subscriptions",
      "organizations_url": "https://api.github.com/users/octocat/orgs",
      "repos_url": "https://api.github.com/users/octocat/repos",
      "events_url": "https://api.github.com/users/octocat/events{/privacy}",
      "received_events_url": "https://api.github.com/users/octocat/received_events",
      "type": "User",
      "site_admin": false
    },
    "assets": [
      {
        "url": "https://api.github.com/repos/octocat/Hello-World/releases/assets/1",
        "browser_download_url": "https://github.com/octocat/Hello-World/releases/download/v1.0.0/example.zip",
        "id": 1,
        "node_id": "MDEyOlJlbGVhc2VBc3NldDE=",
        "name": "example.zip",
        "label": "short description",
        "state": "uploaded",
        "content_type": "application/zip",
        "size": 1024,
        "download_count": 42,
        "created_at": "2013-02-27T19:35:32Z",
        "updated_at": "2013-02-27T19:35:32Z",
        "uploader": {
          "login": "octocat",
          "id": 1,
          "node_id": "MDQ6VXNlcjE=",
          "avatar_url": "https://github.com/images/error/octocat_happy.gif",
          "gravatar_id": "",
          "url": "https://api.github.com/users/octocat",
          "html_url": "https://github.com/octocat",
          "followers_url": "https://api.github.com/users/octocat/followers",
          "following_url": "https://api.github.com/users/octocat/following{/other_user}",
          "gists_url": "https://api.github.com/users/octocat/gists{/gist_id}",
          "starred_url": "https://api.github.com/users/octocat/starred{/owner}{/repo}",
          "subscriptions_url": "https://api.github.com/users/octocat/subscriptions",
          "organizations_url": "https://api.github.com/users/octocat/orgs",
          "repos_url": "https://api.github.com/users/octocat/repos",
          "events_url": "https://api.github.com/users/octocat/events{/privacy}",
          "received_events_url": "https://api.github.com/users/octocat/received_events",
          "type": "User",
          "site_admin": false
        }
      }
    ]
  }
]

refを渡すとrefが指すコミットハッシュを解決して渡してくれるようなエンドポイントは探しましたが見つからず。しばらくGitHub APIを眺めて解決策を2つ見つけました。

1. list tagsのエンドポイントを叩いてtagの一覧からtag_nameで頑張って検索する
2. get a commitのエンドポイントを叩いてtagからコミットを取得する

tagは作成日などでソートされないので1の手法ではタグが増えると検索に時間がかかってしまいます。paginationを使ってループ作るなどの手間を考えると微妙です。ということで2番を試したところうまくできました。

Rubyだとoctokitを使って以下のようにしてコミットハッシュを取得することができます。

require 'octokit'
access_token = 'hoge'
client = Octokit::Client.new(access_token: access_token)

target_repository = 'YourOrg/yourrepo'
ref = "r20210105.1"
commit = client.commit(target_repository, ref)
p commit.sha

参考
https://github.com/octokit/octokit.rb/blob/d56af021d2/lib/octokit/client/commits.rb#L151

Gitコマンド

業務中によく使うコマンドをまとめてみました。

クローン

任意のフォルダ名(task1)配下にクローンする

git clone -b develop git@github.com:XXXX/YYYY.git ~/github/task1

ブランチの確認

git branch

ブランチの新規作成

git branch task1(ブランチ名)

ブランチの切り替え

git checkout task1(ブランチ名)

変更したファイルの状況確認

git status

指定したファイルの差分を表示

git diff ~/github/task1/lib/screens/XXXX.dart

変更内容をインデックスに追加する

git add  ~/github/task1/lib/screens/XXXX.dart

ローカルブランチにコミット

git commit -m 'コミット内容を記載'

リモートブランチtask1にプッシュ

git push -u origin task1

まとめ

よく使うコマンドだけど、よくわからなくなり毎回調べていたので忘れないように!!

WindowsでGit Bashを使う理由

Windowsであればコマンドプロンプトが標準で用意されているのでそれを使用する方法もありますが、Git BashはmacOSのターミナルとほとんど同じコマンドを実行できる（汎用性が高い）ため、推奨されています。

コマンドの書き方

コマンドの構成の各名称は以下のとおりです。

$ ls -a Documents

$：プロンプト（標準で入力されています）
ls：コマンド
-a：オプション
Documents：パラメーター
※オプション、パラメーターは省略されることがあります。
※空白は半角スペースです。

Gitの初期設定をするgit configコマンド

設定する理由

設定したユーザー名とメールアドレスがコミットした際に記録され、だれがコミットしたのかが明らかになります。

ユーザー名を設定する

git config --global user.name ユーザー名

Enterキーを押すと確定します。

メールアドレスを設定する

git config --global user.email メールアドレス

Enterキーを押すと確定します。

設定ができているか確認する

git config --list

色々と項目が出てきますが、user.nameやuser.emailで始まる部分が今回設定した部分になります。
また、このように表示結果が多いとき、一番下に「：」の表示が付きます。その場合、上下キーにて表示をスクロールすることができ、最終は「END」の表示がついています。
表示をやめるときは「Q」キーを押すとエスケープ（コマンドラインに戻ること）ができます。

Git初心者が理解を深める為にSourcetreeを導入したのでその時の作業の備忘録です。

環境

macOS バージョン10.15.17

Sourcetreeのインストール

公式よりダウンロード
https://www.sourcetreeapp.com/

ダウンロード後、インストールの際に「Appストアからのインストールではない」的なエラーを表示しますがmacの「設定→セキュリティとプライバシー→一般」下部の「ダウンロードしたアプリケーションの実行許可」よりエラーを回避してインストールできます。

インストール後

参考：
https://confluence.atlassian.com/get-started-with-sourcetree/get-started-with-sourcetree-847359026.html

公式の手順通りやってみました。

アカウント設定

「Sourcetree→環境設定→アカウント」より登録を行う

ホスト
リモートリポジトリを選択
認証タイプ
BasicとOAuthを選択可能
ユーザー名
「アカウントを接続」をクリックすると認証が走り表示されるようになる
プロトコル
HTTPSかSSHを選択可能、SSHを選択すると公開鍵をコピーできる

今回はGithub,OAth認証、HTTPSを選択して認証まで完了した様子だけど、ここから公式に記載の内容と様子が違ってきてしまいました。

アカウント設定後

アカウント設定が済んだら、本当なら下記のように表示されるようですが私の場合表示できず、空の状態でした。
もちろんリモートリポジトリにはファイルが存在します。なぜ、、

リモートリポジトリのファイルが表示されない理由を調査は後日、、

ローカルリポジトリの追加

これでローカルの方は追加できました

そうするとここに一応リモートリポジトリも表示されるように。

既存のリモートリポジトリはここから確認するのが良いのか。

最後に

一応これでSourcetreeを使用する準備は一通り整ったことになります。
あとは使ってみてどうなるか、使用時のTipsは別途まとめます。

はじめに

共同開発に取り組むようになり、git stashコマンドを使用するようになりました。
その使い方を個人的にまとめております。

内容

1. 「git stash」とは
2. 使用する理由
3. よく使うコマンド

1.git stashとは

• 作業中のファイルを.git/refs/stashへ移動させるコマンド
• 別のブランチに移動する前に使用する

2.使用する理由

なぜgit stashを使うのか？

→「作業途中のブランチ」から「別のブランチ」に切り替えるため

なぜ「別のブランチ」に切り替えるのか？

→別ブランチで行う作業があるから

別ブランチで行う作業とは？

基本的に共同開発を行っている時に使用するかと思います。
- プルリクをローカルでチェックする時
- プルリクを修正する時

なぜ作業途中でブランチを切り替えられないのか？

→ commitしていないファイルはマージされてしまうため

マージされないようにするには？

２つの方法があります。
①git commit でコミットファイルを作成する
②git stashでデータを避難させる

使う理由まとめ

• 別ブランチに移動したい
• 作業途中だとマージされる
• しかし,
• コミットできない！
• だからstashする

という流れで私はstashを使用しています。

3.コマンド

私がメインで使うコマンドは以下の通りです。

git stash list

stashしたファイルをみることができます

git stash list

git stash (save)

• stashでデータを避難させることができます。
• 避難したデータは.git/refs/stashに保存されます。
• saveは省略可

git stash (save)
git stash save "message" #=>　コメント付き

git stash pop

• stashしたデータを取り込みます。
• 取り込んだ後、データを削除します

git stash pop #=>最新のデータを１つ取り込む

git stash drop

• データを削除します

git stash drop #=>最新のデータを１つ削除

状況

Macに標準で入っているgitをHomebrewで管理するようにした後、brew searchコマンドを実行すると、画像のポップアップが出てきて、「拒否」のボタンしか押せない。

解決策

GitHubの公式ドキュメントに答えがありました。スポットライトでKeychain accessと打ってアクセスした後、github.comのinternet passwordを削除すればポップアップは表示されなくなり、コマンドも使えるようになりました。

原因

そもそもなぜこのようなポップアップが表示されたのでしょうか。これも先ほどの公式ページのリンクから引用させていただきます。

You should create a personal access token to use in place of a password with the command line or with the API. Personal access tokens (PATs) are an alternative to using passwords for authentication to GitHub when using the GitHub API or the command line.

要は、「パスワードを使ってAuthentificationする方法が廃止されるので、代わりにPATs(自分のリポジトリで発行したトークン)を使ってね。」ということになります。したがって、このパスワードを削除してしまって、コマンドを実行すれば（最初はユーザー名とパスワードが要求される）いいわけです。

余談

brewでgitをインストールした際には合わせてgit secretsもインストールしないとコマンド実行した際にエラーが出ます。このgit secretのよって、例えば「AWSの秘密鍵を誤ってコミットしてしまった」ということを防ぐことができます。ただし、インストールするだけでは有効にならないので、自分で設定する必要があります。設定方法については以下の記事が参考になりました。

git-secretsはじめました

状況

Macに標準で入っているgitをHomebrewで管理するようにした後、brew searchコマンドを実行すると、画像のポップアップが出てきて、「拒否」のボタンしか押せない。

解決策

GitHubの公式ドキュメントに答えがありました。スポットライトでKeychain accessと打ってアクセスした後、github.comのinternet passwordを削除すればポップアップは表示されなくなり、コマンドも使えるようになりました。

原因

そもそもなぜこのようなポップアップが表示されたのでしょうか。これも先ほどの公式ページのリンクから引用させていただきます。

You should create a personal access token to use in place of a password with the command line or with the API. Personal access tokens (PATs) are an alternative to using passwords for authentication to GitHub when using the GitHub API or the command line.

要は、「パスワードを使ってAuthentificationする方法が廃止されるので、代わりにPATs(自分のリポジトリで発行したトークン)を使ってね。」ということになります。したがって、このパスワードを削除してしまって、コマンドを実行すれば（最初はユーザー名とパスワードが要求される）いいわけです。

余談

brewでgitをインストールした際には合わせてgit secretsもインストールしないとコマンド実行した際にエラーが出ます。このgit secretのよって、例えば「AWSの秘密鍵を誤ってコミットしてしまった」ということを防ぐことができます。ただし、インストールするだけでは有効にならないので、自分で設定する必要があります。設定方法については以下の記事が参考になりました。

git-secretsはじめました

mainのブランチ

git pull

作成したブランチ

git merge 「メインブランチ」 

ここでコンフリクトが起きるので、コードを修正し解消する。

あとは通常通り、

git add .
git commit -m "コミットの名前"
git push origin "作成したブランチ"

これで解決しました！

引用先
Udemy もう怖くないGit!チーム開発で必要なGitを完全マスター
このコースではGitの裏側でどのような挙動でGitが動いているのかを図で詳しく解説しているので深く知りたい方は受講してみることをおすすめします。

プルリクエストとは

プルリクエストとは、自分の変更したコードをリポジトリの取り込んでもらえるよう依頼する機能。
バグを発生させないためにコードを他の人にレビューしてもらうためにプルリクエストがある。

プルリクエストの手順

① masterブランチを最新に更新
② ブランチを作成
③ ファイルを変更
④ 変更をコミット
⑤ GitHubへプッシュ
⑥ プルリクエストを送る
⑦ コードレビュー
⑧ プルリクエストをマージ

GitHub Flow

GitHub　Flowとは、GitHub社のワークフロー。
masterからブランチしてプルリクエストをしマージするといった基本的な流れのこと。

GitHub Flowのポイント

・masterブランチは常にデプロイできる状態に保っておく
・新開発はmasterブランチから新しいブランチを作成してスタート
・作成した新しいブランチ上で作業しコミットする
・定期的にpushする
・masterにマージするためにプルリクエストを行う
・必ずレビューを受ける
・masterブランチにマージしたらすぐにデプロイする
　←テストとデプロイ作業は自動化

リベース

変更を統合する際に、履歴をきれいに整えるために使うのがリベース。

git rebase <ブランチ名>

ブランチの基点(親コミット)となるコミットを別のコミットに移動する。

リベースとマージの違い

リベース：履歴が一直線
マージ：履歴が枝分かれ

リベースでしてはいけないこと

GitHubにプッシュしたコミットをリベースするのはNG

GitHubにプッシュしたコミットをリベースすると、、
GitHub上とローカルリポジトリとの親コミットが変わりプッシュできなくなる。

マージとリベースのメリット、デメリット

	マージ	リベース
メリット	コンフリクトの解決が比較的簡単	履歴を綺麗に保つことができる
デメリット	マージコミットがたくさんあると履歴が複雑化する	コンフリクトの解決が若干面倒

マージとリベースのコンフリクトの違い

マージはコンフリクトが一回しか発生しない。
リベースはコンフリクトが各コミットごとに発生する。

プルのマージ型

git pull <リモート名><ブランチ名>

マージコミットが残るので、マージしたという記録を残したいときに使う。

プルのリベース型

git pull --rebase <リモート名><ブランチ名>

マージコミットが残らないので、GitHubの内容を所得したいときにrebaseを使う。
何も変更していない時に使う。

リベースで履歴を書き換える

git rebase -i <コミットID>

-iは --interactiveの略。
対話的リベースといって、やり取りしながら履歴を変更していく。

①複数のコミットをやり直す

git rebase -i HEAD~3
↓
pick <コミットID> <コミットメッセージ>
pick <コミットID> <コミットメッセージ>
pick <コミットID> <コミットメッセージ>

↓　# やり直したいコミットをeditにする (pick → edit)
edit <コミットID> <コミットメッセージ>
pick <コミットID> <コミットメッセージ>
pick <コミットID> <コミットメッセージ>

↓　# やり直したら実行する
git commit --amend

↓　# 次のコミットへ進む(リベース完了)
git rebase --continue

「HEAD~」とは

HEADは今いるコミット。
HEAD~3は3つ前の親コミットまで遡る。

②コミットを並び替える、削除する

git rebase -i HEAD~3
↓
pick <コミットID> <コミットメッセージ>
pick <コミットID> <コミットメッセージ>
pick <コミットID> <コミットメッセージ>

↓  # 削除の場合    ：一行消す　
   # 並び替えの場合 ：行を入れ替える
pick <コミットID> <コミットメッセージ>
pick <コミットID> <コミットメッセージ>

削除は一行消す、並び替えの場合は行を入れ替えるだけでできる

③コミットをまとめる

git rebase -i HEAD~3
↓
pick <コミットID> <コミットメッセージ>
pick <コミットID> <コミットメッセージ>
pick <コミットID> <コミットメッセージ>

↓  
pick <コミットID> <コミットメッセージ>
squash <コミットID> <コミットメッセージ>
squash <コミットID> <コミットメッセージ>

squashを指定するとそのコミットを直前のコミットと一つにする。

コミットにタグをつける

タグをつけておくとコミットを参照しやすくするためにタグをつける。
リリースポイントによくつける。

タグ一覧を表示する

git tag

アルファベット順にタグを表示する。

タグを作成する

タグには2種類ある
注釈付き版 : annotated
軽量版 : lightweight

注釈付き版を作成する

git tag -a <タグ名> -m "<メッセージ>"

-aオプションを付けると注釈付きタグを作成。
-mオプションを付けるとエディタを立ち上げずにメッセージを入力できる。

軽量版を作成する

git tag <タグ名>

タグのデータを表示する

git show <タグ名>

タグをリモートリポジトリに送信する

git push <リモート名><タグ名>

# タグを一斉に送信する
git push origin --tags

作業を一時避難する

コミットしたくないけど別ブランチで作業しないといけないときに一時避難する。

git stash
git stash save

saveは省略可能。

避難した作業を確認する

git stash list

避難した作業を復元する

# 最新の作業を復元する
git stash apply

# ステージの状況も復元する
git stash apply --index

# 特定の作業を復元する
git stash apply <スタッシュ名>

避難した作業を削除する

# 最新の作業を削除する
git stash drop

# 特定の作業を削除する
git stash drop <スタッシュ名>

# 全作業を削除する
git stash clear

これは何?

作業を忘れる俺のための備忘録
pycharmからgitを操作する予定
これをやれば自分のパソコンを汚さず作業ができるようになる

だからやれ
とにかくやれ

git導入

gitはいろいろと便利だから使えるようになってるといいね

1.インストール

まずは、以下のサイトからGitをダウンロード
https://git-for-windows.github.io/

あとは道なりに進めばインスト―ル完了
詳しい道のりは説明がめんどくさいから調べて

2.ユーザ名とメールアドレスの登録

コンソールで
$ git config --global user.name "ユーザー名"
$ git config --global user.email "メールアドレス"
を打ち込むと登録が完了する

github側の作業

githubのアカウントを作成し、githubのホームページへ行き右上の"+"からnew repositoryでリポジトリを作成する
Repository nameで名前を決める
publicかprivateか決めてcreate repositoryをクリック

すると画面に意味深なurlが出てくるからそれをコピーしてターミナルへ

Codeからでもurlを発行できるからcloneしたときとかはここからやろう

gitのプロジェクトを置きたいディレクトリに移動をしてgit clone <url>
こうすることでgitと繋がったディレクトリができるのでpycharmでもなんでも開く

.gitignoreの作成

ディレクトリは完成したがこのままではなんでもgithubで共有されるので.gitignoreを作る
ディレクトリ直下に.gitignoreって名前のファイルを作る

https://github.com/github/gitignore/blob/master/Global/JetBrains.gitignore
JetBeain系列のIDEを使ってるなら上のソースコードをコピペする
他のIDEは知らん

共有したくないファイルのパスをここに追記する
これでメモなどの他人と共有したくないファイルがgit側に共有されなくなる

Docker側の作業

github側の作業が終わったら次はdockerの作業

インストール

これにDocker for desktopのインストールからpycharm連携まですべてが詰まってる
https://qiita.com/Denpa_Ghost/items/caeddaa29bd9d7514cce

docker-compose.ymlの作成

ディレクトリ直下にdocker-conpose.ymlを作って以下をコピペする

docker-compose.yml

 version: '3'
services:
  app:
    build: docker/python
    tty: true
    volumes:
    - ./app/:/app
    working_dir: /app

build:がdockerfileの格納先の指定

tty:が起動後待機状態にするか
falseや未記入で動いてるものがないとすぐに落ちるため必須

volumes:がホスト機のフォルダとコンテナ内のフォルダをつなげる役割を持つ
左がホスト機、右がコンテナ内
ホスト側でフォルダがない場合新規に作成される

working_dir:はデフォルトの作業場の指定

dockerfileの作成

docker-compose.ymlを作ったらbuild:で指定したパスにdockerfileを作る
slackのbotを動かすなら以下をコピペする

dockerfile

FROM python:latest
RUN mkdir -p /app
RUN pip install slackbot

FROMはdocker imageを設定する
RUNはコンテナ生成後に入力するコマンドを入れる
docker imageに入ってない他のパッケージを入れたい場合などに使うといい

上記のならコンテナ生成後、appディレクトリを作成してslackbotのパッケージをインストールをする
主にlinuxのターミナルでできることならなんでもできる

コンテナの生成

ここまで来たらあとはコンテナを作るだけ
docker-compose.ymlがあるディレクトリ内で
docker-compose up --build -d
をすることでコンテナを生成できる

初回起動
docker-compose up --build -d

次回以降
docker-compose up -d
コンテナをまとめて止める
docker-copose stop

コンテナをまとめて消す
docker-compose down

コンテナとイメージをまとめて消す
docker-compose down --rmi

.pyの実行

プログラム作った実行したいときは
docker psで実行したいコンテナのnameをコピーして
docker exec -it <name> bash
でコンテナ内のターミナルへアクセスできる
あとは普通にpython main.pyなどでpythonの実行をする

ターミナルへアクセスせずに実行をしたい場合は
docker exec -it <name> <プログラム名>
でターミナルへ入らずに実行ができる

終わりに

質問や文句があるなら荒川までお願いします
対応したりしなかったりします

これで快適python生活を楽しもう！

Gitea が大好きです！
みなさんにも使ってほしいので推していきます！

Gitea - Git with a cup of tea

Giteaとは、セルフホストのGitサービス です。
セルフホストのGitサービス とは、ざっくりいうと、https://github.com/ のようなものを自分で構築できるサービスです。
https://github.com/ は、すごいサービスですが、障害が発生すると使えなくなってしまいます。
障害なども、コントロール化におけるセリフホストのGitサービス は、強い味方です。

私の考えるGiteaの魅力

セルフホストのGitサービス には、Github.comのエンタープライズ契約や、Gitlabがあります。
それらと比較して、私はGiteaを魅力的に感じています。
今回は、魅力と感じる点を３つ紹介します。

1. 軽量
2. シングルバイナリ
3. クロスコンパイル

---

1. 軽量

Giteaは、必要最低限のサービスを提供しているので、とても軽量に動作します。
Gitlabのように、多機能ではありません。
しかし、使っていく上で必要最低限のサービスや連携機能は存在しており、使っていく上でものすごく困ることは無いと思っています。

CD/CIまわすときは、痒いことがありますが、足りないならAPI呼び出しで作ればいいだけです！
Webhookできっくできるので、なんでもコイですよ！

なので、Giteaとしては、本当に、必用な機能しか動かないので、とても軽量に動作します。
私の環境では、起動時のメモリ使用量は、128MiB以内で収まっています！

2. シングルバイナリ

Giteaは、シングルバイナリで動作します。（これは、開発言語のGo言語によるものです）
パッケージの展開や、色々なところにファイルを展開する必用もありません。
gemがんばったり、pipがんばったり、apt install -fする必用もなく、バイナリをリリース から持ってくればいいだけです！
環境汚しも気にならないんですよね。導入の敷居がとても低く感じます！

3. クロスコンパイル

Giteaは、クロスコンパイルされています。（これは、開発言語のGo言語の機能を上手に使ったからです）
Windowsでも、Macでも、Linuxでも動作します。
手元のPCで動かしてみて、使えそうだったらVPSとかで動かすことも可能です。
データ形式は、環境が異なっても同じデータベーステーブルを使えます。
なので、.gitフォルダとデータベースをお引っ越しすれば環境移行も楽勝です！
（クロスコンパイルと関係ないですが、Dockerの提供もあるので、お引っ越しし放題です！）

---

いかがでしょう！
今回は魅力３つの紹介をしましたが、私個人的に魅力を感じる機能は、まだいっぱいあります。

ぜひ使ってみてください！

手元のWindowsでもすぐ動きますので、ぜひちょっとつけてみて、魅力を知ってください！
ちょっとクリックすれば、Github.comの小さいものがお手元に！
あと、公式サイト のアイコンもとても可愛いので、ぜひ〜。

リンク

• 公式サイト
• ドキュメントページ
• ブログ