- 投稿日：2019-12-04T23:16:48+09:00
会社でGit導入で詰まったところ
私を含めあまりGitに慣れていないメンバーばかりのPJにてGitを導入することになった
その時詰まった点をメモしておきたいGitflowの考え方が理解できなかった
Gitflowとは
このサイト参照
https://www.atmarkit.co.jp/ait/articles/1311/18/news017_2.html我々下請けは悲しいかなこのうちdevelopブランチとfeatureブランチしか使わない
しかし、初学者にはこれらすら難しかった。developブランチからfeatureブランチが作成され、実装完了後developブランチにマージするということも難しかった
featureブランチは機能単位で作成するということも理解できなかった
どのブランチがdevelopブランチでどれがfeatureブランチか、わからなかった
Gitflowを理解しても実際そこそこたくさんあるブランチのうち、どれをdevelopブランチとして起点にfeatureブランチを作成するのかがわからなかった。
このあたりを共有する会や資料は必要かなと
今後の課題
「featureブランチは機能単位で作成する」
これがあるため、どのようにすれば競合を防げるのか、あまり個人的にはわかってないです。
- 投稿日：2019-12-04T16:22:20+09:00
git初心者から見たmergeして衝突(CONFLICT)したときの対処法
ブログを書くにあたって
Qiita初投稿でブログを書くのもあまり経験がございません。
この記事を読むときはどうかお温かい目で読んでくださいませm(__)m
あと文章を書く力もございません実行環境
コンソール
- cygwin 3.1.0
エディタ
- sublime Text 3
- visual studio Code (バージョンはまた今度調べます)
mergeしてみた
git merge originとコマンド打つと以下のような実行画面になった。
小さくて読みづらいが、CINFLICTの文字が見える衝突(CONFLICT)したファイルを開いてみる
以下のキャプチャは、衝突したファイルの中身である。
すると、ソースコードの所々にある<<<<<<< HEAD(15行目)や=======(46行目)や>>>>>>> origin(69行目) があるのがみてとれる。
これを直さずにそのまま放置するとエラーを吐くので、早急に対処する必要がある。<<<<<<< HEAD や ======= や >>>>>>> origin の意味するものとは？
調べてみたところ、
<<<<<<< HEADと=======の間の部分(16行目～45行目)が作業ブランチの(自分が変更した)内容で
=======や>>>>>>> originの間の部分(46行目～69行目)が他の人が変更した内容だということがなんとなくわかった。
<<<<<<< HEADと=======の間の部分を消して=======や>>>>>>> originの間の部分は残しておくことにした。備考
この記事は他の人が読むほどの質の高い記事ではないと自分では思っています。
私が得た知識をアウトプットする練習のために書きました。参考
- https://ja.wikipedia.org/wiki/%E3%83%9E%E3%83%BC%E3%82%B8_(%E3%83%90%E3%83%BC%E3%82%B8%E3%83%A7%E3%83%B3%E7%AE%A1%E7%90%86%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0)#3.E3.82.A6.E3.82.A7.E3.82.A4.E3.83.9E.E3.83.BC.E3.82.B8
- https://techacademy.jp/magazine/10264
- https://qiita.com/te2u/items/c23f82ec84cf65564554
- 投稿日：2019-12-04T15:42:54+09:00
git cloneの時に鍵がないと怒られた時の対処法
git cloneの時に鍵がないと怒られた時の対処法
先日とあるプライベートレポジトリをcloneしたのですがこのようなエラーメッセージが出て失敗してしまいました。
git@github.com: Permission denied (publickey). fatal: Could not read from remote repository.鍵がないよと言われてそうなので鍵を生成してgithubにアップロードします。
shell$ ssh-keygen -t rsa -C "githubに登録してあるメールアドレス"で鍵を生成した後~/.ssh/に生成されるid_rsa.pubというファイルをgithubにアップロードします。
gitへのアップロードは
https://github.com/settings/keys
から行います。その後~/.ssh/configに
~/.ssh/configHost github HostName github.com IdentityFile ~/.ssh/id_rsa User gitと書き込めばcloneできるようになります。
参考
- 投稿日：2019-12-04T15:00:17+09:00
perlcriticを使って自動でコードの品質を担保する仕組みを作ってみた
最近の興味
コードレビューや設計レビューなど、
未だに人力で頑張っているプロジェクトが多い印象があるので、
なんかおしゃれに自動化出来ないかなと思って考えていて、
とりあえずなんか作ってみようかなとなって作ってみました。perlcritic選定理由
perlでの静的解析ツールで調べると、
perlcritic推しが多い印象だったのでとりあえず試してみようかという感じperlcriticのインストール
最近はcpanmではなくcartonが普通っぽいが、
現環境ではcpanmを使ってるのでここではそれを使用する。cpanm Perl::Critic;これで基本的にモジュールは入るが、
perlcriticというスクリプトのパスが通ってなかったので、.bashrcを書き換えてパスを通す。# ここは設定済みであれば対応不要 # cpanmで落としてくるディレクトリのパスが通ってればオーケー。 export PATH=$HOME/extlib/bin:$PATHこれでperlcriticを使う準備は出来た。
使ってみる
とりあえず既存タイトルのあるモジュールをperlcriticにかけてみました
> perlcritic -5 --verbose 8 Base.pm [Subroutines::ProhibitExplicitReturnUndef] "return" statement with explicit "undef" at line 127, column 2. (Severity: 5) [Subroutines::ProhibitReturnSort] "return" statement followed by "sort" at line 160, column 2. (Severity: 5) [Subroutines::ProhibitExplicitReturnUndef] "return" statement with explicit "undef" at line 395, column 2. (Severity: 5) [Variables::ProhibitConditionalDeclarations] Variable declared in conditional statement at line 445, column 2. (Severity: 5) [Subroutines::ProhibitExplicitReturnUndef] "return" statement with explicit "undef" at line 643, column 2. (Severity: 5) [Subroutines::ProhibitExplicitReturnUndef] "return" statement with explicit "undef" at line 650, column 2. (Severity: 5) [Variables::ProhibitConditionalDeclarations] Variable declared in conditional statement at line 665, column 2. (Severity: 5) [Variables::ProhibitConditionalDeclarations] Variable declared in conditional statement at line 697, column 2. (Severity: 5) [Subroutines::ProhibitExplicitReturnUndef] "return" statement with explicit "undef" at line 1154, column 2. (Severity: 5) [Subroutines::ProhibitExplicitReturnUndef] "return" statement with explicit "undef" at line 1155, column 2. (Severity: 5)結構出る。
5オプションについて どこまで厳格にPerlベストプラクティスに従っているのかの指定。 ちなみに5は最も優しいオプション。他の厳しいオプションで検知されるものとしては、文字列の中に変数展開が含まれてないのに
ダブルクォーテーションを使っているのはNGなどがあるが、今回はそこまでしない。
verboseオプションについて なぜその書き方だと駄目なのかという情報をどれだけしっかり表示するのかの指定。これぐらいゆるく静的解析をするのはありかもしれない。
githubのhookとかに打ち込めばある程度の品質の担保は行けそう。ということで実際にhookに仕込んで見る
.git/hooks/pre-push
remote="$1" url="$2" z40=0000000000000000000000000000000000000000 while read local_ref local_sha remote_ref remote_sha do if [ "$local_sha" = $z40 ] then # Handle delete : else if [ "$remote_sha" = $z40 ] then # New branch, examine all commits range="$local_sha" else # Update to existing branch, examine new commits range="$remote_sha..$local_sha" fi commit=`git diff --name-only "$range"` if [ -n "$commit" ] for file in $commit; do case "${file##*.}" in pl | pm | t) echo $file #perlcritic -5 --verbose 8 $file || exit 1 ;; *) ;; esac done exit 0 then exit 1 fi fi done exit 0pushされる前に、
pushしようとしているコミットと最新のコミットの間にある変更差分から、
Perlモジュール、Perlスクリプト、テストのみに対してperlcriticをかけるという処理作ってみた感想
Perlベストプラクティスに従うならこれでいいかなと言う印象。
あと、実際に大量のコードが存在しているプロジェクトに投入すると、
変更する毎に自分が触った部分ではない処理の解析が大量にされるので、
覚悟を持ってやる必要あるなとは思いました。でも、push前に指摘するよりPR時に指摘とかの方が良いなと思うので、
そういうのを組み合わせた環境もちょっと今度作ってみたい参考
- 投稿日：2019-12-04T12:41:24+09:00
6歳娘｢パパ、プロジェクトフォルダを見つけるのに何時間かけるの？｣【ghq+fzf+zsh】
はじめに
娘(6歳)｢パパ、いま私のためのブログつくってるんでしょ?｣
娘｢ブログってどういうふうにつくるの?｣ワイ｢コードっていうのを元に動くんや｣
ワイ｢ちょっと待ってな。いまホームディレクトリやから…｣
ワイ｢たしかprojects/myproject01みたいな名前やったかな…｣
ワイ｢cd projects/myproject01...あれ、ないな｣
ワイ｢lsしてみよ。｣ (ポチッ$ ls . .. myproj myproj1 myproj001 myproject1 myproj2 myproject2 myproject3 yabai-proj sugoi-projectワイ(…クソみたいな構造してるやん)
ワイ｢ごめん。娘ちゃん、もうちょい待ってな｣娘｢部屋も汚い上に、ディレクトリも整理されてないんだね｣
どうするか
ghq と fzf(Fuzzy Finder)を利用すると、必要なプロジェクトに一瞬で移動できるようになります。自分の環境だとこのように動作します。
ghqとは
GitHubなどでホストされているレポジトリをクローンする際に、ディレクトリを指定してリポジトリを管理をシンプルにするためのツールです。
https://github.com/motemen/ghq
$ ghq get https://github.com/motemen/ghq clone https://github.com/motemen/ghq -> /Users/amachi/src/github.com/motemen/ghq git clone https://github.com/motemen/ghq /Users/amachi/src/github.com/motemen/ghq
git cloneの代わりにghq getで実行すると、カレントディレクトリに関係なく、指定されたルールでgit cloneできるのが分かります。fzfとは
fzf(Fuzzy Finder)は、インタラクティブでインクリメンタルな検索フィルターツールです。
コマンドラインでfzfコマンドを渡して検索をかけると、それに対応する結果をインタラクティブに返します。簡単に言うと、Googleの検索機能と似たような動きをコマンドライン上で出来ます。https://github.com/junegunn/fzf
導入の準備
macであれば、homebrew経由でインストールできます。
$ brew install ghq fzfインストール後、ghqでどこを起点のディレクトリとするかを、gitの設定ファイルを追加します。
$ git config --global ghq.root $HOME/src ↓ $ less ~/.gitconfig --- 追加された部分 --- [ghq] root = /Users/amachi/src --------------------ghq, fzfを組み合わせる
まず
ghq listでghq root以下に存在するプロジェクトの一覧を取得することができます。ここからfzfでインクリメンタルに検索をかけることができます。またfzfでは、
--previewオプションで、右半分の画面をプレビューに利用できるので、ここにプロジェクトを選択するのに便利な情報を表示していきます。これまで試したのは以下の3パターンですが、自分は
3. プロジェクトルートのファイルリストが好きです。preview : README ファイル
ghq list | fzf --preview "bat --color=always --style=header,grid --line-range :80 $(ghq root)/{}/README.*"
preview : git log情報
ghq list | fzf --preview "git --git-dir $(ghq root)/{}/.git log --date=short --pretty=format:'-%C(yellow)%d%Creset %s %Cgreen(%cd) %C(bold blue)<%an>%Creset' --color"
preview : プロジェクトルートのファイルリスト
ghq list | fzf --preview "ls -laTp $(ghq root)/{} | tail -n+4 | awk '{print \$9\"/\"\$6\"/\"\$7 \" \" \$10}'"
さらに使いやすく : zshのキーバインディング
さらにzshのキーバインディングに登録することで、プロジェクトを選択後にプロジェクト直下に移動できます。
以下の場合、Ctrl+]を押すと、プロジェクト選択画面が開きます。function ghq-fzf() { local src=$(ghq list | fzf --preview "ls -laTp $(ghq root)/{} | tail -n+4 | awk '{print \$9\"/\"\$6\"/\"\$7 \" \" \$10}'") if [ -n "$src" ]; then BUFFER="cd $(ghq root)/$src" zle accept-line fi zle -R -c } zle -N ghq-fzf bindkey '^]' ghq-fzfまとめ
娘｢パパ、 @Yametaro さんみたいな記事にするの早めに諦めたね｣
ワイ｢あの形式でまとめるって大変なんやな｣娘｢あと、ノリでつくってたtomoyamachiで埋めるアドベントカレンダー…｣
娘｢初日から休んだよね…｣
ワイ｢初日が日曜日なのはつらかったな｣娘｢…｣
- 投稿日：2019-12-04T10:23:30+09:00
[Mac] HomebrewでGitアップデートできないエラー => Error: The `brew link` step did not complete successfully The formula built, but is not symlinked
副題： HomebrewでGitのバージョンをアップグレードしたのに
git --versionで確認するとバージョンが変わらない件環境
- macOS 10.14.6
- git version 2.22.0
- Homebrew 2.2.0
（2019年12月3日時点）
結論
パスに問題がない場合、Homebrewで何らかのパッケージをインストール/アップデート/アップグレード時、シンボリックリンクが貼られなかったことが原因。以下のコマンドで解決。
ターミナル$ brew link --overwrite gitGit以外のパッケージのsymlinksを解決したいときは
gitの部分を適宜変更して実行。
そしてタイトルに「HomebrewでGitアップデートできないエラー」と書いたものの、厳密には「Gitのアップデートはできているがシンボリックリンクが適切に貼られないため、コマンドで呼び出すとアプデされていないように見える」が正しい。エラー発生までの流れと状況調査
そもそもはGitを最新版にアップグレードしたい！と思ったのが始まりでした。
現在のGitのバージョンを確認
ターミナル$ git --version git version 2.22.0 # 最新版は 2.24.0Homebrewでアップグレード
ターミナル$ brew upgrade gitこの後
git --versionでちゃんとバージョンアップできたか確認するも、
2.22.0からバージョンが変わらないという状況が発生。
Homebrewで管理できてなかった、パスが通ってなかった？などを調査。
whichで、 git コマンドがどこを参照しているか確認ターミナル$ which git /usr/local/bin/gitHomebrewでインストールした場所にあるようには見えるが・・・確実ではないので引き続き調査。
brew lsで、Homebrewからインストールしたパッケージを確認ターミナル$ brew ls autoconf glib libde265 little-cms2 openssl@1.1 x265 automake heroku libffi mysql pcre xz cmake heroku-node libheif node python yarn freetype icu4c libomp nodebrew readline gdbm ilmbase libpng openexr shared-mime-info gettext imagemagick libtiff openjpeg sqlite git jpeg libtool openssl webpやっぱりGitあるもよう。
インストール済みのパッケージが多すぎてリストが見づらい場合は、grepのコマンドで絞り込みも可能。ターミナル$ brew ls | grep git git
brew list gitで、Homebrewでのインストール先 ＝ HomebrewでインストールしたGitの本体がある場所を確認ターミナル$ brew list git /usr/local/Cellar/git/2.18.0/.bottle/etc/gitconfig /usr/local/Cellar/git/2.18.0/bin/git /usr/local/Cellar/git/2.18.0/bin/git-cvsserver /usr/local/Cellar/git/2.18.0/bin/git-receive-pack /usr/local/Cellar/git/2.18.0/bin/git-shell /usr/local/Cellar/git/2.18.0/bin/git-upload-archive /usr/local/Cellar/git/2.18.0/bin/git-upload-pack /usr/local/Cellar/git/2.18.0/bin/gitk /usr/local/Cellar/git/2.18.0/etc/bash_completion.d/ (2 files) /usr/local/Cellar/git/2.18.0/libexec/git-core/ (196 files) /usr/local/Cellar/git/2.18.0/share/doc/ (847 files) /usr/local/Cellar/git/2.18.0/share/emacs/ (2 files) /usr/local/Cellar/git/2.18.0/share/git-core/ (158 files) /usr/local/Cellar/git/2.18.0/share/git-gui/ (61 files) /usr/local/Cellar/git/2.18.0/share/gitk/ (13 files) /usr/local/Cellar/git/2.18.0/share/gitweb/ (5 files) /usr/local/Cellar/git/2.18.0/share/man/ (171 files) /usr/local/Cellar/git/2.18.0/share/perl5/ (19 files) /usr/local/Cellar/git/2.18.0/share/zsh/ (2 files)やっぱりちゃんとあるやん！ バージョン2.18.0・・・？雲行きが怪しくなってきた。
gitコマンドのショートカット（エイリアス）ではなくフルパスを指定して複数のGitのバージョンを確認
ターミナル$ /usr/bin/git --version git version 2.20.1 (Apple Git-117)ターミナル$ /usr/local/bin/git --version git version 2.22.0バージョンからしてもgitコマンドは
/usr/local/bin/gitを向いていることを再度確認。
brew upgrade gitしたときにエラーがなかったかもう一度確認ターミナル$ brew upgrade git ==> Upgrading 1 outdated package: git 2.18.0 -> 2.24.0_2 ==> Upgrading git ==> Installing dependencies for git: pcre2 ==> Installing git dependency: pcre2 ==> Downloading https://homebrew.bintray.com/bottles/pcre2-10.34.mojave.bottle.tar.gz ==> Downloading from https://akamai.bintray.com/9b/9bc0815c6c4c584ef16e93e5ecf37aa786303d88f9321274a29b4f60876d583f?__gda__=exp=1575368945~hmac=5a828a3607 ######################################################################## 100.0% ==> Pouring pcre2-10.34.mojave.bottle.tar.gz ? /usr/local/Cellar/pcre2/10.34: 230 files, 5.9MB ==> Installing git ==> Downloading https://homebrew.bintray.com/bottles/git-2.24.0_2.mojave.bottle.tar.gz ==> Downloading from https://akamai.bintray.com/34/343c1a0b842b84095aa0632ea7ca3f1717103fe4f393a6014c7f6165b079c849?__gda__=exp=1575368950~hmac=f533430d65 ######################################################################## 100.0% ==> Pouring git-2.24.0_2.mojave.bottle.tar.gz Error: The `brew link` step did not complete successfully The formula built, but is not symlinked into /usr/local Could not symlink bin/git Target /usr/local/bin/git already exists. You may want to remove it: rm '/usr/local/bin/git' To force the link and overwrite all conflicting files: brew link --overwrite git To list all files that would be deleted: brew link --overwrite --dry-run git Possible conflicting files are: /usr/local/bin/git -> /usr/local/git/bin/git （〜中略〜） /usr/local/share/man/man7/gitworkflows.7 -> /usr/local/git/share/man/man7/gitworkflows.7 ==> Caveats Bash completion has been installed to: /usr/local/etc/bash_completion.d zsh completions and functions have been installed to: /usr/local/share/zsh/site-functions Emacs Lisp files have been installed to: /usr/local/share/emacs/site-lisp/git ==> Summary ? /usr/local/Cellar/git/2.24.0_2: 1,547 files, 45.1MB Removing: /usr/local/Cellar/git/2.10.2... (1,445 files, 31.8MB) Removing: /usr/local/Cellar/git/2.18.0... (1,488 files, 35.5MB) ==> Checking for dependents of upgraded formulae... ==> No dependents found! ==> Caveats ==> git Bash completion has been installed to: /usr/local/etc/bash_completion.d zsh completions and functions have been installed to: /usr/local/share/zsh/site-functions Emacs Lisp files have been installed to: /usr/local/share/emacs/site-lisp/gitエラー内容書いてあったーーー！！
ターミナルError: The `brew link` step did not complete successfully The formula built, but is not symlinked into /usr/local Could not symlink bin/git Target /usr/local/bin/git already exists. You may want to remove it: rm '/usr/local/bin/git' To force the link and overwrite all conflicting files: brew link --overwrite git要するに、
/usr/local/bin/gitに対してgitコマンドのシンボリックリンク（ショートカットのようなもの）を作成しようとしたけど対象がすでに存在するため、エラーになってシンボリックリンク作れなかったよ、ということのようだ。
「対象ファイルを削除したいときはこうしてね」とrmリムーブのコマンドが親切に書かれているが、その次に書かれたbrew link --overwrite gitのコマンドでシンボリックリンクの上書きをすれば良さそうである。シンボリックリンクのオーバーライトを実施
ターミナル$ brew link --overwrite git Linking /usr/local/Cellar/git/2.24.0_2... 206 symlinks created $ git --version git version 2.24.0あらためて、無事にGitのバージョンアップができました！
まとめ
- ログとエラー内容はよく読む。
- GitなどのパッケージはひとつのPCに複数インストールされている可能性がある。
- いま自分がどこに保存したどのバージョンのどのパッケージを触っているのかを把握する。
- Error: The
brew linkstep did not complete successfully ... The formula built, but is not symlinked ... というエラーはシンボリックリンクのエラーなので、内容をよく読みながら対応する。以上！
参考URL
【Homebrew】インストールしたパッケージのシンボリックリンクが作成されない場合
今さらだけどHomebrewのコマンドをちゃんと理解して使おう
【 whereis 】コマンド――コマンド本体と関連ファイルを検索する
PATHを理解して、コマンドの在りかを探してみよう (1/3)
Homebrew使い方まとめ
homebrewインストール時にリンクが貼られない問題
HomebrewでGitをインストールする
brew install nmap で発生したインストール時のエラーをchownで解決
MacのGitのバージョンをアップデート！Homebrewでの管理に切り替える
Git のインストール 〜Git をMacにインストールしよう〜
- 投稿日：2019-12-04T10:23:30+09:00
[Mac] HomebrewでGitアップデートできないというか Error: The `brew link` step did not complete successfully The formula built, but is not symlinked
副題： HomebrewでGitのバージョンをアップグレードしたのに
git --versionで確認するとバージョンが変わらない件環境
- macOS 10.14.6
- git version 2.22.0
- Homebrew 2.2.0
（2019年12月3日時点）
結論
パスに問題がない場合、Homebrewで何らかのパッケージをインストール/アップデート/アップグレード時、シンボリックリンクが貼られなかったことが原因。以下のコマンドで解決。
ターミナル$ brew link --overwrite git（git以外のパッケージのsymlinksを解決したいときは
gitの部分を適宜変更して実行。）エラー発生までの流れと状況調査
そもそもはGitを最新版にアップグレードしたい！と思ったのが始まりでした。
現在のGitのバージョンを確認
ターミナル$ git --version git version 2.22.0 # 最新版は 2.24.0Homebrewでアップグレード
ターミナル$ brew upgrade gitこの後
git --versionでちゃんとバージョンアップできたか確認するも、
2.22.0からバージョンが変わらないという状況が発生。
Homebrewで管理できてなかった、パスが通ってなかった？などを調査。
whichで、 git コマンドがどこを参照しているか確認ターミナル$ which git /usr/local/bin/gitHomebrewでインストールした場所にあるようには見えるが・・・確実ではないので引き続き調査。
brew lsで、Homebrewからインストールしたパッケージを確認ターミナル$ brew ls autoconf glib libde265 little-cms2 openssl@1.1 x265 automake heroku libffi mysql pcre xz cmake heroku-node libheif node python yarn freetype icu4c libomp nodebrew readline gdbm ilmbase libpng openexr shared-mime-info gettext imagemagick libtiff openjpeg sqlite git jpeg libtool openssl webpやっぱりGitあるもよう。
インストール済みのパッケージが多すぎてリストが見づらい場合は、grepのコマンドで絞り込みも可能。ターミナル$ brew ls | grep git git
brew list gitで、Homebrewでのインストール先 ＝ HomebrewでインストールしたGitの本体がある場所を確認ターミナル$ brew list git /usr/local/Cellar/git/2.18.0/.bottle/etc/gitconfig /usr/local/Cellar/git/2.18.0/bin/git /usr/local/Cellar/git/2.18.0/bin/git-cvsserver /usr/local/Cellar/git/2.18.0/bin/git-receive-pack /usr/local/Cellar/git/2.18.0/bin/git-shell /usr/local/Cellar/git/2.18.0/bin/git-upload-archive /usr/local/Cellar/git/2.18.0/bin/git-upload-pack /usr/local/Cellar/git/2.18.0/bin/gitk /usr/local/Cellar/git/2.18.0/etc/bash_completion.d/ (2 files) /usr/local/Cellar/git/2.18.0/libexec/git-core/ (196 files) /usr/local/Cellar/git/2.18.0/share/doc/ (847 files) /usr/local/Cellar/git/2.18.0/share/emacs/ (2 files) /usr/local/Cellar/git/2.18.0/share/git-core/ (158 files) /usr/local/Cellar/git/2.18.0/share/git-gui/ (61 files) /usr/local/Cellar/git/2.18.0/share/gitk/ (13 files) /usr/local/Cellar/git/2.18.0/share/gitweb/ (5 files) /usr/local/Cellar/git/2.18.0/share/man/ (171 files) /usr/local/Cellar/git/2.18.0/share/perl5/ (19 files) /usr/local/Cellar/git/2.18.0/share/zsh/ (2 files)やっぱりちゃんとあるやん！ バージョン2.18.0・・・？雲行きが怪しくなってきた。
gitコマンドのショートカット（エイリアス）ではなくフルパスを指定して複数のGitのバージョンを確認
ターミナル$ /usr/bin/git --version git version 2.20.1 (Apple Git-117)ターミナル$ /usr/local/bin/git --version git version 2.22.0バージョンからしてもgitコマンドは
/usr/local/bin/gitを向いていることを再度確認。
brew upgrade gitしたときにエラーがなかったかもう一度確認ターミナル$ brew upgrade git ==> Upgrading 1 outdated package: git 2.18.0 -> 2.24.0_2 ==> Upgrading git ==> Installing dependencies for git: pcre2 ==> Installing git dependency: pcre2 ==> Downloading https://homebrew.bintray.com/bottles/pcre2-10.34.mojave.bottle.tar.gz ==> Downloading from https://akamai.bintray.com/9b/9bc0815c6c4c584ef16e93e5ecf37aa786303d88f9321274a29b4f60876d583f?__gda__=exp=1575368945~hmac=5a828a3607 ######################################################################## 100.0% ==> Pouring pcre2-10.34.mojave.bottle.tar.gz ? /usr/local/Cellar/pcre2/10.34: 230 files, 5.9MB ==> Installing git ==> Downloading https://homebrew.bintray.com/bottles/git-2.24.0_2.mojave.bottle.tar.gz ==> Downloading from https://akamai.bintray.com/34/343c1a0b842b84095aa0632ea7ca3f1717103fe4f393a6014c7f6165b079c849?__gda__=exp=1575368950~hmac=f533430d65 ######################################################################## 100.0% ==> Pouring git-2.24.0_2.mojave.bottle.tar.gz Error: The `brew link` step did not complete successfully The formula built, but is not symlinked into /usr/local Could not symlink bin/git Target /usr/local/bin/git already exists. You may want to remove it: rm '/usr/local/bin/git' To force the link and overwrite all conflicting files: brew link --overwrite git To list all files that would be deleted: brew link --overwrite --dry-run git Possible conflicting files are: /usr/local/bin/git -> /usr/local/git/bin/git （〜中略〜） /usr/local/share/man/man7/gitworkflows.7 -> /usr/local/git/share/man/man7/gitworkflows.7 ==> Caveats Bash completion has been installed to: /usr/local/etc/bash_completion.d zsh completions and functions have been installed to: /usr/local/share/zsh/site-functions Emacs Lisp files have been installed to: /usr/local/share/emacs/site-lisp/git ==> Summary ? /usr/local/Cellar/git/2.24.0_2: 1,547 files, 45.1MB Removing: /usr/local/Cellar/git/2.10.2... (1,445 files, 31.8MB) Removing: /usr/local/Cellar/git/2.18.0... (1,488 files, 35.5MB) ==> Checking for dependents of upgraded formulae... ==> No dependents found! ==> Caveats ==> git Bash completion has been installed to: /usr/local/etc/bash_completion.d zsh completions and functions have been installed to: /usr/local/share/zsh/site-functions Emacs Lisp files have been installed to: /usr/local/share/emacs/site-lisp/gitエラー内容書いてあったーーー！！
ターミナルError: The `brew link` step did not complete successfully The formula built, but is not symlinked into /usr/local Could not symlink bin/git Target /usr/local/bin/git already exists. You may want to remove it: rm '/usr/local/bin/git' To force the link and overwrite all conflicting files: brew link --overwrite git要するに、
/usr/local/bin/gitに対してgitコマンドのシンボリックリンク（ショートカットのようなもの）を作成しようとしたけど対象がすでに存在するため、エラーになってシンボリックリンク作れなかったよ、ということのようだ。
「対象ファイルを削除したいときはこうしてね」とrmリムーブのコマンドが親切に書かれているが、その次に書かれたbrew link --overwrite gitのコマンドでシンボリックリンクの上書きをすれば良さそうである。シンボリックリンクのオーバーライトを実施
ターミナル$ brew link --overwrite git Linking /usr/local/Cellar/git/2.24.0_2... 206 symlinks created $ git --version git version 2.24.0あらためて、無事にGitのバージョンアップができました！
まとめ
- ログとエラー内容はよく読む。
- GitなどのパッケージはひとつのPCに複数インストールされている可能性がある。
- いま自分がどこに保存したどのバージョンのどのパッケージを触っているのかを把握する。
- Error: The
brew linkstep did not complete successfully ... The formula built, but is not symlinked ... というエラーはシンボリックリンクのエラーなので、内容をよく読みながら対応する。以上！
参考URL
【Homebrew】インストールしたパッケージのシンボリックリンクが作成されない場合
今さらだけどHomebrewのコマンドをちゃんと理解して使おう
【 whereis 】コマンド――コマンド本体と関連ファイルを検索する
PATHを理解して、コマンドの在りかを探してみよう (1/3)
Homebrew使い方まとめ
homebrewインストール時にリンクが貼られない問題
HomebrewでGitをインストールする
brew install nmap で発生したインストール時のエラーをchownで解決
MacのGitのバージョンをアップデート！Homebrewでの管理に切り替える
- 投稿日：2019-12-04T08:49:14+09:00
PHP-CS-FixerとGit フックで治安保持活動
こちらはJoolen Advent Calendar 2019 8日目の記事です。
カレンダーのURLはこちら
Joolen Advent Calendar 2019まえがき
PHPを書いてるとコーディング規約とか守らない人出てきますよね。
私も気付かず破ってしまうことがあります。
それを防ぐためにPHP-CS-FixerとGitフックを利用して治安を保持を目指します。PHP-CS-Fixerとは
コードの整形ツールと呼ばれるものです。
.php_cs.distという設定ファイルにルールを記述することで、コマンド一つでルールに沿ったコードに整形してくれます。
ルールはPHPの配列形式で設定します。
またFinderと呼ばれるものもあり、こちらを設定すると、整形して欲しくないファイルやディレクトリを指定できます。例:
.php_cs.distreturn PhpCsFixer\Config::create() ->setRiskyAllowed(true) ->setRules([ ... 'array_syntax' => ['syntax' => 'short'], // 配列の書き方を'short'にする ... ]) ->setFinder(PhpCsFixer\Finder::create() ->exclude('vendor') ->in(__DIR__) );実行結果
- $arrRet = array(); + $arrRet = [];同じようなツールにPHP_CodeSnifferというツールもあります。
こちらはphpcs.xmlという設定ファイルに記述する形式になります。
こちらに関しては今回は触れません。Git フックとは
Gitには発生したアクションに応じてスクリプトを実行する仕組みがあります。
これがGit フックです。
実行するスクリプトはGitディレクトリ(普通は.git)内のhooksディレクトリフック名をファイル名にした状態で格納されます。(.git/hooks/pre-commit等)
フックはクライアントサイドフックとサーバーサイドフックの2グループに分けられます。
公式ドキュメント
pre-commitやcommit-msgなど多くある中で、今回はpre-commitフックを使用します。
pre-commit
- コミットメッセージが入力される前に実行されます。
- このフックがゼロでない値を返すと、コミットが中断されます。
- この検査は git commit --no-verify で飛ばすこともできます。
- ここではコーディングスタイルの検査（lintを実行するなど）や、行末の空白文字の検査（デフォルトのフックがまさにそうです）、新しく追加されたメソッドのドキュメントが正しいかどうかの検査といったことが可能です。
PHP-CS-Fixerのインストール
composerを利用してインストールします。
$ composer require --dev friendsofphp/php-cs-fixer ... $ vendor/bin/php-cs-fixer -V PHP CS Fixer 2.16.1 Yellow Bird by Fabien Potencier and Dariusz RuminskiPHP-CS-Fixerの設定を行う
早速設定をしていきたいところですが、PHP-CS-Fixerの設定を全てやっていると膨大な時間がかかります。
そこで、設定をパッケージ化して公開してくれている方がいるので、自分にあった物を見つけて利用しましょう。
私が公開しているものやhttps://github.com/suin/php-cs-fixer-rules
などありますので、探してみてください。探して無事インストールできたら、今度は設定を少々変えていきましょう。
ほとんどのパッケージはルールが上書きできるようになっているはずです。
php-cs-fixer-configuratorを参考にして、設定を書き換えていきましょう。整形予定の確認。 そして整形
設定が完了したら整形！
といきたいところですが、その前に整形予定を確認して、設定の間違いがないか以下のコマンドで確認しましょう。$ vandor/bin/php-cs-fixer fix --dry-run --diffこちらのコマンドは
fixによって設定ファイルに沿って整形
--dry-runオプションによって整形せず整形予定ファイルの表示
--diffオプションによって整形内容の表示となっています。実行して予期せぬ変更がなければ以下のコマンドで実際に整形します。
$ vandor/bin/php-cs-fixer fixpre-commitフックでPHP-CS-Fixerを実行
PHP-CS-Fixerによる整形ができるようになったので、最初に紹介したpre-commitフックを利用して整形前のコードがコミットされないようにします。
.git/hooksディレクトリにpre-commitという名前でファイルを作成します。
$ touch .git/hooks/pre-commit作成したファイルを修正してPHP-CS-Fixerを実行するようにします。
pre-commit#!/bin/bash # ディレクトリ定義 ROOT_DIR=$(git rev-parse --show-toplevel) LIST=$(git status | grep -e '\(modified:\|new file:\)'| grep '\.php' | cut -d':' -f2 ) # php-cs-fixer error=false for file in $LIST do # --path-modeをintersectionにすることで、Finderが無視されないようにします。 $ROOT_DIR/vendor/bin/php-cs-fixer fix --path-mode=intersection --dry-run $ROOT_DIR/$file > /dev/null 2>&1 if [ $? != 0 ]; then echo -e " please, cs fix to $ROOT_DIR/$file" error=true fi done if "${error}"; then echo echo -e "\033[31mCommit fail\033[m please run \"vendor/bin/php-cs-fixer fix\" command" exit 1 fiこれで、規約を無視したコードをコミットしようとすると以下のように表示されるようになります。
please, cs fix to /path/to/invalid-file.php Commit fail please run "vendor/bin/php-cs-fixer fix" commandこれで治安保持できるようになりました！
コーディング規約にそってないコードは精神衛生上よろしくないので、駆逐していきましょう！明日は@joolenkoyamaさんのEC-CUBE4のContainerの探検記録です。
- 投稿日：2019-12-04T01:57:31+09:00
筋肉マージは辞めよう
追記2 2019/12/04 21:00
こんなよくわからない記事をご覧いただきありがとうございます。
この事件を起こしたのは1年前で、Gitを使いはじめて1ヶ月のときに下記の事件を起こしてしまっていてとても混乱していたのを当時覚えています。
内容については、rmをしたかもしれないという記事に結果的になったかもしれませんが、私の記憶ではファイルを消した記憶はありません。
ただ、当時作業していたディレクトリもないのでコマンドを確認する手段がないため一番濃厚なrmをしたというのを今回の結論にしました。
曖昧さは申し訳ありません。
また、意見、感想、批評には全て目を通させております。伝わりにくい内容やわかった事実は適宜編集してできるだけ皆さんに伝わるよう善処いたしますのでどうぞよろしくお願いします。
追記2ここまで追記 2019/12/04 13:00
1.本番環境でやらかしちゃった人 Advent Calendar 2019で本番環境でないのではないかということですが、私自身は
文章をpushしたら本(原稿)ができあがるって本番環境じゃないか？と考え、申し込みました。
しかし、皆さんが考える本番環境の認識とは違うのではないかと考えています。
今回の件は申し訳ありません。もし、取り消すもしくは差し替えをする場合は下記コメントに連絡のほどよろしくお願いします。2.友達に手伝ってもらい調査をした結果をまとめましたので修正させていただきます。申し訳ございません。
しかし、1年前のことだったり、ローカルに作業していたディレクトリがなかったり確信は持てませんので予めご了承ください。追記ここまで
こんにちは。ぽちゃまと申します。
皆さんが投稿しているような本番環境ではないのですが、技術書典で共同執筆していたときにやらかした話です。筋肉マージとは
自分でPRを立てる -> 自分でPRを承認してマージする
のように、チーム管理なのに一連の流れを自分の判断(権利)でやってしまうこと。
権利がある(偉い)を言い換えると、筋肉があるだと考えています。
なので、今回は自身の権限を行使してマージをした、すなわち筋肉を使ってマージをしたので
筋肉マージとしています。
(セルフマージと同じと考えていただいて構いません。インパクトの問題で筋肉マージと名付けました)やらかしちゃった(ﾉω・)ﾃﾍ
時は2019年2月8日22:50のことだった。
自分の担当の記事を書いてPRを立てた。
しかし、レビューをお互いにする時間まで後10分もなかったため自分でレビューをして自分でマージをする、権限を行使する、すなわち筋肉を使ってマージをした。
これからの一連の動作を筋肉マージと呼ぶ。
そしたら、他の人のファイルが消えた。
↑これは慌ててる僕。結局、別の人にあったPRを出した状態のやつがローカル環境にあったのでそれをソイヤして
一部コミットを良い感じに出来なかったなんとかなりました。惨劇はなぜおこってしまったのか(#´Д｀)
PRを自分でマージする前にブランチを最新にしていなかったのが原因でした。
みんな各々pullしてMergeされたらpullしてをちゃんとしていたのですが、僕はそれを怠っていました。
しかも、ちゃんとレビューしてもらえば防げたのに自分でマージをするという筋肉を発揮してしまったので、今回の惨劇がおこってしまいました。
友達の@onokatioに手伝ってもらい改めて考えられる原因を書かせていただきます。原因
1.自分でrmをした。
名前が乗っているのでPR名は隠しましたが、ファイルがここで消えています。
まだ知識がなかったので差分ということでrmをしてしまった可能性があります。
しかし、rmをしたかどうかは覚えていなくて、どれくらいの曖昧かというと、テストのときに答えに−をつけたかどうかの曖昧さです。
もし、これが原因だったらごめんなさい。2.ブランチを切らずにmasterで作業して作業の結果をmaster以外のブランチにpushした
タイトル通りに最初にmasterにいると思わずにmasterで作業をし、作業後にmaster以外のブランチにpushをしてしまった
結論は1と変わらないです。3.マージミス
最初に挙げていたマージミスです。でも、一番ありえるのは自分でrmをしてそれを基盤に作業したが濃厚です。
やってしまった...
二度と惨劇を起こさないためにどうしたのか(｡•́︿•̀｡)
(今回の原因がマージミスの場合)
- ブランチは常に最新にする
- マージをするときはPRの内容、差分をしっかりと見る
- レビューをきちんとしてもらう。
(今回の原因が
rmによる削除だった場合)
- ファイルをやたらrmしないようにする。
- addするファイルをきちんと指定する。
- 今いるブランチがどこなのか、差分はどうなっているのかをきちんと確認する。
(全体で言えること)
- 自分は大丈夫と慢心してはいけない。
- やらかしたらすぐに謝る。
- チーム開発の場合はしっかりと他のメンバーにレビューしてもらう。
- 自分の判断でマージなどの重要なことをやらない。
もし筋肉マージをして同じようなことが起こった場合
また、もし筋肉マージなど似たようなやらかしをしてしまい、同じようなことが起こった場合の修正方法も書いておきます。
他にも方法がありましたら編集リクエストで追加していただけたら幸いです。別のメンバーのPR出したときのローカル環境をpushしてもらう。
今回はPRを最近出したままのメンバーがいた+そのPR後にPRは僕のしかないという状況があったので、別のメンバーの環境を再度pushしてもらい、マージをしました。
revertする
@5ym さんより
git checkout master git pull git checkout -b revert git revert HEAD^ git push origin HEAD # revertブランチをmasterにマージ git checkout master git pull git checkout ミスマージしたブランチ git merge master git push origin HEAD # 再マージgit reset する
これを書いて修正方法を調べていた時に以下のサイトにこのようなことが書いてありましたので共有させていただきます。
(ただし、これはcliでマージをした時の場合です。)# マージする。 $ git checkout <マージ先ブランチ> $ git merge <マージ元ブランチ> # マージしたあと、やっぱやめよって思ったらこれをやる # ORIG_HEADを指定すればマージ前に戻る $ git reset --hard ORIG_HEAD終わり
以上です。これを機に反復確認をするくらい落ち込んでました。
あの時はごめんなさい。
また、技術書典6で無事"#kosen16s"として販売が終了し、今Boothで売っているので気になった方は見てみて下さい！
これで僕のやらかし記事は終わります。少しでも役に立てたら幸いです。何かありましたら、Twitterまでご連絡下さい。
- 投稿日：2019-12-04T01:55:37+09:00
Git SubmoduleでのやらかしとGit Submoduleとうまく付き合うために
この記事はAteam Hikkoshi Samurai Inc. & Ateam Connect Inc.（エイチーム引越し侍、エイチームコネクト） Advent Calendar 2019 4日目の記事です。
本番環境でやらかしちゃった人 Advent Calendar 2019が人気ですね。おはこんばんにちは。
?このカレンダー程ではないですが、私もやらかした事があります。Git Submoduleで。
今回はそれについて何が起こったのか、どう対策したのかと簡単に説明した後、
Git Submoduleを使う上でよく使うコマンドについて説明します。はじめに
Gitについて学びたい方には以下をお勧めします。
https://git-scm.com/book/ja/v2
上記のSubmoduleについてのページは以下です。(おそらくこの記事よりも参考になるかと思います)
7.11 Git のさまざまなツール - サブモジュール背景
弊社ではサービスによってリリースする方法として、Deployボタンをポチっと押す簡単なものから、複数の手順を踏んでリリースをするものまで複数あります。
また、リリースはエンジニアなら誰でもできるわけではなく、一部のメンバーのみができるような権限管理がされています。
Git Submoduleのやらかしは、複数の手順を踏んでリリースするものでの出来事です。とあるチケットのリリース作業
いつものように開発フローを進みリリースができる状態となったプログラムのリリース作業を進めていました。
別の開発者が開発し、私がコードレビューし、私がリリースを行うタイプでした。
一通りの確認作業を実施し、本番環境へのリリースを完了しました。
リリースを完了した直後、エラー通知がひとつ、またひとつと届くのを確認しました。
リリースによる負荷でエラーが発生することもあるのでその時点ではそれ系かな？と思いつつエラー通知を確認しました。
そこには今まで見たことのないタイプのエラー通知が来ており、一目で
あ
あ!ヤバいやつだ!!とすぐに分かったので担当者と一緒にリリースしたものの切り戻し作業を実施しました。
5分程度で切り戻しが完了し、次は何が原因だったのかを確認する作業を始めました。何が起こっていたのか
本来Submoduleが参照すべき先が過去に巻き戻ってしまっていた事が原因です。
(Git Submoduleの仕組みを使った事がある方にとってはあるあるな事なのかもしれません)
リリースする手順の中にDiffの確認をする手順も含まれており、そこにSubmoduleのDiffも出ていたのですが、それを私が見逃してしまっていました。
そのDiffを見逃してしまった結果、本番環境で問題を発生させてしまう結果となったのです。何が原因だったのか
まず、本件における責任はリリースを実施した私にあります。リリースをするという役割を持つ事はその結果起こりうることへの責務を負うことに繋がるからです。
原因としては以下があると考えました。
- 開発者がSubmoduleの向き先変更をPushしたコミットへ含めてしまっていた
- リリース手順の差分確認の際、Submoduleの向き先変更が含まれていることに気づくことができなかった
詳細は割愛しますが、この時は 2. についての対策を実施しました。
行った対策
今までの手順では、通常のコードの差分と同時にSubmoduleのDiffも確認していました。
それを、Submoduleの変更があった場合は、そのSubmoduleの向き先ががSubmodule自身のMasterと等しいかのチェックをリリース時の処理に追加しました。改善されたフローと新たな課題
上記の対策を実施した結果、Submoduleが最新出ない場合は確認のダイアログが表示されるようになり、Submoduleの向き先を誤って変更してしまうという種類のミスは発生していません。
しかし、なにかのリリースでSubmoduleの向き先を更新するとそのSubmoduleを参照している別Projectもリリースする必要が出てきたため、リリースに時間がかかるようになってしまいました。ここは要改善点です。
Git Submoduleにおけるケース別操作例ここから
Git Submoduleについての説明と、主な対応方法について説明します。
はじめに、でも言及しましたが、7.11 Git のさまざまなツール - サブモジュールを読むこともお勧めします。
以下からは、私の理解を私がわかりやすいと思う言葉を使って説明していますので、一部正確ではない部分、または間違っている部分があるかもしれません。その点ご留意ください。Submoduleとはある Git リポジトリを別の Git リポジトリの共通モジュールとして扱うための仕組みです。
Git Submoduleを使うことで何が嬉しいのかサービスやプロジェクトを跨いで使用するような共通処理をSubmodule化することで一元管理ができるようになります。
便利な仕組みですが、その簡単さ故、人為的なミスも起こりやすいです。
以下に遭遇しうるパターンとその際に実施すべきコマンド例を上げます。対象のプロジェクトで使用されているSubmoduleの確認方法
# 任意のプロジェクト直下 git submodule status 586857a3fa26c271eacb1e8a845fabef79b6fb2a sub/module1 (remotes/origin/HEAD) da489da68e9f753d3d5c3da53eca68c9c0f559ab lib/common_submodule2 (remotes/origin/HEAD)※リポジトリ直下の
.gitmodulesの中身を確認することでもSubmoduleの確認が可能です。Submoduleでdiffが出たとき
git pullやgit mergeで最新の更新を取り込んだ際に、(master *)の様に差分がでることがあります。git diff diff --git a/sub/module1 b/sub/module1 index 6a55aa29..8d4c117cb 160000 --- a/sub/module1/ +++ b/sub/module1/ @@ -1 +1 @@ -Subproject commit a8e3a94836ec75bb36539c29652fc844cbfa072d +Subproject commit e5546365dffd2d5d34d0ab8f5923f61496007358
git submodule updateについて
git submodule updateはgit pullなどで最新の更新を取得した際などに、
自身の環境のSubmoduleが向いている向き先を取得した更新をもとに参照すべき向き先へ変更するコマンドです。
git diffでSubmoduleの変更が出た際は、多くの場合git submodule updateで差分を解消することが必要です。Submoduleの変更をaddする場合
Submoduleの変更を
git addしてgit commitする時とはどういう場合でしょうか。
それは、自身がそのSubmoduleを変更しその向き先へ合わせる場合、または別の開発で更新された向き先へ合わせるために更新する場合などです。
Submoduleの向き先の変更のaddとcommitについては、何らかの手段で制限をすることを推奨します。前述したように、あまりにも簡単に向き先を変更できるためです。
日々の開発において、Submoduleの向き先の変更に気づかずにcommitしてしまう、というミスが起こりえます。人間はミスをする生き物です。なのでミスをするという前提で考えましょう。私がいるプロジェクトでは、Submoduleの変更をそのままcommitすることはできません。
Gitの仕組みの一つであるpre-commitでSubmoduleの変更がcommitされようとしていたらRejectする仕組みを採用しています。終わりに
私がなにかを学ぶ時、特にミスをしない方法を学ぶタイミングは大抵そのミスを犯してしまった時です。なぜそのミスが起こったのか、どう対策をしたのか、その結果そのミスの発生率はどうなったのか、を残すことで1人でも同じ轍を踏む人が少なくなればと思います。
また、本記事を読まれた方ならなんとなく分かるかもしれませんが、まだまだ課題や改善すべき点が本件以外にも多くあります。そのような課題を解決したい!俺が解決してやる!という気概のある方はぜひ?下記をご参照ください。お知らせ
エイチームグループでは一緒に活躍してくれる優秀な人材を募集中です。
興味のある方はぜひともエイチームグループ採用ページ（Webエンジニア詳細ページよりお問い合わせ下さい。
あるいは、Qiita Jobsの引越し侍Webエンジニアチーム、自社サービスWebエンジニア／インフラからサービス改善まで！、求む！引越し侍大規模リプレイスにおけるフロントエンドのリードエンジニア募集！の記事をみて、興味が出てきた方は是非Qiita Jobsのチャットでメッセージをください。明日
明日は最近マネージャー業務が忙しくコードを書く時間がなかなか取れないと嘆いているkekiの記事です。
お楽しみに！
- 投稿日：2019-12-04T01:29:40+09:00
terminalのコマンドを実行してGithub Pagesでサイトを公開する方法
自分でちょっとつまづいて、忘れそうなので備忘録として書き残しておきます。
Github Pagesでサイトを公開する方法です。
Github Pagesでポートフォリオサイトを作成したけど、GithubDesktopでGitHubへプッシュするときに下記のエラーメッセージが出て、プッシュができないという状況になりました。
どうしようかと思って色々調べていると、ターミナルから下記のコマンドを実行したら、プッシュができました。
リポジトリにコミット
$ git add --all
$ git commit -m "任意のメッセージ"
GitHubへプッシュ
$ git push -u origin master
パスワードを入力して、実行できました。
- 投稿日：2019-12-04T01:29:40+09:00
ターミナルのコマンドを実行してGithub Pagesでサイトを公開する方法
自分でちょっとつまづいて、忘れそうなので備忘録として書き残しておきます。
Github Pagesでサイトを公開する方法です。
Github Pagesでポートフォリオサイトを作成したけど、GithubDesktopでGitHubへプッシュするときに下記のエラーメッセージが出て、プッシュができないという状況になりました。
どうしようかと思って色々調べていると、ターミナルから下記のコマンドを実行したら、プッシュができました。
リポジトリにコミット
$ git add --all
$ git commit -m "任意のメッセージ"
GitHubへプッシュ
$ git push -u origin master
パスワードを入力して、実行できました。