こんにちわ、語学交換マッチングアプリ『CROSSER』の開発者です。 この『CROSSER』なのですが、FlutterとFirebaseを用いて開発しております。 今回は、Flutter Packageをカスタマイズする方法を記載していきたいと思いますので、このパッケージめっちゃいいけど！なんか惜しいな！！って時に是非参考にしてみて下さい! はじめに 語学マッチングアプリ『CROSSER』の概要についてはこちらを参照ください！ 今回書くもの Flutter Packageをカスタマイズして利用する方法 使用するもの Git Flutter Packageカスタマイズ手順 ①カスタマイズしたいパッケージのページにいく 今回はswipable_stackというパッケージをカスタマイズしていきます。 https://pub.dev/packages/swipable_stack ②VersionsページでカスタマイズしたいVersionのソースをダウンロードする。 ③ダウンロードしたソースをローカルに解凍する。 ④解凍したソースを開く（私はVSコードで開発しているのでVSコードで行いました) ⑤パッケージで修正したい部分を修正する。 ⑥gitにpushする。 ⑦開発しているflutterアプリのworkspaceを開き、pubspec.yamlのdependenciesに追加する 以下のように追加します。 dependencies: swipable_stack: git: url: カスタマイズしてpushしたGitレポジトリーURL ⑧flutter pub get まとめ dependenciesにgitのurlを指定することができる。 今回はカスタマイズしたいFlutter Packageを修正したものを使用したが、オリジナルのパッケージもこのGitにあげれば読み込める。 言語交換マッチングアプリ『CROSSER』もよろしくお願いします。 評価もいただけると嬉しいです！ iOS/Androidモバイル対応 https://crosser.page.link/crosser

はじめに 本稿は執筆者の備忘録です。 記述内容に誤りなどありましたら、教えていただけると幸いです。 また、末尾に参考サイトのリンクを貼り付けています。 より詳しい解説となっておりますので、ぜひそちらもご覧ください。 メインブランチは更新される 最近はチーム開発に関わるようになり、個人学習よりも本格的にgitを使うようになりました。 自分に振られたIssueをこなすので精一杯なのですが、如何せん時間がかかります。 ようやく動作確認までして、いざpush!、、と思いきや、コンフリクトしているようです。 何やら数日前に大きく改修したらしく自分がブランチを切った際のメインブランチが古くなっていたということらしい。 なんか、自分の仕事が遅いような気がしてちょっと切なくなります。 が、しかしこれはチーム開発である以上避けては通れない道ですよね。 メインブランチの更新を取り込む 作業ブランチで更新されたメインブランチを取り込むには、 git pull origin {mainブランチ名} とすればOKです。 また、pullコマンドはfetch(リモートのブランチからデータを取ってくる)とmerge(データを取り込む)をした場合と同義です。 ですので、 git fetch git merge origin/main としてもOK。 --rebaseオプションを使う pullコマンドのオプションに--rebaseがあります。 これは、前述したメインブランチの更新を作業ブランチに取り込むのではなく、作業ブランチを切った際の状態を、更新されたメインブランチに付け替えるというイメージでいいかと思います。 git pull --rebase origin {mainブランチ名} こうすると、gitのマージコミットがスッキリします。 イメージしにくい方のために、私が書いた超綺麗な図解を載せておきますね。 ただ、元の履歴が消えてしまうので、通常のマージでログを残した方が良い場合もあります。 チームの方針を確認した方がいいとのことでしたので、注意してください。 参考サイト https://kray.jp/blog/git-pull-rebase/ こちらのサイトは本稿の１００倍詳しく、そして分かりやすいです。

はじめに 学習するに至った経緯 未経験からエンジニアへの転職を目指し、プログラミングを勉強中。 Git/GitHub/GitHubDesktopの使い方を理解しているところと理解していないところが ごちゃ混ぜになっている事が判明。 自身の理解の整理と言語化による認識の深化による備忘録として記載。 GitHub Pagesとは 『GitHub Pages』とは、GitHub のリポジトリから HTML、CSS、および JavaScript ファイル を直接取得し、任意でビルドプロセスを通じてファイルを実行し、ウェブサイトを公開できる静的なサイトホスティングサービスのこと。 メリット Webサーバーが一切不要 JavaScriptやjQueryも作動する GitHubアカウントを持っていれば3～5分程度で公開できる 「xxx.github.io」のドメインがもらえる (xxxはあなたのユーザー名) ドメイン設定をすれば独自ドメインの使用も可能 デメリット GitHubを使っているのでソースコードが公開される サーバーに接続する大規模サイトには向いていない GitHubを使っているため日本語ローカライズがされていない GitHub Pagesを使ってWebページを公開 1.GitHub Pages用のリポジトリの作成 2.ウェブページの作成 3.GitHubへプッシュ 4.GitHub Pagesへアクセスして確認 1.GitHub Pages用のリポジトリの作成 GitHub Pagesには大きく分けて2つの種類があり、ユーザのウェブページを公開する①ユーザサイト（User site）とプロジェクトのウェブページを公開する②プロジェクトサイト（Project site）がある。 ※　組織サイト（Organization site）もあるが、主体がユーザか組織かというだけで、基本的にはユーザサイトと同じもの。 ※　ユーザサイトとプロジェクトサイトではリポジトリの作成方法が少し異なる。 ①ユーザサイト用リポジトリの作成 (1) GitHubにアクセスし、ログインする。ページ右上の『+』アイコンをクリックし、『New repository』をクリックする。 (2) 「Repository name」欄に、「username.github.io」（「username」の部分は自分のGitHubユーザ名）と入力し、 『Create repository』ボタンをクリックする。 (3) ローカルのターミナルで、下記のように実行したら、（usernameは自分のGitHubユーザ名に変更する）　ローカル環境にレポジトリがクローンできる。 $ git clone 　　例：https://github.com/username/username.github.io (4)カレントディレクトリに「username.github.io」というディレクトリができているので、そのディレクトリに入れ、ユーザサイト用のリポジトリが作成できた。 $ cd 　例：username.github.io ②プロジェクトサイト用リポジトリの作成 ウェブページを作成したいプロジェクトのリポジトリに「gh-pages」という名前のブランチを作成し、チェックアウトする（「/path/to/local-repository」はローカルにあるリポジトリのパス）。 $ cd /path/to/local-repository $ git branch gh-pages $ git checkout gh-pages 既存リポジトリの場合、すでに存在しているプロジェクトのファイル群はウェブページには基本的に必要ないので削除する（「.git」ディレクトリはGitが用いるので残します）。これでプロジェクトサイト用のリポジトリが作成。 2.ウェブページの作成 GitHub Pagesに反映させるためのページをローカルのリポジトリで作成する。 HTML、CSS、画像はもちろん、JavaScriptを用いることもできる。 ※ ここでは簡単に「Hello world」と文字列を表示するページを作成。　自分で試すときは、しっかりHTMLファイルを作成しても構わない。 $ echo "Hello world" > index.html html-file01 ファイルが完成したので、リポジトリにコミットし、事前準備は完了です。 $ git add --all $ git commit -m "Initial commit" 3.GitHubへプッシュ GitHub Pagesで表示させるために、ローカルでコミットした変更をGitHubへプッシュする。 ※ 今回は、originという名前でGitHubのリポジトリを作成した例を記載。別の名前をつけたい場合は置き換える。 ここでもユーザサイトとプロジェクトサイトでやり方が異なるので注意 !! ① ユーザサイトの場合は「master」ブランチをプッシュする。 $ git push -u origin master ② プロジェクトサイトの場合は「gh-pages」ブランチをプッシュする。 $ git push -u origin gh-pages 上記コマンドの後、自分のGitHubユーザ名とパスワードを入力してプッシュし、作業は完了。 4.GitHub Pagesへアクセスして確認 作成したウェブページは、ユーザサイトの場合は「http://　例：username.github.io」で、　 プロジェクトサイトの場合は、「http://　例：username.github.io/repository」で公開される。 ※ 「username」は自分のGitHubユーザ名、「repository」はリポジトリ名に置き換える。 ※ ウェブページが表示されないときは、リポジトリ名およびブランチ名が正しく設定されているかを確認すること。 公開したページを更新する ローカルレポジトリに入り、作成したHTMLファイルを更新する。 ※ 今回は、文字を「Hello GitHub Pages!」に変えただけ。 　　　　$ cd /path/to/local-repository ※ $ echo "Hello GitHub Pages!" > index.html ファイルの更新が終わったら、下記のように入力して変更をコミットする。 $ git add --all $ git commit -m "Update page" ①　ユーザサイトならば『master』ブランチをプッシュする。 $ git push -u origin master ② プロジェクトサイトならば「gh-pages」ブランチをプッシュする。 $ git push -u origin gh-pages 再度ブラウザで自分のページのURLへアクセスして、正しく更新されているかを確認する。 参考サイト GitHub Pages について 無料で使える！GitHub Pagesを使ってWebページを公開する方法 たった５ステップ！Githubの機能「GitHub Pages」でホームページを制作しよう

目次 1.よく使うコマンド 2.実際に使用していた手順 3.押さえておきたい概念 4.git pullとgit pull -rの違い 5.さいごに 1. よく使うコマンド ①git checkout ブランチ名 ブランチを移動する。 git checkout feature/kana/dayo-123456 ②git status 修正があるファイルを確認する。 git status ③git checkout . ②で修正があるときに修正を取り消す。 git checkout . ④git pull -r ブランチを最新化する。 ※git pullとの違いについてはこの記事の最後にまとめています。 git pull -r ⑤git pull -rp 複数の人が同じブランチで作業しているとき、他方の修正内容を反映させる。 git pull -rp ⑥git branch -l | grep '文字列' 検索したい文字列が含まれるブランチを探す。 it branch -l | grep 'kana' ⑦git merge 親ブランチ名 子ブランチで親ブランチの内容をマージする。 git merge feature/kana/dayo ⑧git branch ローカルブランチにあるブランチを確認する。 git branch ⑨git branch -d ブランチ名 ローカルブランチを削除する。 git branch -d feature/kana/dayo-123456 ⑩git branch -D ブランチ名 ⑨でエラーが出たときローカルブランチを強制削除する。 git branch -D feature/kana/dayo-123456 ⑪git fetch -p ⑨→⑩のあとにこのコマンドを叩く。 リモートブランチに存在していてローカルブランチに存在していないブランチを削除する。 git fetch -p feature/kana/dayo-123456 ⑫git checkout -b ブランチ名 ブランチを新規作成する。 git checkout -b feature/kana/dayo-123456 ⑬git push -u origin ブランチ名 指定したブランチで修正した内容をプッシュする。 git push -u origin feature/kana/dayo-123456 2. 実際に使用していた手順 親ブランチの内容を子ブランチに取り込む ※コミットするものはコミットしておく ①修正があるファイルを確認 git status ②修正があるときは修正をなくす git checkout . ③子ブランチでブランチ最新化 git pull -r ④親ブランチに移動しブランチ最新化 git pull -r ⑤子ブランチで親ブランチの内容をマージ git merge feature/kana/dayo 子ブランチの新規作成 ①親ブランチに移動しブランチ最新化 git pull -r ②子ブランチを新規作成 git checkout -b feature/kana/dayo-123456 ローカルブランチを消す ①消すブランチとは違うブランチに移動 git checkout feature/kana/dayo ②ブランチ削除 git branch -d feature/kana/dayo-123456 ③エラーが出たときに強制削除 git branch -D feature/kana/dayo-123456 ④リモートブランチに存在していてローカルブランチに存在していないブランチを削除 git fetch -p ※この手順のみではリモートブランチは消えない 3. 押さえておきたい概念 ※プルはフェッチとマージを一括で行うコマンド（プル＝フェッチ＋マージ） 4. git pullとgit pull -rの違い git pull　　 = fetch + merge git pull -r　= fetch + rebase ◆merge、rebaseとは 今いるブランチに別のブランチの内容を取り込むコマンド ◆違い マージは現在のブランチの上に他のブランチの内容を取り込むというかんじですが、 リベースは取り込みたいブランチの上に今のブランチの内容を乗せるといったかんじ ◆git pull -rのメリット マージコミットが作られない＆履歴が綺麗になる ◆注意 いきなりリベースをするとチームの規約に反する場合もありますので、 そのあたりは事前にチームの人に確認してください。 （現場でgit pull -rの使用を指示されていたため使用していたのですが、 チームの規約に反する可能性があるということは知りませんでした。。。） ↓こちらの方の記事がとてもわかりやすかったため、引用させていただきました。 ※--rebaseと-rは同じ意味のオプションです。 5. さいごに ここまで読んでいただきありがとうございます！ 主に実際に現場で使用していたコマンドをまとめてみました。 改めて調べてみると認識が違っていたり、 気づきがあったりしたためとても勉強になりました。 自分の記録が誰かのお役に立てると嬉しいです。。

githubでメインアカウント、サブアカウントがあるとして アカウントを使い分けられるように設定していきます。 githubのssh接続先を分ける .ssh/configの接続先を分けます。 Host github # メインのgithubアカウント用 HostName github.com User company-user IdentityFile ~/.ssh/id_rsa_github_company IdentitiesOnly yes Host github-sub # サブ用。github.com以外の任意のHost名 HostName github.com User private-user IdentityFile ~/.ssh/id_rsa_github_private IdentitiesOnly yes 上記の接続先の設定で接続テストができるか確認。 $ ssh -T git@github-sub Hi {githubのID}! You've successfully authenticated, but GitHub does not provide shell access これでサブのアカウントでgit cloneできるようになりました。 $ git clone git@github-sub:{githubのID}/{リポジトリ名}.git 作業ディレクトリ単位でアカウントを切り替える git clone、git pushはssh接続先を複数設定することで出来るようになりましたが、 これだとuser.nameとuser.emailの設定が足りないので、コミットにそれぞれのuser.name、user.emailが追加されません。 メインアカウントとサブアカウントとでuser.nameとuser.emailの設定も切り替えられるようにしたいところ。 ただ、git config --globalだと共通の設定になってしまうし、 git config --localだと対象リポジトリ内のみで都度設定するのは手間なので メインとサブの作業ディレクトリを分けて、それぞれの作業ディレクトリ下でgit cloneしたリポジトリには ユーザー情報がメインとサブでそれぞれ設定されるようにしたい。 作業ディレクトリはこういうイメージ。 /user/to/path/ ├ workspace-main/ # メインアカウントのリポジトリはこっちにgit cloneしたい └ workspace-sub/ # サブアカウントのリポジトリはこっち .gitconfigでディレクトリ毎の設定を分ける 下記のような.gitconfigファイルを設置します。 ~/ ├ .gitconfig ├ .gitconfig-main # メイン用設定ファイル └ .gitconfig-sub # サブ用設定ファイル 仕事用githubユーザー情報を.gitconfig-mainに、 同様にプライベートのgithubユーザー情報を.gitconfig-subにそれぞれ設定。 .gitconfig-main [user] name = main-user email = main-user@example.com .gitconfig-sub [user] name = sub-user email = sub-user@example.com .gitconfigに includeIf で作業ディレクトリ毎に読み込むファイルを追記。 [user] [includeIf "gitdir:/user/to/path/workspace-main/"] path = ~/.gitconfig_main [includeIf "gitdir:/user/to/path/workspace-sub/"] path = ~/.gitconfig_sub 各作業ディレクトリ下でgit cloneしたリポジトリで設定したユーザー情報が確認できたら完了です。 $ cd /user/to/path/workspace-sub/nanika-no-repository/ $ git config --list user.name=sub-user user.email=sub-user@example.com

概要 ポートフォリオ作成にあたり、開発タスクをissueを使って管理することにしたので issueのテンプレートを作成し、楽にissueをかけるようにしたかった。 作成方法 Settingsへ移動する まずはissueを作成したいプロジェクトへ移動し、 settings -> Optionsを選択 テンプレートを作成する準備 FeaturesのIssuesのSet up templatesをクリック 作成画面 Add template: selectをクリックし、任意のテンプレートを選択する。 今回はCustom templateを選択します。 次にPreview and editをクリック クリックするとカスタムテンプレートを作成する画面が表示されます。鉛筆横のマークをクリックします。 編集画面が表示されるので、必要な項目を入力していきます。 今回はTemplate nameとAbout、Template contentを入力します。 入力が完了したら、右上のPropose changesをクリックします。 コミットする Issue　Templateをコミットする画面に遷移するので、コミットメッセージを記載して、Commit changesをクリックします。 これで、概要のリポジトリのIssue Templateが完成です。 使い方 issue作成画面へ移動 issues -> New issue をクリック templateを選ぶ いくつかテンプレートを作成できるので、自分が使いたいテンプレートを選択し、Get startedをクリックします。 issueを作成する 先ほど作成したIssue templateの内容が書かれています。 今回作成したテンプレートの内容 まずは作ってみることが先決だと思うので、コピペできるようにテンプレートの内容を置いておきます。 チームや自分の作成したい仕様に合わせて変更してみてください。 // Template name issue template // About Here is a template for creating an issue // Template content ## Overview Please provide an overview of the issue you are creating. ex) I want to adapt the style of the header. ## Purpose Describe the purpose of this issue ex) To style it. ## Task Break down and manage your tasks. - [ ] XXXX - [ ] XXXX - [ ] XXXX