プルリクエストでブランチをマージなど!【Githubの使い方】

プログラミング学習

Githubの使い方をまとめておきます。

Githubの使い方

Githubの公式

公式サイトはこちらです。

GitHub: Let’s build from here
GitHub is where over 100 million developers shape the future of software, together. Contribute to the open source community, manage your Git repositories, revie...

Githubの登録

登録方法は以下のとおりです。

  1. [Username]、[Email]、[Password] を入力して [Sign up for GitHub] のボタンを押す。
  2. ロボットでないことを証明する。
  3. [Next Select a plan] のボタンを押す。
  4. [Free](無料)か [Pro](有料) かを選ぶ。
  5. [Welcome to GitHub] ページで、プログラミング経験、利用目的、興味のあるキーワードを入力して [Complete setup] ボタンを押す。選ばなくてもスルーできる。
  6. メールアドレスにメールが送られてくるため、 URL をクリックする。続いてリポジトリの作成に入る

githubのリポジトリ名の決め方

  • リポジトリ名がそのままurlになるため単語はurlの慣習に従ってハイフンで区切るのが無難
  • 公開リポジトリで検索でひっかけたいのならその文字列を含ませる。あまり目立ちたくないならその逆。

githubのリポジトリの作り方

リポジトリの作り方は以下のとおりです。2回目以降はNewのボタンで画面に移動します。

  • リポジトリ名を入力する。
  • PrivateかPublicか選ぶ。Privateは非公開。
  • Initialize this repository with a README:READMEを作成するか否か。後から作れるため未チェック。
  • Add .gitignore:git で無視するファイルを指定するファイル。後から作れるためNone
  • Add a license:ライセンス設定。後から作れるためNone
  • [Create repository] でリポジトリを新規作成する。

githubのリモートリポジトリを共有用に新規でわける

外注さんなどの都合で、たまにリモートリポジトリを分けたいときがあります。

前提の作業として、github上で新規のリポジトリを作成しておきます。

あとはvscode上で確認します。

git remote -v

紐づけるリモートリポジトリのurlを変更します。

git remote set-url origin https://github.com/USERNAME/REPOSITORY.git

再び確認すると変わっています。

git remote -v

もっと詳しくみたかったら、configファイルを確認します。

cat .git/config

メールアドレスと名前を確認したい場合はこちらのコマンドで。

git config --list

あとはステージング、addはgui上でやって最後はgithubにプッシュしましょう。

gitのプッシュ(git push -u origin master)

git push -u origin master

-uは–set-upstream-toの省略形です。

-uは推奨されています。pullするとき、あれこれ聞かれるからです。-uをつけると上流ブランチになります。

git push origin master --force

pushがうまくいかないとき強制的に行う方法があります。通常はpullしましょう。

git push origin master --force-with-lease

もう少しマイルドな方法もあります。ローカルrefとリモートrefを比較してローカルが最新か否かを確認します。最新ではない場合はPUSHを失敗します。直前にfetchしているとPUSHが成功してしまうので要注意。

githubのリモートリポジトリの削除

github上でいらないリモートリポジトリは削除します。

Settings > Danger Zoneの[ Delete this repository ] > ユーザ名+リポジトリ名をタイプして[I understand the conequences, delete this repository]

リモートリポジトリが削除されるだけで、ローカルリポジトリを削除したい場合は別途、削除の作業が必要です。
作ったばかりでリモートシポジトリ側でいろいろ削除してpushできなくなった場合も削除すると楽にpushできる。危険なのでいらないデータの場合のみ。

gitのルートディレクトリーの変更

dev/..中略../project/applebook/
から
ebook/..中略../project/applebook/
に変更したい。PCで普通に名前を変えるだけでOKです。

  • gitより上階層のフォルダの場所を変更しても問題なし
  • gitはプロジェクトのルート以下しか監視していないから(相対パスみたいな)

git管理下は次のような変更が必要。

git mv applebook orangebook

gitのルートディレクトリーを親階層に変更

project
|-- project/
|    |-- .git/
|-- export/

project
|-- .git/
|-- work/
|-- export/
  1. VsCodeで親階層を開く
  2. 次のコマンド。
cd project
mv .git ../

念の為エクスプローラやfinderで変更を確認します。.gitは隠しファイルなので表示が必要です。

フォルダ名の変更もあわせて行ってコミットしなおす。

githubのリポジトリの複数運用

リポジトリを切り替えてpushするという発想はやめた方がいいかもしれません。混乱します。

新しいプロジェクトのリポジトリを作る形で運用します。外注さんの〇〇プログラムのリポジトリを作成し、必要ならローカルでコピペで受け渡してメインのリポジトリに組み込みます。情報漏洩の懸念があるときだけに留め、基本は仲間うちで1つのリポジトリで運用するとよいでしょう。

githubにおけるブランチをマージ

github上でプルリクエストをマージする流れです。

  1. プルリクエスト(コードが長い場合は変更以外は隠れていることもある)
  2. プルリクエストされたコードを確認
  3. This branch has no conflicts with the base branch(競合が発生していないことを確認)
  4. 「Merge pull request」のボタンを押します。
  5. 「Confirm merge」のボタンを押します。
  6. 念の為github上で変更を確認。
  7. マスターブランチを確認して「Delete branch」のボタンを押します。

最後にローカルリポジトリにも反映させます。

git pull origin master

Please commit your changes or stash them before you merge.Aborting

Please commit your changes or stash them before you merge.Aborting
ローカルファイルとコンフリクトを起こす場合は、ローカルファイルをリネイムしてpullしてしまう手もあります。もしくは確実にいらないなら削除するとよいです。他にstashがあります。

gitのコマンドラインのブランチをマージ

github上でやる方法が簡単ですので上記の方法をおすすめしますが、一応書いておきます。

共同開発で誰かがブランチをあげてくれたとしましょう。いずれのコマンドでブランチの状況を確認しましょう。

ローカル&リモートブランチ一覧を表示します。

git branch -a

*印が付いているものが現在のブランチ です。なお、誰かがプルリクエストしてくれた場合、このコマンドを実行しても、最初含まれていません。fetchが必要です。

余談ですが、リモートブランチ一覧を表示するコマンドです。

git branch -r

fetchすると、github上のプルリクエストがVS Code上でみれます。

git fetch

個別に指定したい場合は次のとおりです。IDはgithubの#以降の数字です。BRANCHNAMEはなんでもOKの任意の名前です。

git fetch origin pull/ID/head:BRANCHNAME

再度、次のコマンドを実行すると見れるようになっているはず。

git branch -a

図説すると以下のようになります。

リモート:master

git fetchは、リモートのmasterからローカルのorigin/masterに。

ローカル:origin/master

git mergeは、ローカルのorigin/masterからローカルのmasterに。

ローカル:master

fetchとmargeとあわせたものが、git pullです。fetchではコンフリクトはおこりません。

ローカルファイルがある場合、チェックアウトしてmargeする流れになります。

git checkout project

fetchせず、ローカルファイルがない場合は、次のようになります。

git checkout -b project origin/project

最後にマージします。

git checkout project

まとめてやるなら、pullを使いましょう

git pull origin master

vs codeのGit Historyを使う場合は次の手順のようです。

  1. Git History(View > コマンドパレット > Git: View History (git log))を開きます
  2. masterブランチにチェックアウト(選択)
  3. 画面右のMove > Merge this commit into current branch

Please commit your changes or stash them before you switch branches.

ローカルで作業しているとき、別の開発者からあがってきたブランチをマージしたいときがあります。そんなときに便利なのがstachのコマンドです。

margeしようとしても、以下のエラーがでます。

error: Your local changes to the following files would be overwritten by checkout:
        nuxt.config.js
Please commit your changes or stash them before you switch branches.
Aborting

stashとは隠しておくという意味です。

まず、このコマンドを実行します。

git stash
// saveは省略できます。
git stash save

次のはただの確認コマンドです。

git stash list

pullします。

git pull origin master

あるいはgit fetchした場合はリポジトリ名です。

git marge リポジトリ名

ここまで実行すると、リモートにあった情報に更新されてローカル作業の情報が消えています。

次のコマンドを実行するとマージされて元に戻ります。

git stash pop

最新のスタッシュを適用し、スタッシュを削除する場合はpopを使ってください。個人的にはpop派です。

git stash apply

最新のスタッシュを適用し、スタッシュを残す場合はapplyを使ってください。

ブラウザ上からgithubのファイルを消す(小文字を大文字に変換後トラブル)

github上にだけに古いファイルが残ってしまったことがありました。小文字を大文字に変えてコミットしたときです。

github上から消せます。手順は以下のとおり。

  1. 消したいファイルを選ぶ
  2. 画面右上のゴミ箱アイコンをクリック
Add an optional extended despriction
にコメントを書いて

Commit directly to the master branch
ブランチを分けたいわけではないため、チェックをいれたまま

Commit changes
クリックします。

以上で削除されます。

githubの日付

日付はどうやらaddしたタイミングのようです。pushではありません。

githubのリポジトリの検索

他人のソースコードを見たいときもあるでしょう。

該当するリポジトリを開いて検索するだけです。ただし、検索する際に、[ In this repository ]を押します。

githubの正規表現の検索

grep.app | code search
Search across a half million git repos. Search by regular expression.

ただ、ニュースなどによると全リポジトリは検索できないみたいです。素晴らしいサイトです。

ファイル名変更時にgithubの履歴をキープする

Vs Codeで直接書き換える方法はダメなようです。ファイルがある場所でgit mvです。

cd フォルダ名
git mv a.vue b.vue

Vs Codeは変更時にgit addした状態になるため、pushすればOKっぽいです。

昔のファイルはgit log –followで確認するか、githubの履歴ページでUrlの末尾を昔のファイル名に書き換える必要があります。新しいファイルに履歴が移行するわけではないので、ちょっとめんどい。。あまり確認することがないため、これで一応、よしとします。

Githubでファイルを開き、[Blame]でもいけるようです。こちらの方が簡単ですかね。

スポンサーリンク

gitの本や動画

長くなったためこちらの記事にまとめなおしました。

コメント