はじめに Gitへアップする前のシークレット情報の設定方法を手順化しました。 Pythonのバージョン:3.8.2 djangoのバージョン:3.2.9 gitのバージョン:2.30.2 目次 1.django-environのインストール 2.「.env」の作成 3.settings.pyの修正 4.「.gitignore」の確認 インストール django-environをインストールします。 pip install django-environ フォルダとファイルの作成 BASE_DIR（manage.pyがあるディレクトリ)にsecretsフォルダを作成します。 作成後、secretsフォルダ内に「.env」を作成します。 .envにproject/settings.pyの下記の情報を記載します。 ・SECRET_KEY ・DEBUG ・ALLOWED_HOSTS secrets/.env SECRET_KEY=secret_key #ここにsecret_keyを貼り付ける ※ダブルクォーテーションは取り除く DEBUG=True ALLOWED_HOSTS=* DATABASE_URL=sqlite:///db.sqlite3 settings.pyの修正 projectのsettings.pyの中を修正していく project/settings.py #追記--- import environ env = environ.Env() root = environ.Path(BASE_DIR / "secrets") env.read_env(root(".env")) #修正--- SECRET_KEY = env.str("SECRET_KEY") DEBUG = env.bool("DEBUG") ALLOWED_HOSTS = env.list("ALLOWED_HOSTS") DATABASES = { 'default':env.db(), } .gitignoreの確認 .gitignoreに.envの記載があることを確認 ない場合は追記 .gitignore # Environments .env 設定は以上

はじめに こんにちは。 こちらの記事では、スクリーンショットからURLを発行する方法を記しています。 誤っている点がございましたらコメントいただけると幸いです。 手順 READMEの作成をするときに、PC（Mac）で撮ったスクリーンショットを使用したいことがあると思いますが、URLが発行されないのでこの記法では、画像やGIFを表示できません。 そんなときは、GitHubのIssues を活用することで解決できます。 GitHubのIssuesを活用 使用したいスクーンショットをコピーして、Issuesのコメント欄にペーストします。するとURLが発行されます。 Gyazoを利用する URLを発行する方法は他にもあり、Gyazoというアプリを活用する方法があります。 Gyazoは、スクリーンショットで撮った画像やGIFを共有するためのツールで、自動でURLが生成されます。無料で利用できるプランもあるので、興味がある方は使ってみてください！ 詳しくは下記のサイトを参照してください。 Gyazoの使い方をインストールから丁寧に解説！オススメです おわりに ここまでスクリーンショットからURLを発行する方法についてまとめました。 視覚的にわかりやすくするのに画像やGIFはよく使うと思うので、参考にしていただければと思います！ 以上、最後まで読んでいただきありがとうございました！ よければLGTMを押してくれると嬉しいです！

追記 なお本来はgit cloneにて、Github上で作成したリポジトリをローカルに入れ込む管理の方が良い。 目的 久しぶりにGithubに新しいリポジトリを作成しました。が、色々忘れていて少し調べたので、次はスムーズに進められるようまとめておきます。 Github連携 # 1. Githubにディレクトリ作成 # 2. ローカルのgitを初期化 cd ~/repository/repository2 # 該当のディレクトリへ git init git add. git commit -m 'initialize' # 3. リモートのリポジトリを登録（SSH接続） git remote add origin git@github.com:useer_name/repository_name # 4. リモートにpush git push origin master おわり 初歩的すぎて、、

gitについて ・gitとは、バージョン管理にことを言う ※バージョン管理とは、誰がいつどこでコードを修正したかを可視化すること -・githubとは、オンライン上で管理すること。 ※gitはローカルで管理、githubはオンライン上で管理 git hubについて ・githubとは、オンライン上で管理すること。 git githubの実行手順　 (Gitコマンド１) ・git init (gitリポジトリーの作成　最初だけ)　 ・git remote add origin (GitHubのURLを登録) ・git switch -c <ブランチ名>　(ブランチを作成して切り替える) ※リポジトリーとは、フォルダーやファイルなどの記録する場所 (Gitコマンド２) ・git add . (変更内容をステージングに追加) ・git commit -M (git commit -m "メッセージ") ・git push origin <ブランチ名> (GitHubにプッシュ) (Gitコマンド３) ・git switch <ブランチ名> (ブランチを切り替える) ・git pull origin <ブランチ名> (GitHubの変更内容を取り込む) github メールアドレス ユーザーネーム ・git config —global user.name “jojo232” ・git config —global user.email yuya90360@icloud.com ・git config —global merge.ff false ・git config —global pull.rebase merges ・git config —list (確認する) README.md 意味 "https://code-ship-blog.wemotion.co.jp/class-diary/%E3%80%90%E4%BB%8A%E6%97%A5%E3%81%AEqa%E3%80%91readme-md%E3%81%A3%E3%81%A6%EF%BC%9F%E3%80%90github%E3%80%91/#:~:text=GitHub%E3%81%AEREADME.md%E3%81%A3,%E4%B8%8B%E3%81%AB%E8%A1%A8%E7%A4%BA%E3%81%95%E3%82%8C%E3%81%BE%E3%81%99%E3%80%82"

本記事を作成した動機 自分は Git Bash ではなく WindowsTerminal + PowerShell をよく使っている。 が、公式サイトには PowerShell での手順が載っていなかったので、備忘録としてメモ PowerShell での手順 SSH キーを生成 # メールアドレスは自分のものに置き換える ssh-keygen -t ed25519 -C "your_email@example.com" 作成した公開鍵をクリップボードにコピー Get-Content "${HOME}\.ssh\id_ed25519.pub" | Set-Clipboard 公開鍵を GitLab に登録 GitLab の設定画面 の「User Settings」->「SSH Keys」 ->「Key」にペーストする 「Add key」を押下する 参考サイト https://docs.gitlab.com/ee/ssh/index.html#generate-an-ssh-key-pair https://docs.github.com/ja/authentication/connecting-to-github-with-ssh/adding-a-new-ssh-key-to-your-github-account https://docs.microsoft.com/ja-jp/powershell/module/microsoft.powershell.management/set-clipboard

Gitの話をしよう。 Gitなんて「息をするように」つかうもんだよねぇ～ 最近はこんな初心者殺しなことを平気で言う人もいたりします。そんなこといたって。 知らないものはしらんよ。 なわけで、少しずつ整理して理解を深めていけばいいと思います。私ならそうします。ただ、gitの使い方とかテクニックとかそういう話は数多あるんで、そちらにゆずります。 この記事では、おもにGit と Git Hubは違いますよ～って話をしたいと思います。 この記事には「本当ではないこと」が多分に含まれています。概念と経緯を浸透しやすく丸めて、理解しやすくしたいと考えているからです。読んでくれた人が少しでも分かってくれたらうれしいな。 Gitってなんですか？ Gitはファイルのバージョンを管理するためのソフトで SCM(Source Control Management) 一つです。SCMのもっとも重要な役割は以下二点で、これができないソフトはSCMではありません。 ファイルの状態管理 ファイルの変更履歴管理 ここで 「変更履歴管理」 とさらっと書いていますが。これは、過去のあらゆる時点（コミット）にさかのぼってファイルを再現可能であるということ意味します。よくあるファイルサーバでファイル名+日付管理は人がやりますが。プログラムという超多量のファイルの集合体に対して管理してくれるのがSCMの利点です。 No. 世代 名称 ネットワーク共有(リポジトリ) 備考 1. 第一世代 SCCS なし 対象ファイルのディレクトリに管理ディレクトリを作成しDELTASファイルを作成、更新する。 2. 第世代 CVS あり RCSを基礎として開発。ネットワーク共有機能を追加。整理。 3. 第二世代 Subversion あり CVSの問題点を解消。例えば、ファイル名変更時の履歴の引継ぎや、http等のより汎用性の高いプロトコル利用など、より利用しやすくなっている。 4. 第三世代 Git あり 分散管理型SCM。Linux kernel管理用に開発 5. 第三世代 Mercurial あり 分散管理型SCM。JavaFXのコード管理などに利用されている コンピュータの使われ方と密接に関係しています。そのため、第三世代として取り上げているGit/Mercurialは、登場時期も同じです。同じような課題を解決したいと思っているはずなのでおそらくできることもほぼ同じかと。。。知らんけど。 リポジトリってなんですか？ リポジトリとは、ファイルを共有するためのデータプールです。利用者はこのリポジトリを共有することで、ネットワークごしの共有を実現します。リポジトリに対する操作の代表を以下に示します。 No. 操作 役割 備考 1 Check Out（チェックアウト) リポジトリからファイルを取得する。 2 Add（追加） ファイル(または、その変更)をリポジトリに追加する。 対象の変更を登録対象として印をつける（ステージする） 3 Commit（コミット） ファイルを（または、その変更）リポジトリに登録する。 この時点でリポジトリに取り込まれ、再現可能な静止点となる リポジトリを共有しましょう このリポジトリの共有の仕方は、「集中管理型」 と 「分散管理型」 で大別されます。 No. 共有方式 特徴 1 集中管理型 リポジトリを全ユーザ間で共有する。 2 分散管理型 リポジトリをユーザ毎にコピーして利用する。 集中管理型では、リポジトリの情報を取得するたびに、ネットワークを介して情報を取得します。(そこにしか情報がないのです。) 日本のSIerに今でも大人気 のSubersionはこのタイプです。Subversionの場合、「指定したフォルダ以下の全てのファイル」の最新版だけをワーキングcopyとして取得します。checkout commit, 過去のファイルの取得もネットワーク接続時にのみ可能です。閉鎖ネットワークで開発することを前提とした場合とても使いやすいものです。（あと、ネットワークリソースやストレージリソースが貧弱な場合も） 分散管理型は、リモートだけではなく、ローカルにリポジトリをcopyしておくので、必要な情報をいつでも取得可能としています。 OSS開発で大人気のGitは、このタイプです。ネットワーク速度の向上とストレージ価格の下落が普及を後押ししました。OSSの過去の状態をいつでも参照可能で、作業を自体をネットワーク接続から分離できる特徴から世界中で利用されています。 湖畔の別荘でのんびり開発したい！！　そこにネットワークがないからできないとか単なる甘え ってことです。さすが、欧米人は違います。 出てくる要素が1段増えたので、操作も増えます。 No. 操作 役割 備考 1 Check Out（チェックアウト) リポジトリからファイルを取得する。 2 Add（追加） ファイル(または、その変更)をリポジトリに追加する。 対象の変更を登録対象として印をつける（ステージする） 3 Commit（コミット） ファイルを（または、その変更）リポジトリに登録する。 この時点でリポジトリに取り込まれ、再現可能な静止点となる 4 Copy1 リモートリポジトリをローカルリポジトリに複製する。Git ではClone Clone はcopyと一緒にmasterもしくはmainのcheckoutも行う。 5 Copyback2 ローカルリポジトリの変更をリモートリポジトリに反映する。Git ではPush 最後に、Git と Subversionの検索回数の差です。やはりGitの方が人気なように見えますが。Gitの方が難しいという意味もあるのかもしれません。 あれ？GitHubが出ていないよ？ はい。出ていません。出てくる場面がないのです。だってGit Hub は　バージョン管理システムじゃないから。Gitの話をしている場合は、ビタイチ出てこないのです。では、GitHubとは何なのでしょうか？ リモートリポジトリに要求されるもの 話を戻しましょう。Gitの運用に欠かせないリモートリポジトリに求められるものは何でしょうか？ No. 求められること 具体的には？ 必須 1 誰でも利用可能なプロトコルによる応答 HTTP(S) または SSH 〇 2 適切なユーザだけが、リポジトリを操作可能とすること 認証 〇 3 ユーザの役割に応じてできる操作、アクセス可能なデータを制限すること 認可 △ 4 潤沢なストレージ HDD/SSD/NAS/S3/Cloud Storage 〇 5 データを失ってはいけない バックアップ 〇 6 なるべく高速なレスポンス キャパシティ見積もりかなぁ 〇 1,2,4を実現するのは割と簡単で、極端な話SSHDが走っているLinuxサーバがあれば十分です。 慣れた人なら1日かからず運用を開始できます。しかし、3,5はそうではないのです。最低5を整えるだけで、バックアップシステムの設計、開発、構築。バックアップストレージの設計い開発、構築、レストア手順の策定とちょっと油断すると数千万円規模の予算が必要になります。継続的に運用する必要があるので、ランニングも馬鹿になりません。 GitHub大地に立つ！！ ところで、上の表に開発対象ごとに異なる要件ってありますか？ないですよね。だったらとっても大きい箱を用意して、それをみんなで使うほうが、「安く、早く、安全」になりそうです。 それをサービス（ビジネス）として実現、提供しているのがGitHubです。あぁやっと出てきた。 差別化しないとね！ さて、リモートリポジトリ代行サービス。「だけ」だと、すぐにレッドオーシャン化してしまいます。ちょっと大きなデータセンタ抱えてれば誰にでもできてしまうのです。皆さんご存知のF〇itsuとか日本の電気屋さんとか、国内のダメダメベンダーだって実現可能です。長く商売をするには差別化要因が必要です。たとえば 「ルナチタニウム合金」 とか 「パイロットがニュータイプ」 みたいな。。 彼らの差別化要因はやはりOSS開発に根差したものでした。 Pull Request機能による開発者主体の開発の実現 Issue管理との連動 APIの制定とその運用 1点目と3点目がすごく大きいかと思います。1点目は商標なのか、後発の各製品がある時期軒並み「Pull Request」を「Merge Request」に置き換えました。APIの制定と運用も大きいですね。他のCI/CD製品が連動する基盤としての地位を気付きあげることに成功したのです。これらのキーアイデアを武器に、OSS開発者のUXを磨き上げ、他者との差別化を図っています。 Git Hubクローンだってさ こんなに素晴らしいGitHub。みんながまねをするに違いありません。え？ガンダム基、GitHubは唯一無二でほかに変わるものはない？ありますお？ガンダムにだって、陸戦型やら、パーフェクトやらフルアーマーやジムがいたんだから、GitHubにだってGitHubクローンが出てきてあたり前です。いくつか例を挙げます。 No. ソフト名 概要 1 Git Lab 言わすと知れた、貧者のGitHub APIだってほぼ同じように使えます。 2 GitBucket takezoe氏のGit Hub オマージュ。1 warでいきなり起動。試すだけなら一番簡単 じゃぁ、そのうちGitHubは廃れちゃうの？ 立ち止まっていればそうでしょう。でも彼らは立ち止まりません。先だってリリースされたGitHub copilotは素晴らしい。MSの資本をうけた一つの成果だと思います。 まとめ 以上、Git と　Git Hub についてでした。いわゆるGitの良さを語る場合、Pull Requestがぁ～ とか APIがぁ～ とか ISSUE管理と連動してとか言っちゃうのは、「GitHubの良さじゃね～か‼Gitの話違うんかい」 ビッシィ というお話でしした。 Copyという機能はGitにはありません。理解優先の造語です。  ↩ CopyBackという機能もGitにはありません。理解優先の造語です。 ↩

「よし、完璧だ！」とコミットした後やPRで指摘されてtypoに気づき、fix: typoコミットするのはできるだけ避けたいです。 レビューする側にとってもtypoに意識を向けながらレビューをするのは負担になります。貴重な時間はもっと大事な確認と指摘に使いたいものです。 今回は、そんなtypoを自動的に検出してコミットを防ぐ方法を紹介します。 “悲しいfix: typoコミット” できるようになること コミット時に変更ファイルのtypoを自動的に検出し、typoがあった場合はtypo箇所と修正のヒントを出力してコミットを防ぎます。typoがない場合はコミットは成功します。 設定方法 typoの検出 typoの検出にはRust製のtyposを採用しました。 macの場合のインストール手順を記載します。 shell # rustのインストール brew install rust # typosのインストール cargo install typos-cli # バージョンが出力されればOK typos --version ※ GitHubからバイナリをダウンロードして利用する方法もあります。 コミット時に自動的にtypoを検出する Git Hooksを利用することで実現しています。 利用したいリポジトリの.git/hooks/pre-commitを編集してください。 .git/hooks/pre-commit #!/bin/sh # 変更差分をチェックしたい場合 # git diff --cached --diff-filter=AM | typos - # 変更ファイルをチェックしたい場合 git diff --cached --name-only --diff-filter=AM | xargs typos # typoがある場合にコミットを防ぐ if [[ $? -ne 0 ]]; then exit 1 fi .git/hooks/pre-commitに実行権限がない場合は権限を付与してください。 shell # 実行権限の付与 chmod +x .git/hooks/pre-commit 動作方法 設定が終わったリポジトリでコミットすると自動的に動作します。 これでtypoを含んだコミットを自動的に防ぐことができ、fix: typoコミットすることはなくなります。 最後に この記事を読んで「面白かった」「学びがあった」と思っていただけた方、よろしければ Twitter や facebook、はてなブックマークにてコメントをお願いします！ また DeNA 公式 Twitter アカウント @DeNAxTech では、 Blog記事だけでなく色々な勉強会での登壇資料も発信してます。ぜひフォローして下さい！ Follow @DeNAxTech