役割 Stash 「とあるブランチで作業中だけど、いますぐやりたいことができた?」 ✅作業を一時的に待避させる。 ✅待避させた作業を復元させる。 Discard 「変更した内容を取り消したい?」 ✅xcodeの場合、選択したコードのみを取り消せる。 ✅変更した1ファイル、全てのファイルを変更前に戻せる。 git - stashの使い方 ✅作業を一時的に待避させる。 1.以下の画像のように、Source controlを開く。 2.Stash changesを押す。 3.退避させた作業を保存完了? ✅待避させた作業を復元させる。 1.source control navigationを開く。 2.stashed changesファイルを開くと、退避させた作業が保存されているので選択する。 3.無事に復元できたら完了? git - discardの使い方 ✅xcodeの場合、選択したコードのみを取り消す。 1.取り消したいコードの青縦線をクリックする。 2.変更したコードが青枠で囲われるので、discard changesを選択する 3.変更したコードが削除される? ✅変更したファイルを変更前に戻す。 1.ファイル欄から、対象のファイルを右クリックし、source controlを選択する。 2.discard changes in ファイル名を選択するとそのファイルの変更が全て取り消される? ✅全てのファイルを変更前に戻す。 1.xcodeの上部バーのsource controlを選択する。 2.discard all changes...を選択すると全てのファイルの変更が全て取り消される? 参考 https://qiita.com/chihiro/items/f373873d5c2dfbd03250
「とあるブランチで作業中だけど、いますぐやりたいことができた?」
✅作業を一時的に待避させる。 ✅待避させた作業を復元させる。
「変更した内容を取り消したい?」
✅xcodeの場合、選択したコードのみを取り消せる。 ✅変更した1ファイル、全てのファイルを変更前に戻せる。
1.以下の画像のように、Source controlを開く。 2.Stash changesを押す。 3.退避させた作業を保存完了?
Source control
Stash changes
1.source control navigationを開く。 2.stashed changesファイルを開くと、退避させた作業が保存されているので選択する。 3.無事に復元できたら完了?
source control navigation
stashed changes
1.取り消したいコードの青縦線をクリックする。 2.変更したコードが青枠で囲われるので、discard changesを選択する 3.変更したコードが削除される?
青縦線
discard changes
1.ファイル欄から、対象のファイルを右クリックし、source controlを選択する。 2.discard changes in ファイル名を選択するとそのファイルの変更が全て取り消される?
source control
discard changes in ファイル名
1.xcodeの上部バーのsource controlを選択する。 2.discard all changes...を選択すると全てのファイルの変更が全て取り消される?
discard all changes...
$ git rebase --onto 新しく派生元にしたいブランチ名 間違えて派生元にしたいブランチ名 派生したブランチ名 $ git push -f origin 派生したブランチ名
GitHubってどこが便利なんだよ？ と思っていました。現場での開発経験がないと、Gitという仕組みは難しいだけに感じますが 使ってみたらとても便利でした。 GitHubを使えるとポートフォリオにもなりますし、いいことづくめではないでしょうか。 今回は、Gitbash(CUI)を用いた方法とVisual Studio Code(GUI)を用いた方法の2種類のやり方でやってみたGitの使い方をまとめたいと思います。 Gitの仕組み(超ざっくりと) .gitディレクトリ(隠しフォルダ)をしのばせることで親ディレクトリを管理可能。 .gitが特殊な構造を持ち、二層の構造になっている。そのうちの一つがstage,もう一つがrepository(厳密には少し違う気がしますが…)。 ファイルをcommitしたときにそのファイルの情報をrepositoryに格納するのですが、このときにハッシュ値を一緒に持ちます。 このハッシュ値があることで、commitされたファイルが一意に特定できます。 つまり、commitがチェックポイントとなってcommitされるたびにその時点でのファイルの情報を複製します。 これによって、昔よりも開発の手戻りなどが行いやすくなったそうです。(昔を知らないので何とも言えませんが…) さらに、この仕組みによって、branchというものを作成することでそれぞれ別なファイルとして格納できるため、それぞれが｢試しにこういうのを試してみよう｣といったことが気軽にできます。 詳しく知りたい方はコチラの記事が結構参考になりました。 参考サイト init git init このコマンドを入力したファイルの中に.gitが作成されます。(CUIのみ) configでユーザー名とメールアドレスを設定(初回のみ) git config --local(--global) user.name ユーザー名 git config --local(--global) user.email メールアドレス これは文字通りです。 addまではできた気がしますが、commitなどの手続きはuser.nameおよびuser.emailがないと行えませんので追加します。 ちなみに、--localは現在のディレクトリ専用の設定で、--globalはその端末の設定です。 --globalで名前を追加すると、その端末でコミットしたものはすべてその名前の人がコミットしたことになります。 add git add ファイル名 編集したファイルをステージに上げます(ステージング)。 先ほどcommitの話がありましたが、その時に｢ファイルの情報を｣と書いたのは、このステージングという手続きがあるからです。 というのも、おそらくファイルそのものが格納され、スナップショットファイルを作りだしているのは、このaddによって移動したステージング領域と呼ばれるところだと思われます。 commitはこのファイルを圧縮して、圧縮データをステージング領域の奥にある領域に格納しています。実際、一緒に作られるハッシュ値はobjectsと呼ばれる場所に入っていました。 こうすることで何度も編集してデータ量がものすごいことになるのをある程度防いでいます。 commit git commit -m "メッセージ" 表現が正しいかはさておき、commitコマンドを叩くことでチェックポイントを確定させます。 -m でコミット時のメッセージを書いておくことで、後々戻りたいときにわかりやすくなるため -mを付けてメッセージを書いておきます。(そもそも、アプリケーションとかでコミットするときはメッセージ必須のはず。) GitHub側の準備 GitHubにログインして、リポジトリを追加します。 (手順) ログイン→repositoryの登録→publicかprivateかの選択→READMEを作るかの設定 完了後、URLが発行されます。 push git push URL(さっきのURL) pushというものを行うことで、自分のサーバがなくてもサーバ上でコードを管理できます。 そのためのアプリケーションに、githubとgitlabというものが代表としてあるらしいのですが、今回はより知名度が高いと思われるGitHubを使います。 privateに設定した場合はこの後IDおよびパスワードを入力します。 branchには頭(HEAD)とよばれるポイントがあって、これは最後にcommitした地点です。 逆にとらえるならば、commitが行われると、HEADが一つ進みます。(これは先述したcommitされたときにスナップショットを作成されるという仕様によるもの) master(ローカル側)⇔origin(GitHub側) pull(clone) git pull URL(さっきのURL) privateに設定した場合はこの後IDおよびパスワードを入力します。 merge git merge branch名(取り込みたいbranch) 複数人で開発する場合に起こる矛盾などを回避するための策です。 mergeという単語をネットで調べても｢マージする｣と出てきます。ふざけるでない。俺は日本語訳が知りたいんや。→ 一応｢併合する｣と訳するみたいです。 それはさておき、margeというのは、AとBを統合することと認識しておいていいでしょう。 ファイルをcommit地点からスタートさせ、branchを分けて開発を進めた場合、その情報をmaster(元のbranch)に適用させることが基本的なマージの意味です。 これには注意点がいくつかあります。 ※conflict(ケンカ)した場合 どちらを勝たせるか選びます。ただし、サーバ側でpushやpullをしたときにコンフリクトを起こした場合、CUIなので選ぶ ということができません。 この場合は、ケンカしたファイルを直接編集しに行きます。 sudo vi ファイル名(あるいはファイルパス) コンフリクトしたファイルは変な記述が追加されています。 >>>>>>>>HEAD みたいなやつ。 これを取り除くと一応コンフリクトしなくなります。 (本来は開発中の矛盾をなくすためにいったんコードをもとに戻す方がいいと思います。) pullしたときのmarge先はpullしたブランチ。 コンフリクトというのは同じファイルが異なる編集をされていたときに起こるもの。 それとは別に、例えば別のPCでファイルを編集してGitHubにPushして 元のPCでPullせずに別の編集をしてPushしようとすると、できません。 これを解決するためには先にpullすればいいのですが、このときにもmergeが行われます。 このときmergeで取り込むのはpullした方のbranch、取り込まれるのはpullされた方のbranchです。つまり、ほかの人の編集が自分にも反映されてしまうことになるので注意してください。 その他 公開範囲がpublicの場合、DBのアクセス情報などをPushしてしまうとえらいことになっちゃう… そこで! .gitignoreというファイルを用意することで公開したくない情報だけ公開しないように設定できます。 しかも簡単。ファイルの中にGitに上げたくないファイル名を書いておくだけ。ファイル数が多い場合は正規表現も使えるようです。 .gitignoreの書き方(引用) それ以外にもやりようはあるらしいですが、それはおいおい調べていきたいと思います。
と思っていました。現場での開発経験がないと、Gitという仕組みは難しいだけに感じますが 使ってみたらとても便利でした。 GitHubを使えるとポートフォリオにもなりますし、いいことづくめではないでしょうか。 今回は、Gitbash(CUI)を用いた方法とVisual Studio Code(GUI)を用いた方法の2種類のやり方でやってみたGitの使い方をまとめたいと思います。
.gitディレクトリ(隠しフォルダ)をしのばせることで親ディレクトリを管理可能。 .gitが特殊な構造を持ち、二層の構造になっている。そのうちの一つがstage,もう一つがrepository(厳密には少し違う気がしますが…)。
ファイルをcommitしたときにそのファイルの情報をrepositoryに格納するのですが、このときにハッシュ値を一緒に持ちます。 このハッシュ値があることで、commitされたファイルが一意に特定できます。 つまり、commitがチェックポイントとなってcommitされるたびにその時点でのファイルの情報を複製します。 これによって、昔よりも開発の手戻りなどが行いやすくなったそうです。(昔を知らないので何とも言えませんが…)
さらに、この仕組みによって、branchというものを作成することでそれぞれ別なファイルとして格納できるため、それぞれが｢試しにこういうのを試してみよう｣といったことが気軽にできます。 詳しく知りたい方はコチラの記事が結構参考になりました。 参考サイト
git init
このコマンドを入力したファイルの中に.gitが作成されます。(CUIのみ)
git config --local(--global) user.name ユーザー名 git config --local(--global) user.email メールアドレス
git config --local(--global) user.name ユーザー名
git config --local(--global) user.email メールアドレス
これは文字通りです。 addまではできた気がしますが、commitなどの手続きはuser.nameおよびuser.emailがないと行えませんので追加します。 ちなみに、--localは現在のディレクトリ専用の設定で、--globalはその端末の設定です。 --globalで名前を追加すると、その端末でコミットしたものはすべてその名前の人がコミットしたことになります。
git add ファイル名
編集したファイルをステージに上げます(ステージング)。 先ほどcommitの話がありましたが、その時に｢ファイルの情報を｣と書いたのは、このステージングという手続きがあるからです。 というのも、おそらくファイルそのものが格納され、スナップショットファイルを作りだしているのは、このaddによって移動したステージング領域と呼ばれるところだと思われます。
commitはこのファイルを圧縮して、圧縮データをステージング領域の奥にある領域に格納しています。実際、一緒に作られるハッシュ値はobjectsと呼ばれる場所に入っていました。
こうすることで何度も編集してデータ量がものすごいことになるのをある程度防いでいます。
git commit -m "メッセージ"
表現が正しいかはさておき、commitコマンドを叩くことでチェックポイントを確定させます。 -m でコミット時のメッセージを書いておくことで、後々戻りたいときにわかりやすくなるため -mを付けてメッセージを書いておきます。(そもそも、アプリケーションとかでコミットするときはメッセージ必須のはず。)
GitHubにログインして、リポジトリを追加します。 (手順) ログイン→repositoryの登録→publicかprivateかの選択→READMEを作るかの設定 完了後、URLが発行されます。
git push URL(さっきのURL)
pushというものを行うことで、自分のサーバがなくてもサーバ上でコードを管理できます。 そのためのアプリケーションに、githubとgitlabというものが代表としてあるらしいのですが、今回はより知名度が高いと思われるGitHubを使います。 privateに設定した場合はこの後IDおよびパスワードを入力します。 branchには頭(HEAD)とよばれるポイントがあって、これは最後にcommitした地点です。 逆にとらえるならば、commitが行われると、HEADが一つ進みます。(これは先述したcommitされたときにスナップショットを作成されるという仕様によるもの) master(ローカル側)⇔origin(GitHub側)
git pull URL(さっきのURL)
privateに設定した場合はこの後IDおよびパスワードを入力します。
git merge branch名(取り込みたいbranch)
複数人で開発する場合に起こる矛盾などを回避するための策です。 mergeという単語をネットで調べても｢マージする｣と出てきます。ふざけるでない。俺は日本語訳が知りたいんや。→ 一応｢併合する｣と訳するみたいです。
それはさておき、margeというのは、AとBを統合することと認識しておいていいでしょう。 ファイルをcommit地点からスタートさせ、branchを分けて開発を進めた場合、その情報をmaster(元のbranch)に適用させることが基本的なマージの意味です。 これには注意点がいくつかあります。
どちらを勝たせるか選びます。ただし、サーバ側でpushやpullをしたときにコンフリクトを起こした場合、CUIなので選ぶ ということができません。 この場合は、ケンカしたファイルを直接編集しに行きます。
sudo vi ファイル名(あるいはファイルパス)
コンフリクトしたファイルは変な記述が追加されています。 >>>>>>>>HEAD みたいなやつ。 これを取り除くと一応コンフリクトしなくなります。 (本来は開発中の矛盾をなくすためにいったんコードをもとに戻す方がいいと思います。)
コンフリクトというのは同じファイルが異なる編集をされていたときに起こるもの。 それとは別に、例えば別のPCでファイルを編集してGitHubにPushして 元のPCでPullせずに別の編集をしてPushしようとすると、できません。 これを解決するためには先にpullすればいいのですが、このときにもmergeが行われます。
このときmergeで取り込むのはpullした方のbranch、取り込まれるのはpullされた方のbranchです。つまり、ほかの人の編集が自分にも反映されてしまうことになるので注意してください。
公開範囲がpublicの場合、DBのアクセス情報などをPushしてしまうとえらいことになっちゃう… そこで! .gitignoreというファイルを用意することで公開したくない情報だけ公開しないように設定できます。 しかも簡単。ファイルの中にGitに上げたくないファイル名を書いておくだけ。ファイル数が多い場合は正規表現も使えるようです。 .gitignoreの書き方(引用) それ以外にもやりようはあるらしいですが、それはおいおい調べていきたいと思います。
GitHubってどこが便利なんだよ？ と思っていました。現場での開発経験がないと、Gitという仕組みは難しいだけに感じますが 使ってみたらとても便利でした。 GitHubを使えるとポートフォリオにもなりますし、いいことづくめではないでしょうか。 今回は、Gitbash(CUI)を用いた方法とVisual Studio Code(GUI)を用いた方法の2種類のやり方でやってみたGitの使い方をまとめたいと思います。 Gitの仕組み(超ざっくりと) .gitディレクトリ(隠しフォルダ)をしのばせることで親ディレクトリを管理可能。 .gitが特殊な構造を持ち、二層の構造になっている。そのうちの一つがstage,もう一つがrepository(厳密には少し違う気がしますが…)。 ファイルをcommitしたときにそのファイルの情報をrepositoryに格納するのですが、このときにハッシュ値を一緒に持ちます。 このハッシュ値があることで、commitされたファイルが一意に特定できます。 つまり、commitがチェックポイントとなってcommitされるたびにその時点でのファイルの情報を複製します。 これによって、昔よりも開発の手戻りなどが行いやすくなったそうです。(昔を知らないので何とも言えませんが…) さらに、この仕組みによって、branchというものを作成することでそれぞれ別なファイルとして格納できるため、それぞれが｢試しにこういうのを試してみよう｣といったことが気軽にできます。 詳しく知りたい方はコチラの記事が結構参考になりました。 参考サイト init git init このコマンドを入力したファイルの中に.gitが作成されます。(CUIのみ) configでユーザー名とメールアドレスを設定(初回のみ) git config --local(--global) user.name ユーザー名 git config --local(--global) user.email メールアドレス これは文字通りです。 addまではできた気がしますが、commitなどの手続きはuser.nameおよびuser.emailがないと行えませんので追加します。 ちなみに、--localは現在のディレクトリ専用の設定で、--globalはその端末の設定です。 --globalで名前を追加すると、その端末でコミットしたものはすべてその名前の人がコミットしたことになります。 add git add ファイル名 編集したファイルをステージに上げます(ステージング)。 先ほどcommitの話がありましたが、その時に｢ファイルの情報を｣と書いたのは、このステージングという手続きがあるからです。 というのも、おそらくファイルそのものが格納され、スナップショットファイルを作りだしているのは、このaddによって移動したステージング領域と呼ばれるところだと思われます。 commitはこのファイルを圧縮して、圧縮データをステージング領域の奥にある領域に格納しています。実際、一緒に作られるハッシュ値はobjectsと呼ばれる場所に入っていました。 こうすることで何度も編集してデータ量がものすごいことになるのをある程度防いでいます。 commit git commit -m "メッセージ" 表現が正しいかはさておき、commitコマンドを叩くことでチェックポイントを確定させます。 -m でコミット時のメッセージを書いておくことで、後々戻りたいときにわかりやすくなるため -mを付けてメッセージを書いておきます。(そもそも、アプリケーションとかでコミットするときはメッセージ必須のはず。) GitHub側の準備 GitHubにログインして、リポジトリを追加します。 (手順) ログイン→repositoryの登録→publicかprivateかの選択→READMEを作るかの設定 完了後、URLが発行されます。 push git push URL(さっきのURL) pushというものを行うことで、自分のサーバがなくてもサーバ上でコードを管理できます。 そのためのアプリケーションに、githubとgitlabというものが代表としてあるらしいのですが、今回はより知名度が高いと思われるGitHubを使います。 privateに設定した場合はこの後IDおよびパスワードを入力します。 branchには頭(HEAD)とよばれるポイントがあって、これは最後にcommitした地点です。 逆にとらえるならば、commitが行われると、HEADが一つ進みます。(これは先述したcommitされたときにスナップショットを作成されるという仕様によるもの) master(ローカル側)⇔origin(GitHub側) pull(clone) git pull URL(さっきのURL) privateに設定した場合はこの後IDおよびパスワードを入力します。 merge git merge branch名(取り込みたいbranch) 複数人で開発する場合に起こる矛盾などを回避するための策です。 mergeという単語をネットで調べても｢マージする｣と出てきます。ふざけるでない。俺は日本語訳が知りたいんや。→ 一応｢併合する｣と訳するみたいです。 それはさておき、margeというのは、AとBを統合することと認識しておいていいでしょう。 ファイルをcommit地点からスタートさせ、branchを分けて開発を進めた場合、その情報をmaster(元のbranch)に適用させることが基本的なマージの意味です。 これには注意点がいくつかあります。 ※conflict(ケンカ)した場合 どちらを勝たせるか選びます。ただし、サーバ側でpushやpullをしたときにコンフリクトを起こした場合、CUIなので選ぶ ということができません。 この場合は、ケンカしたファイルを直接編集しに行きます。 sudo vi ファイル名(あるいはファイルパス) コンフリクトしたファイルは変な記述が追加されています。 >>>>>>>>HEAD みたいなやつ。 これを取り除くと一応コンフリクトしなくなります。 (本来は開発中の矛盾をなくすためにいったんコードをもとに戻す方がいいと思います。) pullしたときのmarge先はpullしたブランチ。 コンフリクトというのは同じファイルが異なる編集をされていたときに起こるもの。 それとは別に、例えば別のPCでファイルを編集してGitHubにPushして 元のPCでPullせずに別の編集をしてPushしようとすると、できません。 これを解決するためには先にpullすればいいのですが、このときにもmergeが行われます。 このときmergeで取り込むのはpullした方のbranch、取り込まれるのはpullされた方のbranchです。つまり、ほかの人の編集が自分にも反映されてしまうことになるので注意してください。 その他 公開範囲がpublicの場合、DBのアクセス情報などをPushしてしまうとえらいことになっちゃう… そこで! .gitignoreというファイルを用意することで公開したくない情報だけ公開しないように設定できます。 しかも簡単。ファイルの中にGitに上げたくないファイル名を書いておくだけ。ファイル数が多い場合は正規表現も使えるようです。 .gitignoreの書き方(引用) それ以外にもやりようはあるらしいですが、それはおいおい調べていきたいと思います。 GUIの方は改めて書きます。
GUIの方は改めて書きます。
はじめに 前回に引き続きMATLAB GUIによるGit操作の第2回目 第1回 : プロジェクト作成とGUIの説明 第2回 : git add/git commit 第3回 : ブランチ作成 第4回 : リモートリポジトリとの連携 (git push/git pull) 第5回 : クローンを作成する 第6回 : 応用1 第7回 : 応用2 CUIから実行するにはgit add及びgit commit。 MATLABのコマンドウィンドウから実行する場合は!git add、!git commitです。 では、同様の操作をMATLABのGUIから実行するには？ 1プロジェクトを開く 第1回 : プロジェクト作成とGUIの説明 にて作成したプロジェクトを開くところから始めます。 GtiPrj.prjをダブルクリックします。 プロジェクトウィンドウが開きます。Gitのステータスも表示されています。 git addするために新規ファイルを作成します。ここではMATLABの簡単な関数を作成します。 git add 方法1 プロジェクト内の.gitがある現在のフォルダに新規MATLABファイルを保存。 右クリックで「ソース管理」⇒ 「Gitに追加」。 ステータスが白丸から＋印になります。これでgit addは完了 git add 方法2 方法1同様に新規MATLABファイルを現在のフォルダに保存。 プロジェクトウィンドウにおいて、「すべて」タブを選択。 ファイルを右クリックして「プロジェクトに追加」を選択。Gitステータスが＋になります。これでgit addは完了。プロジェクトに登録するとgit addになるんですね！ git commit 方法1 続いて、git commitです。これも2通り。 方法1は正確には git commit .(ステージングエリアにあるファイルを一括コミット)です。 ステージングエリアにあるファイルに対して、コミットアイコンをクリックすると対象ファイル全てがコミットされます。 コミットコメントを入力するダイアログが起動するので、規定のコメントフォーマットに従って設定してください。この辺りの、専用ダイアログは使いやすいと思います。 Gitステータスがグリーンの◯になったのでOKです。 git commit 方法2 先程の操作で全てコミットされたので、goofy.mを一旦編集します。 プロジェクトウィンドウまたは、現在のフォルダで、goofy.mを選択し、コンテキストメニューから「コミット」を選択します。ついでにプロジェクトに登録します。 最後に ここで一旦「プロジェクトの整合性チェック」を実行します。 プロジェクトの整合性チェックは、ファイルがgti管理化に存在するか? パス設定が正しく設定されているか? などGit及びSimulinkプロジェクト内のファイルの整合性をチェックしてくれます。 コミットしたあと等、定期的に実施すると良いかと思います。 次回 予定では第3回ですが、ちょっと2日前に面白い質問を頂いたので、 その回答をするかもしれません。 第1回 : プロジェクト作成とGUIの説明 第2回 : git add/git commit 第3回 : ブランチ作成 第4回 : リモートリポジトリとの連携 (git push/git pull) 第5回 : クローンを作成する 第6回 : 応用1 第7回 : 応用2 では、よい週末をお過ごし下さい。
前回に引き続きMATLAB GUIによるGit操作の第2回目
第1回 : プロジェクト作成とGUIの説明 第2回 : git add/git commit 第3回 : ブランチ作成 第4回 : リモートリポジトリとの連携 (git push/git pull) 第5回 : クローンを作成する 第6回 : 応用1 第7回 : 応用2
CUIから実行するにはgit add及びgit commit。 MATLABのコマンドウィンドウから実行する場合は!git add、!git commitです。 では、同様の操作をMATLABのGUIから実行するには？
git add
git commit
!git add
!git commit
第1回 : プロジェクト作成とGUIの説明 にて作成したプロジェクトを開くところから始めます。 GtiPrj.prjをダブルクリックします。
プロジェクトウィンドウが開きます。Gitのステータスも表示されています。
git addするために新規ファイルを作成します。ここではMATLABの簡単な関数を作成します。
続いて、git commitです。これも2通り。 方法1は正確には git commit .(ステージングエリアにあるファイルを一括コミット)です。 ステージングエリアにあるファイルに対して、コミットアイコンをクリックすると対象ファイル全てがコミットされます。
git commit .
コミットコメントを入力するダイアログが起動するので、規定のコメントフォーマットに従って設定してください。この辺りの、専用ダイアログは使いやすいと思います。
Gitステータスがグリーンの◯になったのでOKです。
先程の操作で全てコミットされたので、goofy.mを一旦編集します。
プロジェクトウィンドウまたは、現在のフォルダで、goofy.mを選択し、コンテキストメニューから「コミット」を選択します。ついでにプロジェクトに登録します。
ここで一旦「プロジェクトの整合性チェック」を実行します。 プロジェクトの整合性チェックは、ファイルがgti管理化に存在するか? パス設定が正しく設定されているか? などGit及びSimulinkプロジェクト内のファイルの整合性をチェックしてくれます。 コミットしたあと等、定期的に実施すると良いかと思います。
予定では第3回ですが、ちょっと2日前に面白い質問を頂いたので、 その回答をするかもしれません。
では、よい週末をお過ごし下さい。
初めて Qiita に投稿します！ 恥ずかしながら私は本日初めて GitHub をまともに使いました。いろいろな記事をネットで漁り、見よう見まねで頑張りました。初心者の備忘録として残しておこうと思います。 まだまだわからないことが多いので、間違いや補足等教えてくださると嬉しいです((o(ﾟ▽ﾟ)o))！ 環境 macOS Catalina 目次 Git と GitHub について Git のインストール GitHub のアカウント作成 GitHub リポジトリの作成 ターミナル操作 Git と GitHub について この両者についての説明はネット上にたくさんあります。 たくさんあるのですが私が自分なりに考えて解釈しました。 Git = ソースコードの履歴を管理するシステム GitHub = Git を統合する(集める)もの Hub はこんな感じの便利な機器ですね。いろんな線挿してつないでくれるやつ(語彙力)。 GitHub もまさにこんなイメージで、 Git という履歴管理システムを集積させたサービスって私は捉えました。異論は認めます() Git のインストール https://git-scm.com/download/mac にアクセスして Git をダウンロードします。 インストーラーのダウンロード後にターミナルを起動します。 インストールが完了すると Git コマンドが使えるようになります。 terminal $ git --version git version 2.17.1 GitHub のアカウント作成 一応ざっくりと書いておきます。 https://github.co.jp/ にアクセスして、ユーザー名と Email とパスワードを入力します。 サインアップします。 ＊GitHub が2018年6月に Microsoft に75億米ドルで買収されたのち、2019年1月に新しい料金プランが発表されました。 以下 https://forest.watch.impress.co.jp/docs/news/1161195.html より抜粋。 新しい“GitHub Free”プラン（無償）では、無制限のプライベートリポジトリに加え、プライベートリポジトリで最大3名までの共同作業者がサポートされる。“GitHub Pro”プラン（月額7米ドル）との違いは、プライベートリポジトリの共同作業者の数とレビューツールへのアクセスのみ。小規模なサイドプロジェクトへ参加するだけなら、無償プランでも十分カバーできるだろう。ちなみに、パブリックリポジトリであれば“Free”でも“Pro”でも共同作業者の数に制限はない。 ありがたい...！因みにこれを期に昨年私も GitHub のアカウントを作ることを決意しました。 当時はアカウントを作ってみただけだったのでしたが() GitHub リポジトリの作成 GitHub(https://github.com/) を開き、マイページを開きます。 Repositories を選択して "New" をクリックします。 リポジトリ名を記入して "Create repository" をクリックします。 これで空のリポジトリが作成できます。 ターミナル操作 GitHub にアップするフォルダを用意します。(デスクトップに置いたりターミナルの画面の大きさを調節したりするとやりやすいと思います) ターミナルで以下の呪文を打ちます。 terminal $ cd [アップするフォルダをドラッグする] cd というのは change directory の略で、そのファイルやフォルダに移動するコマンドです。 3. リポジトリを初期化します。 terminal $ git init Initialized empty Git repository in *****/.git/ git init と入力して、Initialized empty Git 〜 と表示されれば大丈夫です。 4. ファイルとフォルダをコミットします。 terminal $ git add . $ git commit -m "First commit" 2行目の -m 以降はコミットコメントです。 5. GitHub で作成したリポジトリをリモートリポジトリ(=ローカルでない共有用のリポジトリ)として登録します。 terminal $ git remote add origin [GitHub のリポジトリのURL(https://github.com/***/***.git)] 6. ローカルのファイルをリポジトリにアップロードします。 terminal $ git push -u origin master これでアップロードができます！٩( ᐛ )و まとめ GitHub は便利ですが慣れないうちは少し使いにくいです。今回は勉強も兼ねてターミナルを使いましたが、GitHubデスクトップというものもあるそうです。コマンドでの操作に抵抗のある人でも安心できるのではないでしょうか。 黒画面での作業はやはり興奮しますね。今まで私はターミナルをいじることに恐怖を感じていたのですが、少しずつ使い方がわかってくると楽しいです(そのうち何かやらかしたりして)。 それでは！ 参考 (より詳しい説明などは以下のサイトを参照) Qiita | Git と GitHub とは Qiita | gitの基本(init~push)+@ note | ローカルのディレクトリをGithubへアップロードする方法 「分かりそう」で「分からない」でも「分かった」気になれるIT用語辞典 | 「フォルダ」と「ディレクトリ」の違い
初めて Qiita に投稿します！
恥ずかしながら私は本日初めて GitHub をまともに使いました。いろいろな記事をネットで漁り、見よう見まねで頑張りました。初心者の備忘録として残しておこうと思います。
まだまだわからないことが多いので、間違いや補足等教えてくださると嬉しいです((o(ﾟ▽ﾟ)o))！
macOS Catalina
この両者についての説明はネット上にたくさんあります。 たくさんあるのですが私が自分なりに考えて解釈しました。
Git = ソースコードの履歴を管理するシステム GitHub = Git を統合する(集める)もの
Hub はこんな感じの便利な機器ですね。いろんな線挿してつないでくれるやつ(語彙力)。 GitHub もまさにこんなイメージで、 Git という履歴管理システムを集積させたサービスって私は捉えました。異論は認めます()
$ git --version git version 2.17.1
一応ざっくりと書いておきます。
＊GitHub が2018年6月に Microsoft に75億米ドルで買収されたのち、2019年1月に新しい料金プランが発表されました。 以下 https://forest.watch.impress.co.jp/docs/news/1161195.html より抜粋。
新しい“GitHub Free”プラン（無償）では、無制限のプライベートリポジトリに加え、プライベートリポジトリで最大3名までの共同作業者がサポートされる。“GitHub Pro”プラン（月額7米ドル）との違いは、プライベートリポジトリの共同作業者の数とレビューツールへのアクセスのみ。小規模なサイドプロジェクトへ参加するだけなら、無償プランでも十分カバーできるだろう。ちなみに、パブリックリポジトリであれば“Free”でも“Pro”でも共同作業者の数に制限はない。
ありがたい...！因みにこれを期に昨年私も GitHub のアカウントを作ることを決意しました。 当時はアカウントを作ってみただけだったのでしたが()
これで空のリポジトリが作成できます。
$ cd [アップするフォルダをドラッグする]
cd というのは change directory の略で、そのファイルやフォルダに移動するコマンドです。 3. リポジトリを初期化します。
$ git init Initialized empty Git repository in *****/.git/
git init と入力して、Initialized empty Git 〜 と表示されれば大丈夫です。 4. ファイルとフォルダをコミットします。
$ git add . $ git commit -m "First commit"
2行目の -m 以降はコミットコメントです。 5. GitHub で作成したリポジトリをリモートリポジトリ(=ローカルでない共有用のリポジトリ)として登録します。
$ git remote add origin [GitHub のリポジトリのURL(https://github.com/***/***.git)]
6. ローカルのファイルをリポジトリにアップロードします。
$ git push -u origin master
これでアップロードができます！٩( ᐛ )و
GitHub は便利ですが慣れないうちは少し使いにくいです。今回は勉強も兼ねてターミナルを使いましたが、GitHubデスクトップというものもあるそうです。コマンドでの操作に抵抗のある人でも安心できるのではないでしょうか。
黒画面での作業はやはり興奮しますね。今まで私はターミナルをいじることに恐怖を感じていたのですが、少しずつ使い方がわかってくると楽しいです(そのうち何かやらかしたりして)。
それでは！
Qiita | Git と GitHub とは Qiita | gitの基本(init~push)+@ note | ローカルのディレクトリをGithubへアップロードする方法 「分かりそう」で「分からない」でも「分かった」気になれるIT用語辞典 | 「フォルダ」と「ディレクトリ」の違い
手順 クローンしたいリポジトリのページへ行き「Clone or download」をクリック HTTPSを使ってリポジトリをクローンする場合はそのままコピーボタンをクリック、SSHキーを使ってクローンする場合は右上の「Use SSH」をクリック後にコピーボタンをクリック クローンしたいフォルダを作成し、そこで$ git clone [クローンURL] [フォルダ名]で実行する ~ ❯ cd MyApp ~/MyApp ❯ mkdir portfolio # 作成したフォルダ名を ~/MyApp ❯ git clone https://github.com/ユーザー名/リポジトリ名.git portfolio # ここへ入力する git cloneのコマンドは単に$ git clone [クローンURL]とすると、クローン側のフォルダごと作成したフォルダに入ってしまうのに対し、上記のコマンドだと綺麗に作成したフォルダにクローン側の中身が入ると思います 終わりに うまくいきましたでしょうか。私自身クローンする機会があまりなかったので殆ど自分のために手順を書いてみました。参考になれば幸いです。
クローンしたいリポジトリのページへ行き「Clone or download」をクリック
HTTPSを使ってリポジトリをクローンする場合はそのままコピーボタンをクリック、SSHキーを使ってクローンする場合は右上の「Use SSH」をクリック後にコピーボタンをクリック
クローンしたいフォルダを作成し、そこで$ git clone [クローンURL] [フォルダ名]で実行する
$ git clone [クローンURL] [フォルダ名]
~ ❯ cd MyApp ~/MyApp ❯ mkdir portfolio # 作成したフォルダ名を ~/MyApp ❯ git clone https://github.com/ユーザー名/リポジトリ名.git portfolio # ここへ入力する
git cloneのコマンドは単に$ git clone [クローンURL]とすると、クローン側のフォルダごと作成したフォルダに入ってしまうのに対し、上記のコマンドだと綺麗に作成したフォルダにクローン側の中身が入ると思います
git clone
$ git clone [クローンURL]
うまくいきましたでしょうか。私自身クローンする機会があまりなかったので殆ど自分のために手順を書いてみました。参考になれば幸いです。
目的 ローカルリポジトリとリモートリポジトリをリンクさせる方法をまとめる 実施方法 ローカルリポジトリの.gitフォルダが見えるディレクトリ階層で下記コマンドを実行する。 $ git remote add origin "リモートリポジトリのURL" 同階層で下記コマンドを実行してリンクされたリモートリポジトリのURLを確認する。 $ git remote -v >origin リモートリポジトリのURL.git (fetch) >origin リモートリポジトリのURL.git (push)
ローカルリポジトリの.gitフォルダが見えるディレクトリ階層で下記コマンドを実行する。
.git
$ git remote add origin "リモートリポジトリのURL"
同階層で下記コマンドを実行してリンクされたリモートリポジトリのURLを確認する。
$ git remote -v >origin リモートリポジトリのURL.git (fetch) >origin リモートリポジトリのURL.git (push)
