- 投稿日:2019-12-13T23:49:12+09:00
Gitマージでdry-runをやってみる
調べればいくらでも出てきそうな内容だけど自分でも書いてみる
$ git merge --no-commit --no-ff ブランチ名元に戻すときは
$ git merge --abort
- 投稿日:2019-12-13T23:25:11+09:00
gitについて自分のにわか知識を撲滅したい 基本編
gitについて自分のにわか知識を撲滅したい 基本編
こちらはITRC Advent Calendar 2019の13日目の記事です。
目的
自分のにわか知識を撲滅したく調べてみました。
今回はgitの歴史や仕組み、自分がなんとなく使っていた基本的なコマンド中心です。目次
- gitとは
- バージョン管理とは
- リポジトリとは
- ローカルバージョン管理システム
- 集中バージョン管理システム
- 分散バージョン管理システム
- Gitを使用する上で最低限必要な用語
- ローカルリポジトリとリモートリポジトリ
- gitサーバとは
- なんとなく使っていたコマンド達
- commitとpushについて
- cloneについて
- pullについて
- コマンドの流れ
- 参照
gitとは
- 分散バージョン管理システム
- スナップショットでファイルを保存
バージョン管理システムとは
ファイルを以前のバージョンに戻したり、変更履歴を保存するためや誰がいつファイルを変更したのか確認のためしたりなどを行え、
かつ、それらをリポジトリで管理するのがバージョン管理システムです。
参考にした文章
「バージョン管理」とは何でしょうか。また、なぜそれを気にする必要があるのでしょうか。 バージョン管理とは、一つのファイルやファイルの集合に対して時間とともに加えられていく変更を記録するシステムで、後で特定バージョンを呼び出すことができるようにするためのものです。 本書の例では、バージョン管理されるファイルとしてソフトウェアのソースコードを用いていますが、実際にはコンピューター上のあらゆる種類のファイルをバージョン管理のもとに置くことができます。
もしあなたがグラフィックス・デザイナーやウェブ・デザイナーで、画像やレイアウトの全てのバージョンを保存しておきたいとすると(きっとそうしたいですよね)、バージョン管理システム(VCS)を使うというのはいい考えです。 VCSを使うことで、ファイルを以前の状態まで戻したり、プロジェクト丸ごとを以前の状態に戻したり、過去の変更履歴を比較したり、問題が起こっているかもしれないものを誰が最後に修正したか、誰がいつ問題点を混入させたかを確認したりといった様々なことができるようになります。 また、VCSを使うと、やっていることがめちゃくちゃになってしまったり、ファイルを失ったりしても、普通は簡単に復活させることができるようになります。 それに、これらのことにかかるオーバーヘッドは僅かなものです。
参照:git バージョン管理に関してより
リポジトリとは
ファイルなどの保存場所。
決してデータベースやコンテナではないですが似たようなものです。
バージョン管理システムの種類
おおまかに3種類のバージョン管理システムがある。
- ローカルバージョン管理システム
- 集中バージョン管理システム
- 分散バージョン管理システム
ローカルバージョン管理システム
ローカルにのみリポジトリがある。
参考にした文章
どのディレクトリにいるのか忘れやすく、うっかり間違ったファイルに書き込んだり、上書きするつもりのないファイルを上書きしてしまったりします。
この問題を扱うため、はるか昔のプログラマは、ローカルのVCSを開発しました。それは、バージョン管理下のファイルに対する全ての変更を保持するシンプルなデータベースによるものでした。
参照:git ローカルバージョン管理システムより
集中バージョン管理システム
1個のサーバーを用意してあげてそこのリポジトリに保存。
参考にした文章
次に人々が遭遇した大きな問題は、他のシステムを使う開発者と共同作業をする必要があるということです。
バージョン管理されたファイルを全て持つ一つのサーバーと、その中心点からファイルをチェックアウトする多数のクライアントからなっています。 長年の間、これはバージョン管理の標準でした。
参照:git 集中バージョン管理システムより
分散バージョン管理システム
ローカルにもサーバーにもリポジトリがある。
もしサーバーが死んでも大丈夫()。
参考にした文章
ここで分散バージョン管理システム(DVCS)の出番になります。 DVCS(Git、Mercurial、Bazaar、Darcsのようなもの)では、クライアントはファイルの最新スナップショットをチェックアウト(訳者注:バージョン管理システムから、作業ディレクトリにファイルやディレクトリをコピーすること)するだけではありません。リポジトリ(訳者注:バージョン管理の対象になるファイル、ディレクトリ、更新履歴などの一群)全体をミラーリングするのです。 そのため、あるサーバーが故障して、DVCSがそのサーバーを介して連携していたとしても、どれでもいいのでクライアント・リポジトリの一つをサーバーにコピーすれば修復できます。 クローンは全て、実際は全データの完全バックアップなのです。
参照:git 分散バージョン管理システムより
スナップショットで、差分ではない
commitが分かれば納得できると思う。
分散バージョン管理システムは一回一回全保存。
その他だと編集したファイルだけ保存。
参考にした文章
Gitと他のVCS (Subversionとその類を含む)の主要な相違は、Gitのデータについての考え方です。 概念的には、他のシステムのほとんどは、情報をファイルを基本とした変更のリストとして格納します。 これらのシステム(CVS、Subversion、Perforce、Bazaar等々)は、図1-4に描かれているように、システムが保持しているファイルの集合と、時間を通じてそれぞれのファイルに加えられた変更の情報を考えます。
Gitは、この方法ではデータを考えたり、格納しません。 代わりに、Gitはデータをミニ・ファイルシステムのスナップショットの集合のように考えます。 Gitで全てのコミット(訳注:commitとは変更を記録・保存するGitの操作。詳細は後の章を参照)をするとき、もしくはプロジェクトの状態を保存するとき、Gitは基本的に、その時の全てのファイルの状態のスナップショットを撮り(訳者注:意訳)、そのスナップショットへの参照を格納するのです。 効率化のため、ファイルに変更が無い場合は、Gitはファイルを再格納せず、既に格納してある、以前の同一のファイルへのリンクを格納します。 Gitは、むしろデータを一連のスナップショットのように考えます。
参照:git Gitの基本より
Gitを使用する上で最低限必要な用語
- ローカルリポジトリ
- リモートリポジトリ
- Gitサーバ
- add
- commit(コミット)
- push(プッシュ)
- clone(クローン)
- pull(プル)
リポジトリとは(復習)
ローカルリポジトリとリモートリポジトリ
- ローカルリポジトリは自分のPC内にあるリポジトリのこと
- リモートリポジトリはGitサーバにあるリポジトリのこと
Gitサーバ
Git用に設定されたサーバです。
もちろん自分でたてられたりしますが、
GitHubやGitLabなどの無料で使えるクラウドサーバ(厳密には開発プラットホーム)もあります。全体像
全体像はこんな感じ
addとは
作業ファイルはリポジトリをコピーして「作業コピー」を取得します。
その作業コピーにたして変更を加えてあげることで、変更内容のスナップショットをリポジトリにコミットします。
ファイルの状態には追跡されている(tracked)や追跡されてない(untracked)があり、
追跡されている(tracked)状態の「変更されている(modified)」ファイルを「ステージされている(staged)」状態にするために行うことがaddです。commit(コミット)してpush(プッシュ)
- commitはローカルリポジトリにファイルを保存すること。
- pushはリモートリポジトリにローカルリポジトリを保存すること。
gifだと分かりやすく新しいファイルのみpushしていますが、実際はリポジトリごとpushしています。
ここで行っているadd,commit,pushコマンド
$ git add [file] $ git commit -m "[comment]" $ git push -u origin mastercloneとpullの違い
ローカルリポジトリがあるかないかです。
つまり自分のPCにデータがあるかないかです。
- cloneはローカルリポジトリがないとき
- pullはローカルリポジトリがあるとき
clone
リモートリポジトリにリポジトリがあるがローカルリポジトリにリポジトリがない時に行います。
つまり、サーバにだけデータベースがあって自分のPCにデータベースがない時に使用するコマンドです。
ここで行っているcloneコマンド
$ git clone [URL]pull
他人がリモートリポジトリにもリポジトリが変更した時、自分もそのリポジトリをローカルリポジトリにダウンロードする必要があります。
つまり他人がサーバにデータを保存した時、それをダウンロードするために使用するコマンドです。
ここで行っているpushコマンド
$ git pull origin masterコマンドの流れ
ローカルリポジトリをGitHubにpushする
1回目
$ mkdir [file name] $ cd [file name] $ echo "hello,world" >> README.md $ git init $ git add [file name] $ git commit -m "[comment]" $ git remote add origin [URL] $ git push -u origin master2回目以降
$ git add . $ git commit -m "comment" $ git push -u origin masterリモートリポジトリからローカルリポジトリにcloneしてくる
$ git clone [URL]リモートリポジトリからローカルリポジトリにpullしてくる
$ git pull origin masterまとめ
- バージョン管理には種類がある。
- リポジトリはファイルの保存場所
- アップロードはaddしてcommitしてpush
- ダウンロードはclone or pull
参照
- 投稿日:2019-12-13T23:25:11+09:00
gitについて自分のにわか知識を撲滅したい その1 基本編
gitについて自分のにわか知識を撲滅したい 基本編
こちらはITRC Advent Calendar 2019の13日目の記事です。
2日前の人: トラコンの感想
前の人: 限定公開でした。
次の人: VisualStudioCode 便利なプラグインをまとめてみた目的
自分のにわか知識を撲滅したく調べてみました。
今回はgitの歴史や仕組み、自分がなんとなく使っていた基本的なコマンド中心です。目次
- gitとは
- バージョン管理とは
- リポジトリとは
- ローカルバージョン管理システム
- 集中バージョン管理システム
- 分散バージョン管理システム
- Gitを使用する上で最低限必要な用語
- ローカルリポジトリとリモートリポジトリ
- gitサーバとは
- なんとなく使っていたコマンド達
- commitとpushについて
- cloneについて
- pullについて
- コマンドの流れ
- 参照
gitとは
- 分散バージョン管理システム
- スナップショットでファイルを保存
バージョン管理システムとは
ファイルを以前のバージョンに戻したり、変更履歴を保存するためや誰がいつファイルを変更したのか確認のためしたりなどを行え、
かつ、それらをリポジトリで管理するのがバージョン管理システムです。
参考にした文章
「バージョン管理」とは何でしょうか。また、なぜそれを気にする必要があるのでしょうか。 バージョン管理とは、一つのファイルやファイルの集合に対して時間とともに加えられていく変更を記録するシステムで、後で特定バージョンを呼び出すことができるようにするためのものです。 本書の例では、バージョン管理されるファイルとしてソフトウェアのソースコードを用いていますが、実際にはコンピューター上のあらゆる種類のファイルをバージョン管理のもとに置くことができます。
もしあなたがグラフィックス・デザイナーやウェブ・デザイナーで、画像やレイアウトの全てのバージョンを保存しておきたいとすると(きっとそうしたいですよね)、バージョン管理システム(VCS)を使うというのはいい考えです。 VCSを使うことで、ファイルを以前の状態まで戻したり、プロジェクト丸ごとを以前の状態に戻したり、過去の変更履歴を比較したり、問題が起こっているかもしれないものを誰が最後に修正したか、誰がいつ問題点を混入させたかを確認したりといった様々なことができるようになります。 また、VCSを使うと、やっていることがめちゃくちゃになってしまったり、ファイルを失ったりしても、普通は簡単に復活させることができるようになります。 それに、これらのことにかかるオーバーヘッドは僅かなものです。
参照:git バージョン管理に関してより
リポジトリとは
ファイルなどの保存場所。
決してデータベースやコンテナではないですが似たようなものです。
バージョン管理システムの種類
おおまかに3種類のバージョン管理システムがある。
- ローカルバージョン管理システム
- 集中バージョン管理システム
- 分散バージョン管理システム
ローカルバージョン管理システム
ローカルにのみリポジトリがある。
参考にした文章
どのディレクトリにいるのか忘れやすく、うっかり間違ったファイルに書き込んだり、上書きするつもりのないファイルを上書きしてしまったりします。
この問題を扱うため、はるか昔のプログラマは、ローカルのVCSを開発しました。それは、バージョン管理下のファイルに対する全ての変更を保持するシンプルなデータベースによるものでした。
参照:git ローカルバージョン管理システムより
集中バージョン管理システム
1個のサーバーを用意してあげてそこのリポジトリに保存。
参考にした文章
次に人々が遭遇した大きな問題は、他のシステムを使う開発者と共同作業をする必要があるということです。
バージョン管理されたファイルを全て持つ一つのサーバーと、その中心点からファイルをチェックアウトする多数のクライアントからなっています。 長年の間、これはバージョン管理の標準でした。
参照:git 集中バージョン管理システムより
分散バージョン管理システム
ローカルにもサーバーにもリポジトリがある。
もしサーバーが死んでも大丈夫()。
参考にした文章
ここで分散バージョン管理システム(DVCS)の出番になります。 DVCS(Git、Mercurial、Bazaar、Darcsのようなもの)では、クライアントはファイルの最新スナップショットをチェックアウト(訳者注:バージョン管理システムから、作業ディレクトリにファイルやディレクトリをコピーすること)するだけではありません。リポジトリ(訳者注:バージョン管理の対象になるファイル、ディレクトリ、更新履歴などの一群)全体をミラーリングするのです。 そのため、あるサーバーが故障して、DVCSがそのサーバーを介して連携していたとしても、どれでもいいのでクライアント・リポジトリの一つをサーバーにコピーすれば修復できます。 クローンは全て、実際は全データの完全バックアップなのです。
参照:git 分散バージョン管理システムより
スナップショットで、差分ではない
commitが分かれば納得できると思う。
分散バージョン管理システムは一回一回全保存。
その他だと編集したファイルだけ保存。
参考にした文章
Gitと他のVCS (Subversionとその類を含む)の主要な相違は、Gitのデータについての考え方です。 概念的には、他のシステムのほとんどは、情報をファイルを基本とした変更のリストとして格納します。 これらのシステム(CVS、Subversion、Perforce、Bazaar等々)は、図1-4に描かれているように、システムが保持しているファイルの集合と、時間を通じてそれぞれのファイルに加えられた変更の情報を考えます。
Gitは、この方法ではデータを考えたり、格納しません。 代わりに、Gitはデータをミニ・ファイルシステムのスナップショットの集合のように考えます。 Gitで全てのコミット(訳注:commitとは変更を記録・保存するGitの操作。詳細は後の章を参照)をするとき、もしくはプロジェクトの状態を保存するとき、Gitは基本的に、その時の全てのファイルの状態のスナップショットを撮り(訳者注:意訳)、そのスナップショットへの参照を格納するのです。 効率化のため、ファイルに変更が無い場合は、Gitはファイルを再格納せず、既に格納してある、以前の同一のファイルへのリンクを格納します。 Gitは、むしろデータを一連のスナップショットのように考えます。
参照:git Gitの基本より
Gitを使用する上で最低限必要な用語
- ローカルリポジトリ
- リモートリポジトリ
- Gitサーバ
- add
- commit(コミット)
- push(プッシュ)
- clone(クローン)
- pull(プル)
リポジトリとは(復習)
ローカルリポジトリとリモートリポジトリ
- ローカルリポジトリは自分のPC内にあるリポジトリのこと
- リモートリポジトリはGitサーバにあるリポジトリのこと
Gitサーバ
Git用に設定されたサーバです。
もちろん自分でたてられたりしますが、
GitHubやGitLabなどの無料で使えるクラウドサーバ(厳密には開発プラットホーム)もあります。全体像
全体像はこんな感じ
addとは
作業ファイルはリポジトリをコピーして「作業コピー」を取得します。
その作業コピーにたして変更を加えてあげることで、変更内容のスナップショットをリポジトリにコミットします。
ファイルの状態には追跡されている(tracked)や追跡されてない(untracked)があり、
追跡されている(tracked)状態の「変更されている(modified)」ファイルを「ステージされている(staged)」状態にするために行うことがaddです。commit(コミット)してpush(プッシュ)
- commitはローカルリポジトリにファイルを保存すること。
- pushはリモートリポジトリにローカルリポジトリを保存すること。
gifだと分かりやすく新しいファイルのみpushしていますが、実際はリポジトリごとpushしています。
ここで行っているadd,commit,pushコマンド
$ git add [file] $ git commit -m "[comment]" $ git push -u origin mastercloneとpullの違い
ローカルリポジトリがあるかないかです。
つまり自分のPCにデータがあるかないかです。
- cloneはローカルリポジトリがないとき
- pullはローカルリポジトリがあるとき
clone
リモートリポジトリにリポジトリがあるがローカルリポジトリにリポジトリがない時に行います。
つまり、サーバにだけデータベースがあって自分のPCにデータベースがない時に使用するコマンドです。
ここで行っているcloneコマンド
$ git clone [URL]pull
他人がリモートリポジトリにもリポジトリが変更した時、自分もそのリポジトリをローカルリポジトリにダウンロードする必要があります。
つまり他人がサーバにデータを保存した時、それをダウンロードするために使用するコマンドです。
ここで行っているpushコマンド
$ git pull origin masterコマンドの流れ
ローカルリポジトリをGitHubにpushする
1回目
$ mkdir [file name] $ cd [file name] $ echo "hello,world" >> README.md $ git init $ git add [file name] $ git commit -m "[comment]" $ git remote add origin [URL] $ git push -u origin master2回目以降
$ git add . $ git commit -m "comment" $ git push -u origin masterリモートリポジトリからローカルリポジトリにcloneしてくる
$ git clone [URL]リモートリポジトリからローカルリポジトリにpullしてくる
$ git pull origin masterまとめ
- バージョン管理には種類がある。
- リポジトリはファイルの保存場所
- アップロードはaddしてcommitしてpush
- ダウンロードはclone or pull
参照
- 投稿日:2019-12-13T18:51:17+09:00
Sinatra
事の発端
Sinatraというワードがググっている最中に出てきてなんぞや?と思い調べて見る。
Sinatraとは
Sinatra(Padorino)のテンプレート。
Sinatoraいじったことないけれどw
Sinatraは「ruby,ruby on rails勉強しても、いまいち覚えられているかわからない・・・.」
といったときにSinatora。特徴
超簡単にかけるらしい。
もちろんSinatraインストール必須。
インストールだけ完了しました。
今後使うかもしれないし。※まだSinatraについては勉強中なので、この記事は完成ではありません。
完成できない理由としては、rubygemなど他の優先順位が高い勉強をしなければならないからです。参考にしたサイト
- 投稿日:2019-12-13T16:40:42+09:00
コンフリクト解決を少しだけ楽にする
解決したい問題
マージやリベースでコンフリクトが発生したとき、簡単な競合であればできるだけ手で編集はしたくないですよね。
そこで使うのが
git checkoutの--theirsと--oursオプションですが、追加する変更同士のコンフリクトは、たまに両方を採用したい場合もあります。こういうコンフリクトを
$ git diff diff --cc test/test-foo.rb index dfbf2cc,f42377c..0000000 --- a/test/test-foo.rb +++ b/test/test-foo.rb @@@ -8,7 -8,7 +8,11 @@@ class TestFoo < Test::Unit::TestCas def test_bar assert_equal(0, @foo.bar(0), "bar(0) should have been perfomed correctly") ++<<<<<<< HEAD + assert_equal('baz', @foo.bar('baz'), "bar('baz') should have been perfomed correctly") ++======= + assert_equal('qux', @foo.bar('qux'), "bar('qux') should have been perfomed correctly") ++>>>>>>> develop2 end def teardownこうしたり
def test_bar assert_equal(0, @foo.bar(0), "bar(0) should have been perfomed correctly") assert_equal('baz', @foo.bar('baz'), "bar('baz') should have been perfomed correctly") assert_equal('qux', @foo.bar('qux'), "bar('qux') should have been perfomed correctly") endこうしたい
def test_bar assert_equal(0, @foo.bar(0), "bar(0) should have been perfomed correctly") assert_equal('qux', @foo.bar('qux'), "bar('qux') should have been perfomed correctly") assert_equal('baz', @foo.bar('baz'), "bar('baz') should have been perfomed correctly") end解決方法
VSCodeを使っていれば "Accept both changes" というオプション1があり、手で編集しなくても両方の変更を採用した状態にできます。Atomをつかっていると、さらに "Resolve as Theirs then Ours" というオプション2もあって、theirs -> ours の順に両方をマージした状態にできるようです。
ところがコマンドラインでgitを使っていると、そういう手段は提供されていないように思います。そこで、これを解決するだけの拡張を作りました。リポジトリはこちらです。
https://github.com/sabmeua/git-accept
中身はコンフリクトのマーク
<<<<<<<=======>>>>>>>をsedで見つけて置換しているだけです。
下のように使います。$ git accept ours-then-theirs test/test-foo.rb # ours-then-theirs の順にマージ $ git diff diff --cc test/test-foo.rb index dfbf2cc,f42377c..0000000 --- a/test/test-foo.rb +++ b/test/test-foo.rb @@@ -8,7 -8,7 +8,8 @@@ class TestFoo < Test::Unit::TestCas def test_bar assert_equal(0, @foo.bar(0), "bar(0) should have been perfomed correctly") + assert_equal('baz', @foo.bar('baz'), "bar('baz') should have been perfomed correctly") + assert_equal('qux', @foo.bar('qux'), "bar('qux') should have been perfomed correctly") end def teardown $ $ git accept cancel test/test-foo.rb # cancel で 3-way merge の状態をチェックアウト $ git diff diff --cc test/test-foo.rb index dfbf2cc,f42377c..0000000 --- a/test/test-foo.rb +++ b/test/test-foo.rb @@@ -8,7 -8,7 +8,11 @@@ class TestFoo < Test::Unit::TestCas def test_bar assert_equal(0, @foo.bar(0), "bar(0) should have been perfomed correctly") ++<<<<<<< ours + assert_equal('baz', @foo.bar('baz'), "bar('baz') should have been perfomed correctly") ++======= + assert_equal('qux', @foo.bar('qux'), "bar('qux') should have been perfomed correctly") ++>>>>>>> theirs end def teardown $ $ git accept theirs-then-ours test/test-foo.rb # theirs-then-ours で逆順にマージ $ git diff diff --cc test/test-foo.rb index dfbf2cc,f42377c..0000000 --- a/test/test-foo.rb +++ b/test/test-foo.rb @@@ -8,7 -8,7 +8,8 @@@ class TestFoo < Test::Unit::TestCas def test_bar assert_equal(0, @foo.bar(0), "bar(0) should have been perfomed correctly") + assert_equal('qux', @foo.bar('qux'), "bar('qux') should have been perfomed correctly") + assert_equal('baz', @foo.bar('baz'), "bar('baz') should have been perfomed correctly") end def teardownあとは
addしてmerge --continueするだけです。これを使ってちょっとだけ手数が減らせる?んじゃないかと思っています。
簡単ですが以上です。
- 投稿日:2019-12-13T16:25:13+09:00
git rebaseの方法とコンフリクトなどで失敗した時の対処方法まとめ
git rebase では、~でそのブランチのヘッドから何番目までを指定してリベースが行える。
細かいコミットをまとめる際に利用することが多いターミナル上でツリーを表示
$ git log --oneline --graph --decorateコミットと現在のブランチを確認
リベースの実行
$ git rebase -i HEAD~~~~順序変更を含めて次のように、pickをsまたはsquashへ変更します(今回はs)。
====================================== 例 pick 8145f1c Fix screen rotation problem s 646bf79 Fix screen rotation problem ====================================== :wq するとコミットメッセージを統合するためのエディタが2回開きます。 ====================================== # This is a combination of 2 commits. # The first commit's message is: Fix screen rotation problem # This is the 2nd commit message: Fix screen rotation problem ====================================== :wqローカルとリモートに差分が出るので強制プッシュを行う
$ git push -f失敗した場合
rebaseに失敗したら以下のコマンドでやり直し
$ git rebase --abortコンフリクト時の対応
rebase でもマージと同じように、コンフリクトが発生する可能性があります。
コンフリクトが発生した場合、コンフリクトを解消してから$ git rebase --continueを実行することで、rebase を続けることができます。
競合を解決した結果、一つ前のコミットとの違いがなくなってしまった場合
$ git rebase --skipとしてそのコミットをスキップします。
rebase をあきらめる場合
$ git rebase --abortリベースを行なったが取り消したい場合
git pull で、ローカルを強制上書きする(厳密には上書きではない)
リモートの最新を取ってきてくる
$ git fetch origin masterローカルのmasterを、リモート追跡のmasterに強制的に合わせる
$ git reset --hard origin/master
- 投稿日:2019-12-13T15:32:01+09:00
Git for Windowsで認証情報を保存しない方法
Git for Windowsでは認証情報を自動的に保存してくれるが、共有PCでは認証情報の保存をして欲しくないので保存しない方法のメモ
設定方法1
gitconfigのcredential.helperから設定。
注意点としてはgitconfigはsystem>global>localの順に参照される。
たぶんデフォルトのままインストールした場合はsystemでcredential.helper = managerとなっているのでこれを削除。git config --system -e編集モードに入って
[credential] helper = managerこの欄を削除して保存。なお、systemの編集は管理者権限が必要なので注意。
設定方法2
Gitインストール時にGit Credential Managerのチェックを外しておく。
インストール後であればGit Credential Managerをアンインストール。おまけ
すでに保存済みの認証情報の削除
コントロールパネル>すべてのコントロール パネル項目>資格情報マネージャー
Windows資格情報から削除できる。
- 投稿日:2019-12-13T13:15:09+09:00
git hookで分散バックアップ
プッシュ後に別のWindowsの共有ディレクトリなどにクローンさせて分散バックアップを行います。
サーバーサイド(リモートリポジトリ)のhook/post-updateを作成し以下スクリプトを記述します。
to_clone_pathを変える事でクローンを作る場所を変更出来ます。
post-update#!/bin/bash # リポジトリの情報取得 localrepo_path=`pwd` repo_name=`echo "${localrepo_path}" | sed "s/.*\///g"` branch_name=`echo "${1}" | sed "s/.*\///g"` # クローンを作成するフォルダのパスを指定 to_clone_path="//IPアドレス/共有ディレクトリのパス" # クローン git clone "${localrepo_path}" "${to_clone_path}_${branch_name}" -b "${branch_name}"
- 投稿日:2019-12-13T12:46:28+09:00
gitコツコツ勉強法(半年で使えるようになるまで)
概要
本文は筆者がgitをそこそこ使えるようになるまでの道のりです。
git未修者に多少の参考になればと思い、自分が勉強したことを記載します。やったこと
- udemy見た
- 書籍で概要を学んだ
- N予備校で実際に使った
- vscodeのプラグインで理解した概念をさらに楽に使えるようにした
以下ではそれぞれについて記載していきたいと思います。
udemy見た
git関係では以下2つを見ました。なぜ見たかというと、テキストで勉強するにはあまりにハードだったからです。
(お恥ずかしい話、猿でもわかるgit入門を挫折した人間なので)はじめてのGitとGitHub
https://www.udemy.com/share/100dDgBUAac19SQX4=/
- 無料なのでとりあえず見てみるといいと思いますもう怖くないGit!チーム開発で必要なGitを完全マスター
https://www.udemy.com/share/1004bOBUAac19SQX4=/
なお、udemyは定価で買わずに検索かけるなり、セールス期間を利用して、千円代で動画を購入することを強くお勧めします。
書籍で概要を学んだ
独習Git(アマゾンリンク張っちゃってます)
計3周やりました(合計で30時間くらい)。
1周目は全て馬鹿丁寧に。
2周目はvsCode使って同じ作業をどうすればできるかを調べながら。
3周目は念のための復習で。なお、私の場合は、章末の課題については気が向いたらやる感じでした。
あと、5章のGitGUIと19章のサードパーティー、それからちょくちょく挟まれるGitGUIでやる方法は、よほどのことがない限り使う機会がないのでやらなくてもいいと思います。また、sourcetreeに関する書籍も何冊かやりましたが、vscodeなどのエディタには似たような機能があるため、何か特別な事情がない限りオススメはしないです。
N予備校で実際に使った
もしもあなたが実際に仕事で接する機会がない場合、独習gitでも触れはしますが、N予備校で実践的な使い方のレクチャがあるのでそちらで学んでみることをお勧めします。
なお、2章の11「GitHub で Web サイト公開」から16「ソーシャルコーディング」までに詳しい解説があり、以降でも課題の提出はgithubを使うため、非常に実践的です。https://www.nnn.ed.nico/pages/programming/
vscodeのプラグインで理解した概念をさらに楽に使えるようにした
デフォルトのソース管理、それから、リモートやブランチ、それからスタッシュについてはGit Lensってプラグイン使ってください。
詳しい使い方はこちらの記事が参考になると思います。結論
gitは以下に紹介する本と動画でコツコツ勉強すると半年で現場で使用するのに先輩の助けがいらないくらいに使えるようになりますのでめげずに頑張りましょう。
- 投稿日:2019-12-13T12:08:45+09:00
特定のリポジトリに特定のユーザにadmin権限を付与する方法
概要
あるユーザに、組織のowner権限は与えずに
特定のリポジトリだけ自由に編集する(admin)権限を与える方法方法
開発者チームと別に、管理者チームを作成し、
対象リポジトリにadmin権限を与える設定例
メンバー
- 開発者
- Aさん
- Bさん
- Cさん
- 管理者
- Aさん
権限
開発者には、αリポジトリのWrite権限、βリポジトリのRead権限を与えたい。管理者には、αリポジトリのAdmin権限を与えたい。設定内容
以下のチームを作成する。
- 開発者チーム
- メンバー : Aさん、Bさん、Cさん
- 権限 : αリポジトリのWrite権限、βリポジトリのRead権限
- 管理者チーム
- メンバー : Aさん
- 権限 : αリポジトリのAdmin権限
備考
- 複数チームに所属しているユーザは、どちらか権限が強い方の設定が適用される。
- Aさんは
開発者チーム側で βリポジトリのRead権限があるので、 βリポジトリを見れる。- ぐぐるとよく 所有権の委譲 が引っかかって(これかな?)と思いがちだが これは組織の資産を誰かに委譲する、という機能なのでダメ。絶対。
- 投稿日:2019-12-13T01:01:21+09:00
Githubって何よ
プログラミングを始めると、Githubってのを良く目にするようになった。
あのネコのキャラクターが書いてあるやつ。良くgitgub使いましょうとか書いてあるけど、果たしてどうなのだろうか。
必要なものなの!?Gitとは
Wikipedia先生によると
gitは、プログラムのソースコードなどの変更履歴を記録・追跡するための分散型バージョン管理システムである。Linuxカーネルのソースコード管理に用いるためにリーナス・トーバルズによって開発され、それ以降ほかの多くのプロジェクトで採用されている。
gitでは、各ユーザのワーキングディレクトリに、全履歴を含んだリポジトリの完全な複製が作られる。したがって、ネットワークにアクセスできないなどの理由で中心リポジトリにアクセスできない環境でも、履歴の調査や変更の記録といったほとんどの作業を行うことができる。これが「分散型」と呼ばれる理由である。
とされている。
意味わからないんですけど!
簡単にまとめると、
・オフラインでもプログラムの編集などができる
・その変更履歴も管理できるという事だそうな。
プログラミングでの開発は個人でもできるけど、チームで開発する事のほうが多いので、この機能は便利だ!!
だから必要な訳ね!
じゃあ、Githubはなんだろう?
hubっていうのは、中心とかそういう意味を表すものだった気がする。
じゃあ、Gitの中心という意味か?
Githubは、Gitの仕組みを利用して、自分の作品のコードやデザインコードを公開できるサービスの事。
代表的なのがGithubなだけで、このようなサービスを展開しているものも勿論ある。
Githubは「大手」というべき感じではないだろうか。
まとめ
つまり、Githubは、Gitの仕組みを利用して、自分の作品のコードやデザインコードを公開できるサービスの事である!!!
次回は、実際にGitを入れるという作業から公開までおこなったのでそれを書いて行こうと思う!!













