- 投稿日：2019-08-16T23:45:52+09:00
Gitについて Part3
はじめに
Gitについて調べたことを全3回でまとめていきます。
Part3のゴールは、GitとSourceTreeの連携です。
前提としてBack Numberの内容については理解するものとします。準備するもの
・SourceTree
(https://www.sourcetreeapp.com) の最新バージョンをインストール
(2019.08.16時点ではVer3.1.2)SourceTreeのインストールについて
- Bitbucket Server と Bitbucket の選択肢があるが、「Bitbucket」をインストール
- BitBucketにログインし、「アクセスを許可する」をクリック
- ツールをインストールする。
※Mercurialのインストールのチェックは外す- SSHキーの読み込みはいいえを選択
- SourceTreeを起動
以下、SourceTreeの各操作について記載する。
Remote ～リモートリポジトリ(GitHub)の追加～
- Remote内のアカウントの追加を押下
- Hostのホスティングサービスを「GitHub」に変更
- Credentialsの認証を「Basic」に変更
- 「パスワードを読みこみ」を押下
- ハスワードを入力
- GitHub連携できる
Clone ～リモートリポジトリのクローン～
- Remote内の対象のリポジトリを選択
- clone先のフォルダを選択
- clone先のフォルダ名を記載
- クローンを押下して完了
Create ～リポジトリの作成～
ローカルリポジトリの作成
- Createからパス、フォルダ名を指定
- 名前が自動入力される
- Gitを選択して、作成を押下
リモートリポジトリの作成
- Createからパス、フォルダ名を指定
- 名前が自動入力される
- Gitを選択
- 次のアカウントでリポジトリを作成にチェック
- アカウントをGitHubの名前に選択
- 所有者の名前が自動入力される
- 作成を押下
add ～ローカルにある既存のリポジトリを追加～
- 作業コピーのパスにgitディレクトリを選択
- 名前を付ける
- 追加を押下
ブランチの管理
ローカルブランチの作成
- ブランチを押下
- 新規ブランチ名を入力
- ブランチを作成する場所を決める
最新のコミット or 指定の古いコミット- 新規ブランチを作成してチェックアウトにチェックを入れたままでブランチを作成
リモートブランチの作成
- 設定を押下
- 追加を押下
- リモート名、URLを入力
- ホストタイプを「GitHub」にし、ユーザ名を入力
- OKを押下
ブランチの削除
- ブランチを押下
- 削除したいブランチを選択
- ブランチを削除を押下
リモートリポジトリへpush
- WORKSPACEのファイルステータスを押下
- 変更を確認したのち、インデックスに追加、または「＋」を押下
もし変更を破棄したい場合は、破棄を押下して破棄したいファイルを選択する- Indexにステージしたファイルをコメントを記載してコミット
- 変更をプッシュ
- プッシュするローカルブランチ、及びリモートブランチを選ぶ
リモートブランチは任意の名前に可能- プッシュする
リモートリポジトリからのpull
- プルを押下
- プルを行うリモートブランチを選ぶ
- マージした変更を即座にコミットにチェックを入れたままでOKを押下
スタッシュの使い方
- スタッシュを押下
- スタッシュ名を入力し、OKを押下
- 左下のスタッシュに格納されているので適用/削除したスタッシュを選択
おわりに
とりあえず、Part 1 ～ Part 3 で最低限のGitの使い方については言及したと思います。
今後、使用して発見があれば追記したいと思います。Back Number
- 投稿日：2019-08-16T21:49:26+09:00
最初にGithubに新規レポジトリを作った時に、merge: origin/master - not something we can merge が出た時の解決策[Git merge]
状況
新しくGithubにGUIで新規レポジトリを作り、すでにローカルにあるフォルダをリモートに移したい。前回の記事を参考
前回は、git push でリモートにあるファイルやディレクトリがローカルにはないことが原因でエラーが起きたため、push前にmergeをする必要があった。
今回も同様にmergeをすると、
git fetch git merge --allow-unrelated-histories origin/master merge: origin/master - not something we can mergeというエラーが出た。
https://qiita.com/somarihair/items/8580e9964099e6923bde
などを見ると、ブランチ名がタイポしているとこういうエラーが出るらしいが、タイポはしていない。結果
README.txtを用意せずに新規レポジトリを作ると、何もファイルがないリモートのレポジトリが生成されるので、空のレポジトリをマージしようとしてエラーが出ていた。
そのため、mergeは無視して、git push -u origin master をすれば良い。
git push -u origin master Enumerating objects: 12, done. Counting objects: 100% (12/12), done.
- 投稿日：2019-08-16T17:33:40+09:00
yarn.lockのconflict解消方法
yarnでJSライブラリのパッケージ管理を行っている場合、
しばしばbranch間でconflictする場合があると思います。dependabotなどでライブラリのバージョンアップをしたり、githubの脆弱性チェックなどで
yarn.lockを直接書き換えたりした場合などに発生したりします。ただし、その場合でも手動でyarn.lockを編集することは非推奨となっています。
（yarn.lock自体に正確なパッケージの依存関係が記載されているため、直接編集すると簡単に壊れる）yarn.lockのconflictを解消する
詳細は下記記事を参考にしてください
https://www.jakewiesler.com/blog/merge-conflicts-in-yarn-lock/作業前にmasterを最新にしている前提です。
masterから派生したコンフリクトしているブランチで次のような作業を行うことで解消できます。$ git rebase master # ①masterブランチのyarn.lockにあわせる $ git checkout master -- yarn.lock # ②その後そのブランチの依存関係を解決（パッケージの再インストール） $ yarn install # ③rebaseを続ける $ git add yarn.lock $ git rebase --continue # 再度conflictした場合は上の①②を行い、③を行う FINyarn.lockを直接編集する（脆弱性などの暫定対応）
ライブラリが参照している内部ライブラリが脆弱性があり、それに対してバージョンを上げたい場合があります。
その場合は手動でyarn.lock内の該当の依存ライブラリ部分を削除して再度yarn installします。参考：
https://github.com/yarnpkg/yarn/issues/4986#issuecomment-395036563例えば、package.jsonに記載されているjsonwebtoken（明示的な依存）が暗黙的に内部依存しているjws^3.0.0を脆弱なjws=3.1.4で解決している場合、代わりにパッチを適用したjws=3.1.5にアップグレードする必要があります。
yarn.lock内の下記のようなjwsのエントリを削除して再度
yarnし直します。
そうすると間接的な依存関係と影響を受けるパッケージは、他のものに触れることなく更新されます（yarn v1.3以降で動作）jws@^3.0.0, jws@^3.1.4: version "3.1.4" resolved "https://registry.npmjs.org/jws/-/jws-3.1.4.tgz#f9e8b9338e8a847277d6444b1464f61880e050a2" dependencies: base64url "^2.0.0" jwa "^1.1.4" safe-buffer "^5.0.1"
- 投稿日：2019-08-16T16:24:03+09:00
Github の始め方[備忘録 ]
きっかけ
github 以前使おうとして、アカウントを使っていたりはしていた。
使いこなせなくて、それ以降使っていなかったので、今回改めて始めた。参考
GitHub 入門インストール、メールアドレスの設定
すでにしてある。
$ git --version git version 2.20.1 (Apple Git-117)現在あるディレクトリをCommit
Atcoderのコードが、デスクトップと、Labtopに分散していて、わかりにくかったので、とりあえずpythonのコードだけでもあげることにした。
公開鍵認証
マイページから確認できる。
すでに登録されていた。localのディレクトリを登録する
$ git remote add origin https://github.com/Adaachill/atcoder.git fatal: remote origin already exists.でエラー。
http://pyoonn.hatenablog.com/entry/2014/10/29/191744
を参考に
git remote rm originをするローカルのディレクトリをpushする
そのまま、リモートの登録はできたものの、git push でエラーが。
$ git remote rm origin $ git remote add origin https://github.com/Adaachill/atcoder.git $ git push -u origin master To https://github.com/Adaachill/atcoder.git ! [rejected] master -> master (fetch first) error: failed to push some refs to 'https://github.com/Adaachill/atcoder.git' hint: Updates were rejected because the remote contains work that you do hint: not have locally. This is usually caused by another repository pushing hint: to the same ref. You may want to first integrate the remote changes hint: (e.g., 'git pull ...') before pushing again. hint: See the 'Note about fast-forwards' in 'git push --help' for details.長々とエラーが出たので、辟易しながら読んでみると、
remoteの方にローカルの方にはない、元からあったwork（ファイル？）があるので、失敗しました。
なので、まずは、remoteの方の変更をintegrateしてください。と言っています。remoteの変更をマージする
git fetch && git merge origin/master fatal: refusing to merge unrelated historiesでmergeできない。
https://qiita.com/takanatsu/items/fc89de9bd11148da1438
を参考にして、--allow-unrelated-historiesをつけると解決したgit merge --allow-unrelated-histories origin/master Merge made by the 'recursive' strategy. README.md | 5 +++++ 1 file changed, 5 insertions(+) create mode 100644 README.mdこの時に、なぜか自動的に、マージ用の設定ファイルがvimで開かれたのですが、そのまま閉じました。
次にREADME.mdをいじって変更を反映させようとしたところ、反映されませんでした。
$ git push origin master Everything up-to-datehttps://www.ksakae1216.com/entry/2016/06/09/160000
を参考にすると、もう一回commitすればいいようです。$ git add README.md $ git commit -m "re commit"これでもう一度pushすると反映されました。
commit log の確認
基本的にcommitのlog は
git logでみることができます。ただし、これは、authorやdate,commitのhash番号も含まれていて見にくかったりします。
git log --onelineで1行の簡単な履歴をみることができます。commit messsage のみw見たい時には便利です。$ git log --oneline bf5a668 (HEAD -> master, origin/master) re commit 794220c Merge remote-tracking branch 'origin/master' 21cf55e 2nd commit edd4808 first commit 0eb5287 master branch change 9901a53 Initial commit細かいファイルの差分を見たい場合は
git log -pを行うことでみることができます。
git log -p -nで直前のn件のcommitについての情報を得ることができます。diff --git a/README.md b/README.md index 7b84569..0319ff8 100644 --- a/README.md +++ b/README.md @@ -1,5 +1,4 @@ -# hello-world -1st repository and sample +# AtCoder +AtCoderの解いたファイルを保存します。 +今後整理はしたいですが、解けてないコードなども含まれています。 -#master branch change(commit) -this is the master branch change- が先頭に着くのが、削除された行
+ が先頭に着くのが、追加された行です。
- 投稿日：2019-08-16T16:24:03+09:00
Github の始め方(ローカルにすでにディレクトリがある場合）[備忘録 ]
きっかけ
github 以前使おうとして、アカウントを使っていたりはしていた。
使いこなせなくて、それ以降使っていなかったので、今回改めて始めた。途中から始める場合には、git push の時などにつまずくポイントがあったのでまとめる。
参考にした記事
GitHub 入門すごくわかりやすく、環境構築のところから書いてあります。
まだ、インストールもできていないという人はぜひ参考にしてください。
環境
$ git --version git version 2.20.1 (Apple Git-117)mac OS mojave
まとめ
最初に最終的にどんなコードを実行したのかを書きます。
summary.sh# 0. gitの環境構築 (install,公開鍵認証、メールアドレス登録など） # 1. localの自分のディレクトリでgit を開始する、ローカルに現在のディレクトリを全てコミットする。 git init # 除外するファイルの設定（除外したいファイル名やディレクトリ名を書きます） vim .gitignore git add . git commit -m "commit message" # 2. remote repositoryの登録 git remote rm origin # １度リモートのレポジトリを登録している場合 git remote add origin https://github.com/Username/Repository_name # 3. remote のrepositoryと統合する fetch and merge git fetch git merge --allow-unrelated-histories origin/master # 4. local のrepositoryをremoteにpushする git push -u origin master # 5. よく使う処理 git status # commit,addされていないファイルなどの確認 git diff # どんな変更がされたのか確認 git add . # カレントディレクトリを全てステージング（仮のコミット）する git diff --cached # 差分の確認 git commit -m "commit message" # commit git push # remote にlocal での変更を反映させる git pull # localに remoteの変更を反映させる git log # commitの履歴を確認 git log --oneline # 1行でcommitの履歴を確認 hashとcommit message git log -p -n # 直前のn件のcommitの変更点を行単位で確認する。また、commitの時刻も確認できる git log --pretty=format:"%cd %s" #--pretty=formatを使うことで、自分の好きな情報を、好きなフォーマットで出力することができます。 # %cd でcommitの時刻 %s でcommit messageをみることができます。インストール、メールアドレスの設定
事前にGithubで登録（アカウント作成時）
git config user.email メールアドレス git config user.name ユーザ名config 設定の確認
git config --list git config 確認したい設定現在あるディレクトリをCommit
# 0. gitの環境構築 (install,公開鍵認証、メールアドレス登録など） # 1. localの自分のディレクトリでgit を開始する、ローカルに現在のディレクトリを全てコミットする。 cd target_dir git init # 除外するファイルの設定（除外したいファイル名やディレクトリ名を書きます） vim .gitignore git add . git commit -m "commit message"公開鍵認証
公開鍵で送りたい場合 setting -> SSH and GPG keys で確認できます。
localのディレクトリを登録する (git remote rm originが必要）
$ git remote add origin https://github.com/Adaachill/atcoder.git fatal: remote origin already exists.でエラー。
http://pyoonn.hatenablog.com/entry/2014/10/29/191744
を参考に
git remote rm originをするローカルのディレクトリをpushする
一旦remoteを設定し直すことで、リモートの登録はできたものの、git push でエラーが。
リモートにあるファイルやディレクトリ（README.txtなど）がローカルにはないことが原因。＊逆にGithubでのremoteレポジトリ作成時に何もdiscriptionを書かないと、README.txtが生成されず、空のレポジトリになるのでmergeせずにそのままpushできる（というよりは、mergeするとエラーが出る）ようです。そのことについて記事を書きました。
$ git remote rm origin $ git remote add origin https://github.com/Adaachill/atcoder.git $ git push -u origin master To https://github.com/Adaachill/atcoder.git ! [rejected] master -> master (fetch first) error: failed to push some refs to 'https://github.com/Adaachill/atcoder.git' hint: Updates were rejected because the remote contains work that you do hint: not have locally. This is usually caused by another repository pushing hint: to the same ref. You may want to first integrate the remote changes hint: (e.g., 'git pull ...') before pushing again. hint: See the 'Note about fast-forwards' in 'git push --help' for details.長々とエラーが出たので、辟易しながら読んでみると、
remoteの方にローカルの方にはない、元からあったwork（ファイル？）があるので、失敗しました。
なので、まずは、remoteの方の変更をintegrateしてください。と言っています。remoteの変更をマージする(まずリモートのmergeが必要）
git fetch && git merge origin/master fatal: refusing to merge unrelated historiesでそのままやるとmergeできない。
https://qiita.com/takanatsu/items/fc89de9bd11148da1438
を参考にして、--allow-unrelated-historiesをつけると解決したgit merge --allow-unrelated-histories origin/master Merge made by the 'recursive' strategy. README.md | 5 +++++ 1 file changed, 5 insertions(+) create mode 100644 README.mdこの時に、なぜか自動的に、マージ用の設定ファイルがvimで開かれたのですが、そのまま閉じました。
次にREADME.mdをいじって変更を反映させようとしたところ、反映されませんでした。
$ git push origin master Everything up-to-datehttps://www.ksakae1216.com/entry/2016/06/09/160000
を参考にすると、もう一回commitすればいいようです。$ git add README.md $ git commit -m "re commit"これでもう一度pushすると反映されました。
手元でファイルをいじった後commitするまでの流れ
これで、とりあえず、今まであったファイルやディレクトリをGithubにあげることができました。
今度は、そこからローカルでファイルをいじる場合のコマンドを調べます。流れとしては、ファイルを変更したら、git status,git diffでその変更内容を確認してから、git addでステージングエリア（commit 前の仮の場所のようなもの）にあげ、さらに今度はcommitされているものとの差分を確認をしてcommitします。
差分を確認しすぎな気もしますが、commit前に何度も書き換える場合は、こういうことをしないとどこが変更されるかわからなくなって大変なことになるのでしょう。
git status # commit,addされていないファイルなどの確認 git diff # どんな変更がされたのか確認 git add change_file # 指定したファイルの変更内容を確認する git diff --cached # 現在commitされているものとの差分の確認 git commit -m "commit message" # commit git push # remote にlocal での変更を反映させる git pull # localに remoteの変更を反映させるgit push -u について
git push の際に
git push -u origin masterとすると、次の時から、リモートやローカルのレポジトリの名前を指定しなくても、git pushgit pullで実行することができるようです。commit log の確認
基本的にcommitのlog は
git logでみることができます。ただし、これは、authorやdate,commitのhash番号も含まれていて見にくかったりします。
git log --onelineで1行の簡単な履歴をみることができます。commit messsage のみw見たい時には便利です。$ git log --oneline bf5a668 (HEAD -> master, origin/master) re commit 794220c Merge remote-tracking branch 'origin/master' 21cf55e 2nd commit edd4808 first commit 0eb5287 master branch change 9901a53 Initial commit細かいファイルの差分を見たい場合は
git log -pを行うことでみることができます。
git log -p -nで直前のn件のcommitについての情報を得ることができます。diff --git a/README.md b/README.md index 7b84569..0319ff8 100644 --- a/README.md +++ b/README.md @@ -1,5 +1,4 @@ -# hello-world -1st repository and sample +# AtCoder +AtCoderの解いたファイルを保存します。 +今後整理はしたいですが、解けてないコードなども含まれています。 -#master branch change(commit) -this is the master branch change- が先頭に着くのが、削除、変更前された行
+ が先頭に着くのが、追加、変更後された行です。
git log --pretty=format:"%cd %s"
--pretty=formatを使うことで、自分の好きな情報を、好きなフォーマットで出力することができます。
%cd でcommitの時刻 %s でcommit messageをみることができます。
他にもいろんな情報を出せるようなのできになる方は調べてみてくださいhttps://qiita.com/hirotsugu_kawa/items/41afaafe477b877b5b73
この記事がgitのログについては非常にわかりやすいです。まだ基本的なコマンドも全然わかっていない状態で、かつ他の人のブログからコードをコピペしただけで何をやっているかがわかっていないことが多いのでぼちぼち学んでいこうと思います。
- 投稿日：2019-08-16T12:52:26+09:00
これからIBM Cloud CLIをインストールする方へ
皆さん、こんにちは。戸倉彩です。
今回は、IBM Cloud をコマンドラインから操作することができるCLIのインストールについて解説いたします。イベントやセミナー等で目的に応じてIBM Cloud CLIのインストールで案内される方法はさまざまですが、こちらも合わせて参考にしていただけばと思います。
IBM Cloud CLI とは
IBM Cloud CLIは、IBM Cloudのリソースを管理するためコマンド・ライン・インターフェース(CLI)のことです。現時点では、Mac OX、Windows、Linuxに対応したIBM Cloud CLIが公式サイトから提供されています。
IBM Cloud Kubernetes Servive なども利用する場合は Developer Tools もまとめて1発インストールしておくのが便利！
IBM Cloudで提供されているサービスによって、IBM Cloud CLIに加えてIBM Cloud Developer Toolsと呼ばれている開発者ツールのプラグイン等をインストールする必要があります。後から追加する手間を考えると、初めから一度に最新のIBM Cloud CLIを含む一連のIBM Cloud 開発ツールをインストールしておくと役立ちます。
ここで紹介するコマンドを実行してインストールを行うと、最新のIBM Cloud CLIと下記のツールを一度に入手することができます。GitやDocker、Kubernetesなどを利用する場合に必要なコマンドも一緒にインストールされるので時間の短縮にもなります。
・ Homebrew (Mac のみ)
・ Git
・ Docker
・ Helm
・ kubectl
・ curl
・ IBM Cloud Developer Tools プラグイン
・ IBM Cloud Functions プラグイン
・ IBM Cloud Object Storage プラグイン
・ IBM Cloud Container Registry プラグイン
・ IBM Cloud Kubernetes Service プラグインインストールする前の準備
- IBM Cloud アカウント の取得する
- 次のシステム要件を満たしていることを確認する
- DockerはStable チャネル (安定版) を使用する必要があるため、バージョン 1.13.1 以上を利用する
- 一部の機能はWindows 10 Pro を実行していないとサポートされません
インストール方法
下記のコマンドを実行します。
・MacおよびLinux環境の場合curl -sL https://ibm.biz/idt-installer | bash・Windows環境の場合
Windows 10 Pro の場合、管理者としてPowerShellで次のコマンをを実行します。[Net.ServicePointManager]::SecurityProtocol = "Tls12"; iex(New-Object Net.WebClient).DownloadString('https://ibm.biz/idt-win-installer')参考リソース: IBM Cloud CLI および Developer Tools の概説
シンプルに IBM Cloud CLI のみをインストールしたい場合
必要最低限のIBM Cloud CLIをインストールしたい、もしくは上記の手順でインストールが上手く実行できなかった時は、公式サイトから直接インストーラーをダウンロードして、ローカルで実行するという方法があります。
- Mac OS X 64ビット: インストーラー
- Windows 64ビット: インストーラー
- Linux X86 64ビット: インストーラー
- Linux LE 64ビット (ppc64le): インストーラー
32ビットのバージョンの環境をお使いの場合は、GitHubのIBM-Cloudリポジトリから直接ダウンロード入手することが可能です。
参考リソース: スタンドアロン IBM Cloud CLI のインストールIBM Cloud CLI の始め方
IBM Cloud CLIが正常にインストールされたことを検証するには、helpコマンドを実行します。
ibmcloud helpIBM Cloudを実際に操作するためには、利用するIBM Cloud環境にloginコマンドでログインを行います。
ibmcloud login企業などでシングルサインオンを利用している場合には--ssoのオプションを追加してログインをしてください。
ibmcloud login --ssoIBM CloudにIBM Cloud CLIでログインは無事にできましたでしょうか？
あとは、IBM Cloudのサイトやhelpを参考にしながら、操作を行ってみてください。今回は以上です。お疲れ様でした！
Have a nice Geek Life♪
※Twitterで最新情報配信中 @ayatokura
- 投稿日：2019-08-16T12:50:54+09:00
git初心者デザイナー向けSourceTreeの使い方2019（図説付き）for MAC
はじめに
超初心者向けです。とりあえず使えるようになる情報しか記載しません。
用語も噛み砕いてます。カッコ内は小慣れた人が使う用語なので覚えると便利です。
インストール済み、ssh設定済みの想定の説明です。1. SourceTreeを起動する
すると以下の画面が開きます。画像内の説明の通り、
(1-1)の新規をクリックし、(1-2)を選択しすると後述する(3)の画面が開きます。
2. ブラウザで自分のパソコン（ローカル）にコピー（クローン）したいgitのプロジェクトページを開く
※参考画像はgitlabです。
右端の(2-1)の「Clone」をクリックすると(2-2)が表示されるので上段のSSHの方をコピーする。
3. SourceTreeの画面に戻って自分のパソコン（ローカル）にコピー（クローン）する
(3-1)の「ソースURL」に(2-2)でコピーしたものをペーストする。
(3-2)の「保存先のパス（自分のパソコンのどのフォルダに置くか）」を指定する。
悩んだらコレ→ 例） /Users/user-name/gitlab/project-name(3-3)の「名前」は(3-2)で選択したフォルダ（ディレクトリ）の名前が表示されるので、そのままプロジェクトの名前にしておくのがおすすめ。
最後に右下の「クローン」のボタンを押す。
4. コピー（クローン）完了→ git操作画面が開く
よく使う機能の説明
(4-1)コミット→変更や修正などの作業が終わった時にクリックするボタン。
(4-2)プル→ブラウザのプロジェクト（リモート）にアップされた変更を自分のパソコン（ローカル）に引っ張ってくるボタン。
※ブランチをきる前に必ず毎回押すボタン！！(4-3)プッシュ→コミットの後にクリックするボタン。
(4-4)ブランチ→作業する前に押すボタン。
※masterで作業しちゃいけません！！プロジェクトによってルールが異なるので必ず作業ブランチは確認しましょう！！
(4-4)'自分のパソコン（ローカル）にあるブランチが表示される場所。
完了したものはどんどん削除しましょう。(4-5)スタッシュ→作業途中で別ブランチに移動（チェックアウト）する時に押すボタン。
※押さずに作業途中でチェックアウトすると大事故に繋がります！！
(4-5)'スタッシュ（作業途中を保管）中のブランチ名が表示される場所。元に戻す時にこの場所を利用します。(4-6)リモート→ブラウザのプロジェクト（リモート）に存在するブランチが表示されます。
左の矢印アイコンをポチポチして表示/非表示が切り替わります。
完了したものはどんどん削除しましょう。基本的な作業順
(4-2)プル → (4-4)ブランチ → 修正作業 → (4-1)コミット → (4-3)プッシュ → マージリクエスト（※1） → マージ（権限のある人が行う）
※1：githubのプルリクエスト = gitlabのマージリクエスト = コードレビュー依頼です。コーディング初心者の方は得意な方に見てもらったり、見せてもらったりすると良いと思います。
- 投稿日：2019-08-16T00:40:53+09:00
Gitについて Part2
はじめに
Gitについて調べたことを全3回でまとめていきます。
Part2のゴールは、ブランチとマージを使用した
管理を理解することです。そのうえで、今回は以下の3点を説明します。
1. ブランチとマージを理解する
2. リベースを理解する
3. タグ付け、及びスタッシュを理解する参考にしたサイト git book
（図はこちらのサイトから引用しています。ご了承ください）ブランチとマージ
・ブランチ
複数人が並行して開発するための機能
コミットを指すポインタのことで、「.git/refs」の中に作成したブランチが入っている
・マージ
他人が変更した結果を自分のリポジトリへ更新する・コンフリクト
同じファイルに対して異なる編集を行った場合に発生・リベース
merge以外で、変更履歴を整えるやり方ローカルブランチについて
・git init コマンドでデフォルトのブランチ名「master」が作られる。
また、最初にコミットした時点で、直近のコミットを指す 「master」 ブランチが作られる。リモートブランチについて
・git clone コマンドでデフォルトのリモート名「origin」が作られる。
また、リモートブランチは<リモート名>/<ブランチ名>で表す。
HEADについて
・今どのブランチで作業しているかを指すポインタが「HEAD」
新しいブランチ「testing」を加えたとしても、現在のブランチは「master」
Gitコマンド ～～
git branch
・ブランチに関するコマンド
bash・ブランチを追加する $ git branch <ブランチ名> ・ブランチの一覧を表示 $ git branch -a ・現在作業しているブランチ名を変更 $ git branch -m <ブランチ名> ・ブランチを削除 $ git branch -d <ブランチ名> # masterにマージされていない変更がある場合、削除されない $ git branch -D <ブランチ名> # masterにマージされていない変更がある場合でも、強制的に削除するgit checkout
・ブランチを切り替える
$ git checkout <既存のブランチ名> $ git checkout -b <新しいブランチ名> # 新規ブランチを作成して、ブランチを切り替える
git merge
・作業中のブランチに他のブランチの変更をマージする
bash$ git merge <リモート名/ブランチ名> Ex. $ git merge origin/master $ git merge testing
Gitコマンド ～リベース～
git rebase
・ブランチのコミットした内容を変更する
複数のブランチのコミットを統合する
bash$ git rebase <統合するブランチ名> Ex. $ git checkout experiment # リベースするブランチに移動 $ git rebase master # リベースする $ git checkout master # masterブランチに移動 $ git merge experiment # mergeする
こちらの説明が分かりやすい
※ただし、GitHubにプッシュしたコミットをリベースしないこと！複数のコミットをやり直す
1.git rebase コマンドを実行
base$ git rebase -i <コミットID> Ex. $ git rebase -i HEAD~3「HEAD~」 と 「HEAD^」 の違いはこちらが理解しやすい。
「HEAD~n」は n番目の親と
「HEAD^n」は n階層目の1番目の親を指す2.編集したいコミットの箇所を 「pick」 -> 「edit」に修正、保存する
pick 17a8f6d add rebase2 pick 58fbb09 add first.txt pick fbe208b add second.txt and third.txt ↓ edit 17a8f6d add rebase2 pick 58fbb09 add first.txt pick fbe208b add second.txt and third.txt3.内容を修正し、再度コミット、最新のコミットに戻る
$ git commit --amend $ git rebase --continueコミットを並び替える or 削除する
1.git rebase コマンドを実行
base$ git rebase -i <コミットID> Ex. $ git rebase -i HEAD~32.並び替えたいコミットの順番に修正、保存する
pick 17a8f6d add rebase2 pick 58fbb09 add first.txt pick fbe208b add second.txt and third.txt ↓ pick 6abcce7 add first.txt pick 12b7ed6 add rebase2.txt pick 9aa4bb6 add second.txt and third.txt複数のコミットをまとめる
1.git rebase コマンドを実行
base$ git rebase -i <コミットID> Ex. $ git rebase -i HEAD~32.編集したいコミットの箇所を 「pick」 -> 「squash」に修正、保存する
3つのコミットをまとめる場合pick 6abcce7 add first.txt pick 12b7ed6 add rebase2.txt pick 9aa4bb6 add second.txt and third.txt ↓ pick 6abcce7 add first.txt squash 12b7ed6 add rebase2.txt squash 9aa4bb6 add second.txt and third.txt3.コミットメッセージを修正する
コミットを複数のコミットに分割する
1.git rebase コマンドを実行
base$ git rebase -i <コミットID> Ex. $ git rebase -i HEAD~12.編集したいコミットの箇所を 「pick」 -> 「edit」に修正、保存する
3つのコミットに分割する場合pick 6abcce7 add first.txt ↓ edit 6abcce7 add first.txt3.コミットを修正する
base$ git reset HEAD $ git add XXX.txt $ git commit -m "add XXX.txt" $ git add YYY.txt $ git commit -m "add YYY.txt" $ git rebase --continueコンフリクトの解決方法
・同じ箇所を変更してそれぞれのブランチでコミットする。
bash$ git status ・ ・ ・ both modified: sample.txt ・ ・ ・・ファイルの中身を確認する
<<<<<<< HEAD 「HEADブランチで追加した内容」 =======
「testingブランチで追加した内容」 >>>>>>> testing
となる。sample.txtgit_tutorial用のファイルです。 2回目のコミットです。 3回目のコミットでーす。 マージ用のコミットです。 conflict. <<<<<<< HEAD コンフリクトを追加 ======= conflict. >>>>>>> testing ↓ git_tutorial用のファイルです。 2回目のコミットです。 3回目のコミットでーす。 マージ用のコミットです。 conflict. コンフリクトを追加 conflict.・git add, git commitを行う
GitHubへのプルリクエスト
プルリクエスト
変更内容を他人に確認したのち、マージする
プルリクエストの手順
・ローカルリポジトリ
1. masterブランチを最新に更新
2. プルリクエスト用のブランチを作成
3. ファイルを変更
4. 変更をコミット/GitHubへプッシュ・リモートリポジトリ（GitHub）
1. プルリクエストを確認する
1. Pull requests
2. base:master
3. compare:pull_request にする
4. pull_requestブランチからmasterブランチにプルリクエストを送る
5. Create pull request
6. Reviewersにレビュワーを追加する
2. 再戻し/承認
3. プルリクエストをマージ
4. 最後にプルリクエスト用のブランチを消すタグ付け
git tag
・タグ付けに関するコマンド
base・タグを作成する $ git tag <タグ名> <コミットID> $ git tag -a <タグ名> <コミットID> -m <"メッセージ"> ・タグの一覧を表示 $ git tag ・タグのコミットデータを表示する $ git show <タグ名>・タグをリモートリポジトリでも共有する
GitHubのreleasesに共有したタグが格納されている$ git push <リモート名> <タグ名> $ git push <リモート名> --tags自身の作業を隠す、消す（スタッシュ）
git stash
・変更内容をコミットせず、一時的に隠す
（ステージングエリア、及びワークディレクトリの変更内容を隠す）bash・スタッシュする $ git stash ・メッセージをつけてスタッシュする $ git stash save <メッセージ> ・スタッシュ中のリストを確認する $ git stash list stash@{0}: WIP on master: 2ca844a add third.txt stash@{1}: WIP on master: 2ca844a add third.txt ・スタッシュのリストの変更ファイルを確認する $ git stash show stash@{番号} # スタッシュの変更ファイルを表示する $ git stash show -p stash@{番号} # スタッシュのファイルの変更箇所を表示する ・スタッシュを適用する $ git stash apply # 最新のスタッシュを適用（ワーキングディレクトリのみ） $ git stash apply --index # 最新のスタッシュを適用（ステージングエリアを含む） $ git stash apply stash@{番号} # 指定した番号のスタッシュを適用（index指定可能） ・スタッシュを削除する $ git stash drop # 最新のスタッシュを削除 $ git stash drop stash@{番号} # 特定のスタッシュを削除 $ git stash clear # すべてのスタッシュを削除Back Number
- 投稿日：2019-08-16T00:31:29+09:00
Terminalから`git push`をするときにハマった話
Terminalから
git pushをした際に、エラーが出てきてしまい困っていたのを解決した話。
結構前に書いた覚書なので、当時なんのエラーが出ていたのかは、あんまり覚えていません・・・。GitHubに初めてPushする際に、何故か詰まってしまったので、その解決方法を載せておきます。
最初に次のコマンドを動かして、ユーザー名が表示されなかった場合にSSHの設定を行う必要があります。$ ssh -T git@github.com出力例(成功)
対処法
GitにSSHのアクセス権限を与える
$ ssh-keygen -t rsa $ pbcopy < ~/.ssh/id_rsa.pub # ファイルの内容をクリップボードに貼り付けるGitのページからSSHキーを設定する。
- https://github.com/settings/keys
- Title: 名前を入力する。 自分がわかれば良いので好きに設定する
- Key: ⑴でコピーしたSSHキー(
pbcopyでクリップボードにコピーしたもの)を貼り付ける
Gitのリポジトリを追加する
$ git remote add origin git@github.com:[ Git ID ]/[ Git Repository ] $ git add . $ git commit [-m “Commit message”] $ git push origin [ Remote branch name ]
おまけ
基本的なGitのコマンド
# マージ済みのブランチを削除する $ git branch --delete [ Branch name ] # ブランチの強制削除 $ git branch -D [ Branch name ] # リモートの状態を表示する $ git remote -v # リモートを削除する $ git remote rm [ Remote name ]
