20190301のGitに関する記事は8件です。

gitとgithubの使い方を流れでまとめた備忘録

はじめに

gitとgithubを使った開発を最近始めました.
何も分からなかったので調べたことを備忘録として書いておきます.

前提知識

ローカルリポジトリとリモートリポジトリ

簡単にいうと、PCがローカルでgithubがリモート

branch

branchは枝なので幹から生やすことができる.
共有データ(幹)からbranch(枝)を新しく生やして(=複製)、そこを編集する.
作業が終わったら枝を幹に戻すことになるが、データが衝突する可能性があるので、管理者以外はくっつけるのを申請するまでやる.
ちなみにこの枝をくっつけることを「マージ」と言うらしい.

最初だけやること

新規リポジトリのドアを叩くときは、色々準備が必要らしい.

自分がリポジトリを作る場合

今回、私はこの範疇にありませんでしたので書きません(書けません).
方法はたくさんネットに転がってました.

既存リポジトリに参加する場合

$ git clone -b <branch_name> <repogitory_url>

これでカレントディレクトリにgithubのデータをローカルに落とせる.
branchによってデータが違う. ほとんどの場合masterをcloneしておけば良い気がする.
最初に選択されるbranchはこの時のbranch_nameだと思う.

普段の作業の流れ

一度cloneしてからはこっちでいいらしい.

  1. ローカルの状態を更新する
  2. branchを作成する
  3. branchを切り替える
  4. 作業する
  5. 作業内容をローカルリポジトリに反映する
  6. localのremoteへの反映をお願いする

作業を始めるまで

$ git pull #ローカルリポジトリを更新
$ git branch <branch_name> #ブランチを作成
$ git checkout <branch_name> #ブランチを切り替える
-----
$ git branch #ブランチ一覧表示(現在のbranchも確認できる)

git pullでローカルリポジトリ(pc)を更新できる(=リモートリポジトリ(web)の更新を反映する).
更新されるのは現在選択中のbranchなので、branchをmasterにしておく. git branchで現在ローカルにあるbranchを確認できる.
git checkout <branch_name>でmasterから脱しないと大変なことになりそう.

作業内容を反映する

作業が一通り終わったらリモートリポジトリへ、更新をお願いする.
作業内容はローカルリポジトリでは無く、また別の場所に保存されているので、

  1. 作業内容 → ローカルリポジトリ
  2. ローカル → リモート(の申請)

という流れになる

$ git add * #全部ファイルをadd
$ git commit -m "編集コメント" #branchを更新、編集内容をコメントで
$ git push --set-upstream origin <branch_name> #初めてpushする時だけ
$ git push #現在選択中のbranchをgithubに送る

正直にいうとあまり理解できていないのだが、
add+commitでローカルのbranchに作業内容が反映されるっぽい.
commitのオプションで-mしなければ、commitコマンドの後にその編集画面になるけど
git pushでリモートにローカルのbranchを送れる.

確認をお願いする

あとはwebページ上で、プルリクエスト(マージリクエスト)をすれば管理者に更新をお願いしたことになる.

跡を濁さない

$ git branch -d <branch_name> #branchの削除(マージ済みのみ)
$ git branch -D <branch_name> #branchの削除(強制削除)

もう使わないbranchは削除したほうが良さそうな気がする.

special thanks

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

githubの使い方を流れでまとめた備忘録

はじめに

gitとgithubを使った開発を最近始めました.
何も分からなかったので調べたことを備忘録として書いておきます.

前提知識

  • ローカルリポジトリとリモートリポジトリ
    簡単にいうと、PCがローカルでgithubがリモート
  • branch
    branchは枝なので幹から生やすことができる. 共有データ(幹)からbranch(枝)を新しく生やして(=複製)、そこを編集する. 作業が終わったら枝を幹に戻すことになるが、データが衝突する可能性があるので、管理者以外はくっつけるのを申請するまでやる. ちなみにこの枝をくっつけることを「マージ」と言うらしい.

最初だけやること

新規リポジトリのドアを叩くときは、色々準備が必要らしい.

自分がリポジトリを作る場合

今回、私はこの範疇にありませんでしたので書きません(書けません).
方法はたくさんネットに転がってました.

既存リポジトリに参加する場合

$ git clone -b <branch_name> <repogitory_url>

これでカレントディレクトリにgithubのデータをローカルに落とせる.
branchによってデータが違う. ほとんどの場合masterをcloneしておけば良い気がする.
最初に選択されるbranchはこの時のbranch_nameだと思う.

普段の作業の流れ

  1. ローカルの状態を更新する
  2. branchを作成する
  3. branchを切り替える
  4. 作業する
  5. 作業内容をローカルリポジトリに反映する
  6. localのremoteへの反映をお願いする

作業を始めるまで

$ git pull #ローカルリポジトリを更新
$ git branch <branch_name> #ブランチを作成
$ git checkout <branch_name> #ブランチを切り替える
-----
$ git branch #ブランチ一覧表示(現在のbranchも確認できる)

git pullでローカルリポジトリ(pc)を更新できる(=リモートリポジトリ(web)の更新を反映する).
更新されるのは現在選択中のbranchなので、branchをmasterにしておく. git branchで現在ローカルにあるbranchを確認できる.
git checkout <branch_name>でmasterから脱しないと大変なことになりそう.

作業内容を反映する

作業が一通り終わったらリモートリポジトリへ、更新をお願いする.
作業内容はローカルリポジトリでは無く、また別の場所に保存されているので、↓の流れになる

  1. 作業内容 → ローカルリポジトリ
  2. ローカル → リモート(の申請)
$ git add * #全部ファイルをadd
$ git commit -m "編集コメント" #branchを更新、編集内容をコメントで
$ git push --set-upstream origin <branch_name> #初めてpushする時だけ
$ git push #現在選択中のbranchをgithubに送る

正直にいうとあまり理解できていないのだが、
add+commitでローカルのbranchに作業内容が反映されるっぽい.
commitのオプションで-mしなければ、commitコマンドの後にその編集画面になるけど面倒なので、一言コメントを同時に書いてしまおうと思う.
git push (引数)でリモートの(引数branch)にローカルのbranchを反映できる.
引数を与えない場合は、checkoutしているbranchが対象となる.

確認をお願いする

あとはwebページ上で、プルリクエスト(マージリクエスト)をすれば管理者に更新をお願いしたことになる.

跡を濁さない

$ git branch -d <branch_name> #branchの削除(マージ済みのみ)
$ git branch -D <branch_name> #branchの削除(強制削除)

もう使わないbranchは削除したほうが良さそうな気がする.

special thanks

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Gitのやり方 Pushまで

Gitの登録からPushまで
こちらが参考になります。
https://qiita.com/KosukeQiita/items/cf39d2922b77ac93f51d

Gitで fatal: remote origin already exists. というメッセージが出る場合
こちらを参照すれば出来ます
http://pyoonn.hatenablog.com/entry/2014/10/29/191744

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Gitを2.21.0にアップデートしたらcloneできなくなった話(fatal: multiple updates for ref 'refs/remotes/origin/master' not allowed)

現象

Mac用パッケージ管理ツールのHomebrew経由でGitを2.21.0(2月24日リリース)にアップデート。
GitHubからソースを落としてくるべく、git cloneを実行したら次のエラーが発生。

fatal: multiple updates for ref 'refs/remotes/origin/master' not allowed

Gitの管理下ではないディレクトリでcloneしても発生するからよくわからない。

解決方法

Gitのglobal設定が保持されている~/.gitconfigから[remote "origin"]に関する記述を削除したら解消。

##### 変更前 ######

[user]
    email = *****
    name = *****
[http]
    postBuffer = 2M
[core]
    excludesfile = /Users/xxxxx/.gitignore_global
    editor = vim
[remote "origin"]
    fetch = +refs/heads/*:refs/remotes/origin/*
##### 変更後 ######

[user]
    email = *****
    name = *****
[http]
    postBuffer = 2M
[core]
    excludesfile = /Users/xxxxx/.gitignore_global
    editor = vim

最後に

[remote "origin"]の設定が2.21.0のバージョンアップの際に追加されたのか、それとも旧来からある設定がこのバージョンアップで悪さをするようになったのかは不明。
とりあえずは問題なく動いているので良かったがモヤモヤする……

備考

2019/03/01:諸事情により再投稿しました

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

gitguiでpush時に「permission」と出る場合の解決法

二つのgithubアカウントを切り替えて使うと、片方が片方に対してパーミッションがないので
エラーになります。

下記でデフォルトのユーザを消すと解決できます。Windows10

コントロールパネル→ユーザアカウント→資格情報の管理→Windows資格情報→githubの情報を消します。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Gitで毎回パスワードを聞かれないようにする

GitHubのリモートをhttpsにしていると、git pushなどの実行時に

Username for 'https://github.com': 
Password for 'https://github.com': 

といった形で毎回情報の入力を求められてしまいます。

そういった際は

git config --global credential.helper cache

を実行すると、次に入力した認証情報が保存されるようになります。

VirtualBox:~$ git push
Username for 'https://github.com': Aqua-ix
Password for 'https://Aqua-ix@github.com': 
Everything up-to-date
VirtualBox:~$ git push
Everything up-to-date
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

gitのpushに紐づけてS3へのアップロードとcloudfrontのキャッシュ削除を自動で行う

注意:うろ覚えなんで手順抜けてる可能性あります。

背景

aws s3の静的ホスティングでサイトを公開している。最初はいちいちコンソールで上げてたが、流石にめんどくさすぎるので自動化したかった。サイト自体はgitで管理してたので、gitと連携して自動アップロードできないかなぁって調べたらCodeshipってサービスでできるらしいと知ったので使って自動化した。ついでにcloudfrontのキャッシュ削除も。

codeship

githubやbitbucketと連携してpushと連動してサーバのビルドとかができるらしいです。
aws s3とも連携できてBucket名を指定すればアップロードしてくれます。
月100回のビルドまで無料らしいです。

設定手順

codeshipアカウントの準備

https://codeship.com/
トップページのSign upを押すと上の欄にgitのホスティングサービスが出てくるので自分が使ってるやつを選びます。(自分はbitbucket)
多分認証画面みたいなのが出てくるのでOKを押して、あとは必要事項を入れてsign up

新しいProjectを作る

最初のログインのときにプロジェクト作成画面が出ます。
飛ばしてもあとから作れます。
下側の入力欄にbitBuketの自動アップロードしたいリポジトリの「クローンの作成」でコピーできるURLを貼ります。
この時自分はエラーが出ました。
bit.png
bitbucket側でpipelinesを使うことを許可する設定を行わないとだめっぽいです。
bitbucketだとリポジトリの設定の一番下のPIPELINESのSettingのEnable Pipelinesのチェックをつけたら行けました。多分他のサービスでも似たような設定項目があると思います。
びt.PNG
次にプロジェクトタイプを選びます。s3へのアップロードとcloudfrontのキャッシュ削除だけならbasicでいいです。というかproだとお金取られるのかな?(わからない)
pro.PNG

Projectの設定

Projectの作成が完了したらこんな画面が出てくると思います。上の項目のDeployを選びます。
dep.PNG
パイプライン(ビルドの手順のことをこう呼ぶらしい)でデプロイするブランチを設定します。この項目はよくわかってません。指定したブランチにプッシュされた時にトリガーするって設定かと思ったら初期設定だと他のブランチにプッシュしてもビルドが動いてました。ビルドするデータの場所……?とりあえずgit側でデプロイ用のブランチ作ってその名前と同じにしました。
up.PNG

s3へのアップロード

まずはs3の項目を選択。
s3.PNG
s3の設定。AWS Access Key ID、AWS Secret Access Keyはs3の権限(AmasonS3FullAccess)を持ってるIAMユーザのものを使用します。新しく作るなら後でつかうのでcloudfrontの権限(CloudFrontFullAccess)も持たせておくといいです。AWS Secret Access Keyは後でも入力するのでちゃんと保存しておいてください。IAMの設定は割愛します。AWSのドキュメントを参照して下さい。
Regionリージョン対応表を見て合うものを選択してください。東京ならap-northeast-1です。
local Pathはgit上のアップロードしたいファイルがあるフォルダを指定します。
S3 Bucketはアップロード先のBucket名を入れてください。
ACLはprivateでいいと思います。(よくわかってない)(権限関連だからよくわかってないのは危なそう)(資料読む限りprivateなら許可された人のみアクセスできるからこれでいいっぽい?)
s3r.PNG
設定ができたら下の画像のように表示されます。これでs3へのアップロードの設定は完了です。次はcloudfrontのキャッシュ消去です。
yuaz.PNG

cloudfrontのキャッシュ消去

cloudfrontは連携できないのでaws cliを使って行います。codeshipに標準で入ってます。Custom Scriptを選びます。
こんd.PNG
deployment commandsには
aws cloudfront create-invalidation --distribution-id クラウドフロントのディストリビューションのアイディ --paths "/*"と書きます。ID(アイディ)は下の画像の赤丸の部分のことです。"/*"の部分は消去したいキャッシュの場所です。注意点として*(アスタリスク)を使う場合は""(ダブルクォーテーション)で囲む必要があります。

↓AWSコンソール画面↓
cl.PNG
↓custom scriptの設定画面↓
ぢs.PNG

次にaws cliで使うアクセスキーの設定をします。
上のメニューのEnvironmentを選びます。
enn.PNG

Environment VariablesにIAMのアクセスキーを追加します。keyにAWS_ACCESS_KEY_ID、AWS_SECRET_ACCESS_KEYと入力してValueにそれぞれの値を入力してください。内容はs3で設定したときと同じです。cloudfrontのアクセス権(CloudFrontFullAccess)を持ってるユーザじゃないとだめです。

↓流石に雑消しじゃ怖いのでキーは映してません。右側にvalueがあります。↓
あc.PNG

build triggerの設定

初期設定だと、どのブランチにプッシュしてもビルドが走ってしまいます。
デプロイ用のブランチにプッシュしたときのみビルドを走らせたいので設定を変更します。
上のメニューのBuid Triggersを選びます。
bt.PNG
この項目はお好みで(特定のブランチのみを指定するならRun builds for these branches onlyをえらんでEnter one branch per lineにそのブランチ名を書けばOKです)正規表現も使えるらしい。
sete.PNG

実行

指定したブランチにプッシュするとビルドが始まるはずです。Projectトップを見るとビルド中の情報が見れます。成功したら以下のようにSUCCEEDEDと出ます。失敗したらFAILEDと出てどのステップで失敗したか、どういうエラーが出たかが見れます。設定を修正したら赤丸のRestart buildでもう一度実行できます。最初は一応s3とcloudfront、自分のサイトが更新されているかを確認しましょう。
bbbb.PNG

終わり

これでデプロイ作業が楽になります。正直手動でアップロードとキャッシュ削除するのがめんどくさすぎてサイトの更新停滞してたのでこれでだいぶモチベ戻りました。やっぱり自動化は大事。

表記統一全然できてないな……。最初とかですます調ですらないし……。

参考

https://qiita.com/kashitaka1118/items/75954c92c0db9bf669e3
https://cwhite.me/continuous-delivery-for-your-static-site-with-codeship/

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

VSCode 環境をgit管理してどこでも同じ環境を引き継ぐ

VSCodeの環境をgit管理するメリット

  • どこでも同じ環境を使える
  • 会社で作った環境を自宅でもう一度設定しなくてよい
  • 違う端末にVSCodeをinstallしたときに一瞬で同じ環境が再現できる

なんかポータブルモードとか、Settings Syncとかあるっぽいけど。

VSCodeの環境

環境はだいたい以下の3つで構築されている。

  • settings.json : 設定全般
  • keybindings.json : キーバインド
  • extension(拡張機能)

引き継ぎ方

1. 設定ファイルをgit管理するディレクトリに移動

cd ~/Library/Application\ Support/Code/User/

ここにsettings.jsonkeybindings.jsonがある。

これをgit管理するディレクトリに移動。(自分の場合は/dotfiles/.vscode/においた)

mv settings.json "ファイルを移動したいディレクトリパス"

そして ~/Library/Application\ Support/Code/User/にそれぞれのファイルのシンボリックリンクを貼る。

ln -s "移動したファイルパス/settings.json" "~/Library/Application\ Support/Code/User/settings.json"

2. extention のリスト書き出す

code --list-extensions > extensions

ちなみにcodeコマンドが使えないときはコマンドパレットに「shell」と入力してinstallするとすぐつかえるようになる。

3. 本題、一発で環境設定するファイル

vscode_install.sh
#!/bin/sh

SCRIPT_DIR=$(cd $(dirname $0) && pwd)
VSCODE_SETTING_DIR=~/Library/Application\ Support/Code/User

rm "$VSCODE_SETTING_DIR/settings.json"
ln -s "$SCRIPT_DIR/settings.json" "${VSCODE_SETTING_DIR}/settings.json"

rm "$VSCODE_SETTING_DIR/keybindings.json"
ln -s "$SCRIPT_DIR/keybindings.json" "${VSCODE_SETTING_DIR}/keybindings.json"

# install extention
cat extensions | while read line
do
 code --install-extension $line
done

code --list-extensions > extensions

5. git管理

以下のファイルをgitにあげておく。

  • settings.json
  • keybindings.json
  • extention
  • vscode_install.sh

4. 設定インストール

設定ファイルのリポジトリをgit cloneしてきて以下を実行。

"~/ディレクトリパス"/vscode_install.sh

⚠設定ファイルがある場合は、rmで一旦設定ファイルを削除してシンボリックリンクを貼るので、引き継ぎたい設定がある場合は必ずmvしておく。


おわり。
最近入れて気に入っているextentionは「vscode-spotify」。
spotifyへの画面移動がなくなってとても快適。

その他、VSCodeを使いやすくした

参考 : https://note.mu/teitei_tk/n/n7204cb8d97c5

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む