はじめに チーム開発でよく用いれれているGitHubを使用するために必要なコマンドをまとめたいと思います。 前提としてGitHubのアカウントを登録しているという条件で進めていきます。 登録していない方は下記のリンクより行ってください。 GitHubへの登録/ログインはこちらから 基本的なコマンドについて ・初期設定を行う $ git config --global user.name "（GitHubのユーザーネーム）" $ git config --global user.email "（GitHubのアドレス）" ローカルにリポジトリを作成して、リモートにプッシュする //リポジトリを新規に作成 $ git init //全てのファイルの場合 $ git add . //指定したファイルのみ場合 $ git add (ファイル名) $ git commit -m "（プッシュした時のコメント）" //プッシュ先のプロジェクトを選択 $ git remote add origin https://github.com/（アカウント名）/（プロジェクト名）.git //マスターにプッシュする場合 $ git push -u origin master //ブランチにプッシュする場合 $ git checkout -b （ブランチ名） ☆checkout:移動 ☆-bファイル作成 $ git merge （ブランチ名） リポジトリをコピーする $ git clone https://github.com/（アカウント名）/（プロジェクト名）.git 最後に 箇条書きになってしまいましたが忘却録としてのこします。
チーム開発でよく用いれれているGitHubを使用するために必要なコマンドをまとめたいと思います。 前提としてGitHubのアカウントを登録しているという条件で進めていきます。 登録していない方は下記のリンクより行ってください。 GitHubへの登録/ログインはこちらから
・初期設定を行う
$ git config --global user.name "（GitHubのユーザーネーム）" $ git config --global user.email "（GitHubのアドレス）"
ローカルにリポジトリを作成して、リモートにプッシュする
//リポジトリを新規に作成 $ git init //全てのファイルの場合 $ git add . //指定したファイルのみ場合 $ git add (ファイル名) $ git commit -m "（プッシュした時のコメント）" //プッシュ先のプロジェクトを選択 $ git remote add origin https://github.com/（アカウント名）/（プロジェクト名）.git //マスターにプッシュする場合 $ git push -u origin master //ブランチにプッシュする場合 $ git checkout -b （ブランチ名） ☆checkout:移動 ☆-bファイル作成 $ git merge （ブランチ名）
リポジトリをコピーする
$ git clone https://github.com/（アカウント名）/（プロジェクト名）.git
箇条書きになってしまいましたが忘却録としてのこします。
はじめに 最近、アサインされるプロジェクトでGitを使用しているところが増えてきました。 Gitのプロジェクトに入ったとき、最低限以下だけ覚えておけば、何とかなるものをメモしてみました。 Gitのメリデメ 主観ですが・・・ ＜メリット＞ ・アジャイル開発しやすい。（カンバンとか） ＜デメリット＞ ・ブランチ管理が複雑になりやすい。（スパゲッティ管理。せめてアルデンテで） 用語の説明 リポジトリとは、Gitがバージョン管理下におく場所のこと。 ブランチとは、コミットIDの束を集めたリストのポインタみたいな感じ。 インデックスとは、コミットされる直前のファイルが置かれる場所。 コミットとは、ローカルリポジトリに変更履歴を記録する作業のこと。 既にあるリポジトリを使いたい場合 $ git clone ⇒（すごい）平たく言うと、ダウンロード（cloneっていう名前がややこしい）。 $ git checkout ＜ブランチ名＞ ⇒ 作業ブランチの切り替え。 $ git status ⇒ 現在のブランチや、未コミットのファイルが確認できる。 $ git add . ⇒ 修正したファイルをインデックスに追加。 $ git commit -m "コミットメッセージ" ⇒（ローカルリポジトリに）コミット。 $ git pull ⇒ リモートリポジトリの変更がローカルリポジトリにマージされる。 $ git push origin HEAD ⇒ ローカルでコミットした内容をリモートブランチに反映。 参考 わかばちゃんと学ぶ Git使い方入門 Gitが、おもしろいほどわかる基本の使い方33 C#エンジニア養成読本
最近、アサインされるプロジェクトでGitを使用しているところが増えてきました。
Gitのプロジェクトに入ったとき、最低限以下だけ覚えておけば、何とかなるものをメモしてみました。
主観ですが・・・
＜メリット＞ ・アジャイル開発しやすい。（カンバンとか）
＜デメリット＞ ・ブランチ管理が複雑になりやすい。（スパゲッティ管理。せめてアルデンテで）
リポジトリとは、Gitがバージョン管理下におく場所のこと。
ブランチとは、コミットIDの束を集めたリストのポインタみたいな感じ。
インデックスとは、コミットされる直前のファイルが置かれる場所。
コミットとは、ローカルリポジトリに変更履歴を記録する作業のこと。
$ git clone ⇒（すごい）平たく言うと、ダウンロード（cloneっていう名前がややこしい）。
$ git checkout ＜ブランチ名＞ ⇒ 作業ブランチの切り替え。
$ git status ⇒ 現在のブランチや、未コミットのファイルが確認できる。
$ git add . ⇒ 修正したファイルをインデックスに追加。
$ git commit -m "コミットメッセージ" ⇒（ローカルリポジトリに）コミット。
$ git pull ⇒ リモートリポジトリの変更がローカルリポジトリにマージされる。
$ git push origin HEAD ⇒ ローカルでコミットした内容をリモートブランチに反映。
はじめに Gitの勉強をしていて、push時に403エラーが返された エラー内容 $ git push origin master remote: Permission to アカウント1/リポジトリ名.git denied to アカウント2. fatal: unable to access 'https://アカウント1＠github.com/アカウント1/リポジトリ名.git' : The requested URL returned error: 403 アカウント1が、アカウント2にアクセスしようとしていた 当たり前だけどアカウント1にはアカウント2にアクセスする権限がないので、アカウント2にアクセスが拒否されて403エラーが返されたっぽい 解決方法 アカウント1にアクセスするようにリモートURLを以下のように変更する $ git remote set-url origin https://アカウント1＠github.com/アカウント1/リポジトリ名.git 以下のコマンドを実行して、リモートURLが変更されていることを確認する $ git remote -v origin: https://アカウント1＠github.com/アカウント1/リポジトリ名.git (fetch) origin: https://アカウント1＠github.com/アカウント1/リポジトリ名.git (push) 再度git push origin masterを実行しエラーが出ないことを確認する $ git push origin master ~一部省略~ To https://github.com/アカウント1/リポジトリ名.git * [new branch] master -> master 成功！ 解決するまでにやったこと エラー内容の解析 現在のリモートURLの確認 1、2からエラーを解決する方法を検索 2.で使用したコマンド $ git remote -v origin: github.com/アカウント/リポジトリ名.git (fetch) origin: github.com/アカウント/リポジトリ名.git (push) 3.で参考にさせていただいた記事 https://help.github.com/ja/github/using-git/changing-a-remotes-url https://qiita.com/1natsu172/items/a4a3357a0481440ec6a5 まとめ 今回のエラーは、現在使用しているアカウントが別のアカウントにアクセスしようとしたため発生したものだと分かった 疑問なのは、なぜ別のアカウントにアクセスしようとしたのか。 追記)上記疑問について調べた結果、「どのアカウントでアクセスするか指定していない状態だったため、アカウントの切り替えが出来ていなかった」ということがわかった。そのため、上記作業でアカウントを指定し、アカウントの切り替えをしたということになる
$ git push origin master remote: Permission to アカウント1/リポジトリ名.git denied to アカウント2. fatal: unable to access 'https://アカウント1＠github.com/アカウント1/リポジトリ名.git' : The requested URL returned error: 403
$ git remote set-url origin https://アカウント1＠github.com/アカウント1/リポジトリ名.git
$ git remote -v origin: https://アカウント1＠github.com/アカウント1/リポジトリ名.git (fetch) origin: https://アカウント1＠github.com/アカウント1/リポジトリ名.git (push)
$ git push origin master ~一部省略~ To https://github.com/アカウント1/リポジトリ名.git * [new branch] master -> master
成功！
2.で使用したコマンド
$ git remote -v origin: github.com/アカウント/リポジトリ名.git (fetch) origin: github.com/アカウント/リポジトリ名.git (push)
3.で参考にさせていただいた記事 https://help.github.com/ja/github/using-git/changing-a-remotes-url https://qiita.com/1natsu172/items/a4a3357a0481440ec6a5
はじめに termux上で、ターミナル上にbranch名を表示する方法が見つからなかったので備忘として残しておきます。ちなみにamazon linuxやmacなどでもやることは同じです gitのinstall termuxではデフォルトではgit入っていないので、installしておきます pkg install git Setting 以下2ファイルのpathを確認します。 find ~/../usr/ -name git-prompt.sh find ~/../usr/ -name git-completion.bash おそらく、 /data/data/com.termux/files/home/../usr/etc/bash_completion.d/git-prompt.shと /data/data/com.termux/files/home/../usr/etc/bash_completion.d/git-completion.bash が返ってくるはずです。 あとは.bash_profileと.bashrcをいじるだけです ~/.bash_profileに以下を追記 if [ -f ~/.bashrc ]; then . ~/.bashrc fi ~/.bashrcに以下を追記 source /data/data/com.termux/files/home/../usr/etc/bash_completion.d/git-completion.bash source /data/data/com.termux/files/home/../usr/etc/bash_completion.d/git-prompt.sh GIT_PS1_SHOWDIRTYSTATE=true PS1='\[\033[34m\]\w\[\033[31m\]$(__git_ps1)\[\033[00m\]\n\$ ' # サーバ名も先頭に表示させたいときは以下を使う # PS1='\[\033[32m\]\u@\h\[\033[00m\]:\[\033[34m\]\w\[\033[31m\]$(__git_ps1)\[\033[00m\]\n\$ ' あとは source ~/.bash_profile すれば次のような見た目になっているはずです。
termux上で、ターミナル上にbranch名を表示する方法が見つからなかったので備忘として残しておきます。ちなみにamazon linuxやmacなどでもやることは同じです
termuxではデフォルトではgit入っていないので、installしておきます
pkg install git
以下2ファイルのpathを確認します。
find ~/../usr/ -name git-prompt.sh find ~/../usr/ -name git-completion.bash
おそらく、 /data/data/com.termux/files/home/../usr/etc/bash_completion.d/git-prompt.shと /data/data/com.termux/files/home/../usr/etc/bash_completion.d/git-completion.bash が返ってくるはずです。
/data/data/com.termux/files/home/../usr/etc/bash_completion.d/git-prompt.sh
/data/data/com.termux/files/home/../usr/etc/bash_completion.d/git-completion.bash
あとは.bash_profileと.bashrcをいじるだけです
~/.bash_profileに以下を追記
~/.bash_profile
if [ -f ~/.bashrc ]; then . ~/.bashrc fi
~/.bashrcに以下を追記
~/.bashrc
source /data/data/com.termux/files/home/../usr/etc/bash_completion.d/git-completion.bash source /data/data/com.termux/files/home/../usr/etc/bash_completion.d/git-prompt.sh GIT_PS1_SHOWDIRTYSTATE=true PS1='\[\033[34m\]\w\[\033[31m\]$(__git_ps1)\[\033[00m\]\n\$ ' # サーバ名も先頭に表示させたいときは以下を使う # PS1='\[\033[32m\]\u@\h\[\033[00m\]:\[\033[34m\]\w\[\033[31m\]$(__git_ps1)\[\033[00m\]\n\$ '
あとは
source ~/.bash_profile
すれば次のような見た目になっているはずです。
はじめに iOSアプリを作ってみたいけど 何から始めて良いのかわからない とりあえず、 「やってみました」記事を参考に 地図アプリを真似てみようと思う という記事の９回目です。 今回は、いままでやってきたことを git でソースコード管理し、GitHub にて公開までします。 とりあえず、今回のシリーズは、これで終了の予定。 懺悔（ざんげ） 今回のシリーズは、アプリを「作ってみる」ことが主眼だったので git に関することは「あとまわし」だったけど、本当であれば「最初」にすることだと思います そのようなこともあり、今回の記事は、あとからgitでソースコード管理し、GitHubと連携することになります 一部の方には参考になると思いますが、多くの方には参考になりません GitHubアカウントの作成 ブラウザで、ここ↓にアクセス https://github.com/join 手順などの詳細は、他の記事を参照してください 簡単に作成できるはずです ソースコード管理対象の確認 【なぜ？】 権利（著作権など）の侵害は、法律違反 違反すると罰せられる 他人のものを、自分のもののように公開するのは、格好が悪くない？ 手順 「ターミナル」アプリを起動 Launchpadからでも、アプリメニューからでも、好きな方法で起動する 「ターミナル」にて以下のように、プロジェクトフォルダ全体に対し検索 【なぜ？】 cd で地図アプリ（MyGpsMap）のプロジェクトフォルダへ移動している プロジェクトフォルダの位置に関しては、この記事を参照 grep コマンドは、テキストファイル内の文字列を検索するツール -r オプションは、サブフォルダ全てを検索対象と指定している -i オプションは、大文字小文字を区別せず検索することを指定している 'copyright' は、検索文字列を指定している 最後の * は、全てのファイルが対象であることを指定している console % cd $HOME/github/shinobee/MyGpsMap/ % grep -r -i 'copyright' * 実行結果は、以下の通り 他者(shinobee以外)が copyright を持っているファイルが見つからない プロジェクトフォルダ全体を公開しても大丈夫 プロジェクトフォルダ全体を公開してくれた方が、使う(git cloneする)人もファイルの過不足が気にならないので「楽」だと思います console MyGpsMap/ViewController.swift:// Copyright © 2019 shinobee. All rights reserved. MyGpsMap/AppDelegate.swift:// Copyright © 2019 shinobee. All rights reserved. MyGpsMap/SceneDelegate.swift:// Copyright © 2019 shinobee. All rights reserved. Binary file MyGpsMap.xcodeproj/project.xcworkspace/xcuserdata/shinobee.xcuserdatad/UserInterfaceState.xcuserstate matches MyGpsMapTests/MyGpsMapTests.swift:// Copyright © 2019 shinobee. All rights reserved. MyGpsMapUITests/MyGpsMapUITests.swift:// Copyright © 2019 shinobee. All rights reserved. GitHubリポジトリの作成 GitHubにログイン ブラウザで https://github.com/login を表示 【なぜ？】 OSS(Open Source Software)のプロジェクトは、GitHubで公開で間違いないから GitHubでのプロジェクト作成は、ブラウザを使うから 自分は、他の手段を知らない GitHubにリポジトリを新規作成 画面右上の「＋」をクリックし、「New repository」を選択 以下のようにレポジトリ情報を入力 [Repository name]は、MyGpsMap [公開範囲]は、Public このプロジェクトは「公開」する 必要に応じて「非公開 Private」を選択しても可 [Initialize this repository with a README]は、チェックを入れないでOK [.gitignore]は、変更しないでOK [Add a license]は、変更しないでOK [Create repository]ボタンをクリックして、しばらく待つ 作成されたら、以下↓のように表示される XcocdプロジェクトとGitHubリポジトリの連携 GitHubアドレスを登録 「ターミナル」にて以下のように、コマンドを実行 【なぜ？】 GtHubでリポジトリを作成したあとに表示された「Quick setup」に書かれていたから このコマンドを実行することで、GitHubのリポジトリを連携づけできる 『プロジェクトに教えてあげる』と考えるほうが理解しやすいかも console % cd $HOME/github/shinobee/MyGpsMap/ % git remote add origin https://github.com/shinobee/MyGpsMap.git GitHub と同期 「ターミナル」にて以下のように、コマンドを実行 【なぜ？】 GtHubでリポジトリを作成したあとに表示された「Quick setup」に書かれていたから このコマンドを実行することで、GitHubのリポジトリと同期（今回はpush≒アップロード）できる なお、この時点では全てのファイルが同期（push）されていない 今までの記事では、ソースコード管理をしてこなかったので、Xcodeが自動作成した初期状態のファイルが同期（push）対象 これ↑が理解できない人は、他の人の記事をもとにGitについて勉強しましょう console % git push -u origin master なお、以下のようなコマンド実行結果が出力（表示）された console Enumerating objects: 33, done. Counting objects: 100% (33/33), done. Delta compression using up to 4 threads Compressing objects: 100% (29/29), done. Writing objects: 100% (33/33), 11.30 KiB | 2.82 MiB/s, done. Total 33 (delta 3), reused 0 (delta 0) remote: Resolving deltas: 100% (3/3), done. To https://github.com/shinobee/MyGpsMap.git * [new branch] master -> master Branch 'master' set up to track remote branch 'master' from 'origin'. ブラウザでgithubのリポジトリを表示したら以下のような状態 プロジェクトフォルダ以下の全てのファイルを git で管理 「ターミナル」にて以下のように、コマンドを実行 【なぜ？】 プロジェクトに関連する全てのファイルを対象とするため git のコマンドオプション add で管理対象ファイルを追加することを指示 git のコマンドオプション '.' ドットで、カレント(現在の)フォルダ以下全てを指定 console % cd $HOME/github/shinobee/MyGpsMap/ % git add . プロジェクトフォルダ以下の全てのファイルを git で管理 「ターミナル」にて以下のように、コマンドを実行 【なぜ？】 commit で管理対象ファイルを確定させることを指示 -m オプションで、コメントを記録 console % cd $HOME/github/shinobee/MyGpsMap/ % git commit -m 'update MyGpsMap project' git の内容をGitHubと同期 「ターミナル」にて以下のように、コマンドを実行 【なぜ？】 Mac上での変更内容をGitHubに登録するため console % git push Enumerating objects: 35, done. Counting objects: 100% (35/35), done. Delta compression using up to 4 threads Compressing objects: 100% (24/24), done. Writing objects: 100% (24/24), 126.10 KiB | 21.02 MiB/s, done. Total 24 (delta 5), reused 0 (delta 0) remote: Resolving deltas: 100% (5/5), completed with 5 local objects. To https://github.com/shinobee/MyGpsMap.git 091844c..c7f6b12 master -> master ブラウザでgithubのリポジトリを再表示(reload)したら以下のような状態 今回の到達点 プロジェクト(MyGpsMap)がGitHubにて公開された状態になった さいごに このシリーズの最初に書いた「＋αの目標」は達成できたのでしょうか？（自問） 説明を書き始めると、どこまで深く説明して良いのかわからなくなる 軽く読み切れる記事のボリュームを考えて説明を書いていたので、説明不足感があったかもしれません その中で、できるだけ説明を書いたつもりだけど、余計にわかり難くなったとしたら、ごめんなさい ＋αの目標[再掲] 世の中に「やってみました」記事は、たくさんある。 多くの場合、同じことをすれば同じ結果を得ることができる。 しかし「なぜそのようなことをするのか？」を 解決できないから自分が成長しない。 『人が書いた「やってみました」記事を参考に できるだけ「なぜ？」を解決しながらやってみよう』（汗） 連載 [はじめてのiOSアプリ]xcodeで地図アプリを作成（その１：プロジェクト作成） [はじめてのiOSアプリ]xcodeで地図アプリを作成（その２：地図表示） [はじめてのiOSアプリ]xcodeで地図アプリを作成（その３：位置情報取得） [はじめてのiOSアプリ]xcodeで地図アプリを作成（その４：位置情報と連携した地図表示） [はじめてのiOSアプリ]xcodeで地図アプリを作成（その５：アプリアイコン設定） [はじめてのiOSアプリ]xcodeで地図アプリを作成（その６：拡大・縮小ボタン追加） [はじめてのiOSアプリ]xcodeで地図アプリを作成（その７：地図を拡大・縮小） [はじめてのiOSアプリ]xcodeで地図アプリを作成（その８：地名表示） [はじめてのiOSアプリ]xcodeで地図アプリを作成（その９：ソースコード管理）
iOSアプリを作ってみたいけど 何から始めて良いのかわからない
とりあえず、 「やってみました」記事を参考に 地図アプリを真似てみようと思う
という記事の９回目です。
今回は、いままでやってきたことを git でソースコード管理し、GitHub にて公開までします。 とりあえず、今回のシリーズは、これで終了の予定。
手順
% cd $HOME/github/shinobee/MyGpsMap/ % grep -r -i 'copyright' *
MyGpsMap/ViewController.swift:// Copyright © 2019 shinobee. All rights reserved. MyGpsMap/AppDelegate.swift:// Copyright © 2019 shinobee. All rights reserved. MyGpsMap/SceneDelegate.swift:// Copyright © 2019 shinobee. All rights reserved. Binary file MyGpsMap.xcodeproj/project.xcworkspace/xcuserdata/shinobee.xcuserdatad/UserInterfaceState.xcuserstate matches MyGpsMapTests/MyGpsMapTests.swift:// Copyright © 2019 shinobee. All rights reserved. MyGpsMapUITests/MyGpsMapUITests.swift:// Copyright © 2019 shinobee. All rights reserved.
GitHubにログイン
GitHubにリポジトリを新規作成
GitHubアドレスを登録
% cd $HOME/github/shinobee/MyGpsMap/ % git remote add origin https://github.com/shinobee/MyGpsMap.git
GitHub と同期
% git push -u origin master
Enumerating objects: 33, done. Counting objects: 100% (33/33), done. Delta compression using up to 4 threads Compressing objects: 100% (29/29), done. Writing objects: 100% (33/33), 11.30 KiB | 2.82 MiB/s, done. Total 33 (delta 3), reused 0 (delta 0) remote: Resolving deltas: 100% (3/3), done. To https://github.com/shinobee/MyGpsMap.git * [new branch] master -> master Branch 'master' set up to track remote branch 'master' from 'origin'.
プロジェクトフォルダ以下の全てのファイルを git で管理
「ターミナル」にて以下のように、コマンドを実行
% cd $HOME/github/shinobee/MyGpsMap/ % git add .
% cd $HOME/github/shinobee/MyGpsMap/ % git commit -m 'update MyGpsMap project'
git の内容をGitHubと同期
% git push Enumerating objects: 35, done. Counting objects: 100% (35/35), done. Delta compression using up to 4 threads Compressing objects: 100% (24/24), done. Writing objects: 100% (24/24), 126.10 KiB | 21.02 MiB/s, done. Total 24 (delta 5), reused 0 (delta 0) remote: Resolving deltas: 100% (5/5), completed with 5 local objects. To https://github.com/shinobee/MyGpsMap.git 091844c..c7f6b12 master -> master
ブラウザでgithubのリポジトリを再表示(reload)したら以下のような状態
世の中に「やってみました」記事は、たくさんある。 多くの場合、同じことをすれば同じ結果を得ることができる。 しかし「なぜそのようなことをするのか？」を 解決できないから自分が成長しない。 『人が書いた「やってみました」記事を参考に できるだけ「なぜ？」を解決しながらやってみよう』（汗）
はじめに 新しく会社に入社する人に向けた Git および Github の勉強会をすることになったので、重要なポイントを確認するために下記の本を読みました。 その時に話をしたいと思うことをいくつかまとめたいと思い投稿することにしました。 Github については本でもまとめられていたり、他の人がまとめられていたりするので、 "Pull Request を安全に受け取る方法" の Backlog 版を書きました。参考にしていただけると嬉しいです。 Github実践入門 https://www.amazon.co.jp/GitHub%E5%AE%9F%E8%B7%B5%E5%85%A5%E9%96%80-Pull-Request%E3%81%AB%E3%82%88%E3%82%8B%E9%96%8B%E7%99%BA%E3%81%AE%E5%A4%89%E9%9D%A9-PRESS-plus/dp/477416366X 関連リンク 関連リンクを下記に載せておくので、必要であれば参考にしてください。。 Pull Request を送る方法（Backlog版） https://qiita.com/syukan3/items/6b8c1050a10076ff6d70 Pull Request を安全に受け取る方法 全体フロー Pull Request を安全に受け取るまでの全体のフローを下にまとめました。 上から順に作業していくことで、Pull Request を安全に受け取ることができます。 Pull Request のコードに問題がないかどうかを確認する clone もしくは pull により、リポジトリを最新の状態にする Pull Request送信者のリモートリポジトリを取得する 確認用のブランチを作成する マージする（２パターンあり） 1.で作成したブランチを削除する Pull Request のコードに問題がないかどうかを確認する Pull Request のコードに問題がないかどうかを確認するために、 自分の手元の環境にPull Requestのコードを落として安全確保のためにブランチを作成してそのブランチにてコードの確認をします。 clone もしくは pull により、ローカルリポジトリを最新の状態にする $ git clone ${Pull Requestの元のリポジトリ} Pull Request送信者のリモートリポジトリを取得する Pull Request送信者のリモートリポジトリを取得します。 // リモートリポジトリにPull Request送信者のリポジトリを登録 $ git remote add ${Pull Request送信者} ${Pull Requestされたリポジトリリンク} // Pull Request送信者のリポジトリのデータを取得 $ git fetch ${Pull Request送信者} 確認用のブランチを作成する 下記コマンドにて確認用のブランチを作成し、手元の環境にてPull Requestのコードが問題なく動くかどうかを確認する。 ここはコード内容によって確認項目が異なるかと思うので、各自確認を進めてください。 $ git checkout -b pull_request_1 マージする（２パターンあり） Backlog の画面からマージする方法 パターンの１つ目です。 work欄をクリックします。 印をつけたところをmasterに変更して、マージボタンを押します。 これでworkブランチをmasterブランチにマージをすることができました。 最後に、マージができていることを確認します。 色々と方法はありますが、コミット履歴タブを押すと、下の添付画像の通り "Merge pull request..." と確認できました。 CLI （ターミナル）からマージする方法 パターンの２つ目です。 // Pull Requestを取り込むmasterブランチへ切り替え $ git checkout master // masterブランチへ${Pull Request送信者}/workの内容をマージする $ git merge ${Pull Request送信者}/work // 変更内容を確認して、意図しない変更が含まれていないかを確認する $ git diff origin/master // 変更内容に問題がなければ、pushをすることでPull Requestを取り込む $ git push ブランチを削除する 不要になったブランチは残しておくと、後で見返したときに何かわからなくなるため、使い終わったら削除するようにします。 （"確認用のブランチを作成する"の項目で作成したブランチを削除します。） 下記のコードを実行してください。 $ git branch -D pull_request_1 まとめ Backlog 版として記事をまとめましたが、Pull Requestを安全に受け取る方法の全体的なフローに変わりはありません。 Github と Backlog で UI に差があることから少し操作方法に差があるだけですが、この記事をみて誰かの役に立てば嬉しく思います。
新しく会社に入社する人に向けた Git および Github の勉強会をすることになったので、重要なポイントを確認するために下記の本を読みました。 その時に話をしたいと思うことをいくつかまとめたいと思い投稿することにしました。
Github については本でもまとめられていたり、他の人がまとめられていたりするので、 "Pull Request を安全に受け取る方法" の Backlog 版を書きました。参考にしていただけると嬉しいです。
Github実践入門 https://www.amazon.co.jp/GitHub%E5%AE%9F%E8%B7%B5%E5%85%A5%E9%96%80-Pull-Request%E3%81%AB%E3%82%88%E3%82%8B%E9%96%8B%E7%99%BA%E3%81%AE%E5%A4%89%E9%9D%A9-PRESS-plus/dp/477416366X
関連リンクを下記に載せておくので、必要であれば参考にしてください。。
Pull Request を安全に受け取るまでの全体のフローを下にまとめました。 上から順に作業していくことで、Pull Request を安全に受け取ることができます。
Pull Request のコードに問題がないかどうかを確認するために、 自分の手元の環境にPull Requestのコードを落として安全確保のためにブランチを作成してそのブランチにてコードの確認をします。
$ git clone ${Pull Requestの元のリポジトリ}
Pull Request送信者のリモートリポジトリを取得します。
// リモートリポジトリにPull Request送信者のリポジトリを登録 $ git remote add ${Pull Request送信者} ${Pull Requestされたリポジトリリンク} // Pull Request送信者のリポジトリのデータを取得 $ git fetch ${Pull Request送信者}
下記コマンドにて確認用のブランチを作成し、手元の環境にてPull Requestのコードが問題なく動くかどうかを確認する。 ここはコード内容によって確認項目が異なるかと思うので、各自確認を進めてください。
$ git checkout -b pull_request_1
パターンの１つ目です。
work欄をクリックします。
印をつけたところをmasterに変更して、マージボタンを押します。 これでworkブランチをmasterブランチにマージをすることができました。
最後に、マージができていることを確認します。 色々と方法はありますが、コミット履歴タブを押すと、下の添付画像の通り "Merge pull request..." と確認できました。
パターンの２つ目です。
// Pull Requestを取り込むmasterブランチへ切り替え $ git checkout master // masterブランチへ${Pull Request送信者}/workの内容をマージする $ git merge ${Pull Request送信者}/work // 変更内容を確認して、意図しない変更が含まれていないかを確認する $ git diff origin/master // 変更内容に問題がなければ、pushをすることでPull Requestを取り込む $ git push
不要になったブランチは残しておくと、後で見返したときに何かわからなくなるため、使い終わったら削除するようにします。 （"確認用のブランチを作成する"の項目で作成したブランチを削除します。）
下記のコードを実行してください。
$ git branch -D pull_request_1
Backlog 版として記事をまとめましたが、Pull Requestを安全に受け取る方法の全体的なフローに変わりはありません。 Github と Backlog で UI に差があることから少し操作方法に差があるだけですが、この記事をみて誰かの役に立てば嬉しく思います。
