20191213のGitに関する記事は11件です。

Gitマージでdry-runをやってみる

調べればいくらでも出てきそうな内容だけど自分でも書いてみる

$ git merge --no-commit --no-ff ブランチ名

元に戻すときは

$ git merge --abort
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

gitについて自分のにわか知識を撲滅したい 基本編

gitについて自分のにわか知識を撲滅したい 基本編

こちらはITRC Advent Calendar 2019の13日目の記事です。

目的

自分のにわか知識を撲滅したく調べてみました。
今回はgitの歴史や仕組み、自分がなんとなく使っていた基本的なコマンド中心です。

目次

  • gitとは
  • バージョン管理とは
  • リポジトリとは
  • ローカルバージョン管理システム
  • 集中バージョン管理システム
  • 分散バージョン管理システム
  • Gitを使用する上で最低限必要な用語
  • ローカルリポジトリとリモートリポジトリ
  • gitサーバとは
  • なんとなく使っていたコマンド達
  • commitとpushについて
  • cloneについて
  • pullについて
  • コマンドの流れ
  • 参照

gitとは

  • 分散バージョン管理システム
  • スナップショットでファイルを保存

バージョン管理システムとは

ファイルを以前のバージョンに戻したり、変更履歴を保存するためや誰がいつファイルを変更したのか確認のためしたりなどを行え、
かつ、それらをリポジトリで管理するのがバージョン管理システムです。

参考にした文章

「バージョン管理」とは何でしょうか。また、なぜそれを気にする必要があるのでしょうか。 バージョン管理とは、一つのファイルやファイルの集合に対して時間とともに加えられていく変更を記録するシステムで、後で特定バージョンを呼び出すことができるようにするためのものです。 本書の例では、バージョン管理されるファイルとしてソフトウェアのソースコードを用いていますが、実際にはコンピューター上のあらゆる種類のファイルをバージョン管理のもとに置くことができます。
もしあなたがグラフィックス・デザイナーやウェブ・デザイナーで、画像やレイアウトの全てのバージョンを保存しておきたいとすると(きっとそうしたいですよね)、バージョン管理システム(VCS)を使うというのはいい考えです。 VCSを使うことで、ファイルを以前の状態まで戻したり、プロジェクト丸ごとを以前の状態に戻したり、過去の変更履歴を比較したり、問題が起こっているかもしれないものを誰が最後に修正したか、誰がいつ問題点を混入させたかを確認したりといった様々なことができるようになります。 また、VCSを使うと、やっていることがめちゃくちゃになってしまったり、ファイルを失ったりしても、普通は簡単に復活させることができるようになります。 それに、これらのことにかかるオーバーヘッドは僅かなものです。

参照:git バージョン管理に関してより

リポジトリとは

ファイルなどの保存場所。

決してデータベースやコンテナではないですが似たようなものです。

repo.png

バージョン管理システムの種類

おおまかに3種類のバージョン管理システムがある。

  • ローカルバージョン管理システム
  • 集中バージョン管理システム
  • 分散バージョン管理システム

ローカルバージョン管理システム

ローカルにのみリポジトリがある。

ローカルバージョン管理システム

参考にした文章

どのディレクトリにいるのか忘れやすく、うっかり間違ったファイルに書き込んだり、上書きするつもりのないファイルを上書きしてしまったりします。
この問題を扱うため、はるか昔のプログラマは、ローカルのVCSを開発しました。それは、バージョン管理下のファイルに対する全ての変更を保持するシンプルなデータベースによるものでした。

参照:git ローカルバージョン管理システムより

集中バージョン管理システム

1個のサーバーを用意してあげてそこのリポジトリに保存。

集中バージョン管理システム

参考にした文章

次に人々が遭遇した大きな問題は、他のシステムを使う開発者と共同作業をする必要があるということです。
バージョン管理されたファイルを全て持つ一つのサーバーと、その中心点からファイルをチェックアウトする多数のクライアントからなっています。 長年の間、これはバージョン管理の標準でした。

参照:git 集中バージョン管理システムより

分散バージョン管理システム

ローカルにもサーバーにもリポジトリがある。
もしサーバーが死んでも大丈夫()。

分散バージョン管理システム

参考にした文章

ここで分散バージョン管理システム(DVCS)の出番になります。 DVCS(Git、Mercurial、Bazaar、Darcsのようなもの)では、クライアントはファイルの最新スナップショットをチェックアウト(訳者注:バージョン管理システムから、作業ディレクトリにファイルやディレクトリをコピーすること)するだけではありません。リポジトリ(訳者注:バージョン管理の対象になるファイル、ディレクトリ、更新履歴などの一群)全体をミラーリングするのです。 そのため、あるサーバーが故障して、DVCSがそのサーバーを介して連携していたとしても、どれでもいいのでクライアント・リポジトリの一つをサーバーにコピーすれば修復できます。 クローンは全て、実際は全データの完全バックアップなのです。

参照:git 分散バージョン管理システムより

スナップショットで、差分ではない

commitが分かれば納得できると思う。
分散バージョン管理システムは一回一回全保存。
その他だと編集したファイルだけ保存。

  • 分散バージョン管理システム
    スナップショット

  • その他のバージョン管理システム
    a

参考にした文章

Gitと他のVCS (Subversionとその類を含む)の主要な相違は、Gitのデータについての考え方です。 概念的には、他のシステムのほとんどは、情報をファイルを基本とした変更のリストとして格納します。 これらのシステム(CVS、Subversion、Perforce、Bazaar等々)は、図1-4に描かれているように、システムが保持しているファイルの集合と、時間を通じてそれぞれのファイルに加えられた変更の情報を考えます。
Gitは、この方法ではデータを考えたり、格納しません。 代わりに、Gitはデータをミニ・ファイルシステムのスナップショットの集合のように考えます。 Gitで全てのコミット(訳注:commitとは変更を記録・保存するGitの操作。詳細は後の章を参照)をするとき、もしくはプロジェクトの状態を保存するとき、Gitは基本的に、その時の全てのファイルの状態のスナップショットを撮り(訳者注:意訳)、そのスナップショットへの参照を格納するのです。 効率化のため、ファイルに変更が無い場合は、Gitはファイルを再格納せず、既に格納してある、以前の同一のファイルへのリンクを格納します。 Gitは、むしろデータを一連のスナップショットのように考えます。

参照:git Gitの基本より

容量についての疑問点

ファイルの容量の確認

duコマンドで確認できる。duコマンドはディスクの使用量がわかる。

$ du -sh .git/objects/

全保存ってことは

ファイルの容量は増えていくばかり...
と思ったら、git-pack-objectsなるものがあり、勝手に圧縮してくれるすぐれものです。

Gitを使用する上で最低限必要な用語

  • ローカルリポジトリ
  • リモートリポジトリ
  • Gitサーバ
  • add
  • commit(コミット)
  • push(プッシュ)
  • clone(クローン)
  • pull(プル)

リポジトリとは(復習)

repo.png

ローカルリポジトリとリモートリポジトリ

  • ローカルリポジトリは自分のPC内にあるリポジトリのこと
  • リモートリポジトリはGitサーバにあるリポジトリのこと

repo_git_1.png

Gitサーバ

Git用に設定されたサーバです。

もちろん自分でたてられたりしますが、
GitHubGitLabなどの無料で使えるクラウドサーバ(厳密には開発プラットホーム)もあります。

全体像

全体像はこんな感じ

repo_git_2.png

addとは

作業ファイルはリポジトリをコピーして「作業コピー」を取得します。
その作業コピーにたして変更を加えてあげることで、変更内容のスナップショットをリポジトリにコミットします。
ファイルの状態には追跡されている(tracked)や追跡されてない(untracked)があり、
追跡されている(tracked)状態の「変更されている(modified)」ファイルを「ステージされている(staged)」状態にするために行うことがaddです。

staging

commit(コミット)してpush(プッシュ)

  • commitはローカルリポジトリにファイルを保存すること。
  • pushはリモートリポジトリにローカルリポジトリを保存すること。

gifだと分かりやすく新しいファイルのみpushしていますが、実際はリポジトリごとpushしています。

gif_push_git.gif

ここで行っているadd,commit,pushコマンド

$ git add [file]
$ git commit -m "[comment]"
$ git push -u origin master

cloneとpullの違い

ローカルリポジトリがあるかないかです。

つまり自分のPCにデータがあるかないかです。

  • cloneはローカルリポジトリがないとき
  • pullはローカルリポジトリがあるとき

clone

リモートリポジトリにリポジトリがあるがローカルリポジトリにリポジトリがない時に行います。

つまり、サーバにだけデータベースがあって自分のPCにデータベースがない時に使用するコマンドです。

gif_clone_git.gif

ここで行っているcloneコマンド

$ git clone [URL]

pull

他人がリモートリポジトリにもリポジトリが変更した時、自分もそのリポジトリをローカルリポジトリにダウンロードする必要があります。

つまり他人がサーバにデータを保存した時、それをダウンロードするために使用するコマンドです。

gif_pull_git.gif

ここで行っている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 master

2回目以降

$ 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

参照

Git 公式ドキュメント-日本語

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

gitについて自分のにわか知識を撲滅したい その1 基本編

gitについて自分のにわか知識を撲滅したい 基本編

こちらはITRC Advent Calendar 2019の13日目の記事です。
2日前の人: トラコンの感想
前の人: 限定公開でした。
次の人: VisualStudioCode 便利なプラグインをまとめてみた

目的

自分のにわか知識を撲滅したく調べてみました。
今回はgitの歴史や仕組み、自分がなんとなく使っていた基本的なコマンド中心です。

目次

  • gitとは
  • バージョン管理とは
  • リポジトリとは
  • ローカルバージョン管理システム
  • 集中バージョン管理システム
  • 分散バージョン管理システム
  • Gitを使用する上で最低限必要な用語
  • ローカルリポジトリとリモートリポジトリ
  • gitサーバとは
  • なんとなく使っていたコマンド達
  • commitとpushについて
  • cloneについて
  • pullについて
  • コマンドの流れ
  • 参照

gitとは

  • 分散バージョン管理システム
  • スナップショットでファイルを保存

バージョン管理システムとは

ファイルを以前のバージョンに戻したり、変更履歴を保存するためや誰がいつファイルを変更したのか確認のためしたりなどを行え、
かつ、それらをリポジトリで管理するのがバージョン管理システムです。

参考にした文章

「バージョン管理」とは何でしょうか。また、なぜそれを気にする必要があるのでしょうか。 バージョン管理とは、一つのファイルやファイルの集合に対して時間とともに加えられていく変更を記録するシステムで、後で特定バージョンを呼び出すことができるようにするためのものです。 本書の例では、バージョン管理されるファイルとしてソフトウェアのソースコードを用いていますが、実際にはコンピューター上のあらゆる種類のファイルをバージョン管理のもとに置くことができます。
もしあなたがグラフィックス・デザイナーやウェブ・デザイナーで、画像やレイアウトの全てのバージョンを保存しておきたいとすると(きっとそうしたいですよね)、バージョン管理システム(VCS)を使うというのはいい考えです。 VCSを使うことで、ファイルを以前の状態まで戻したり、プロジェクト丸ごとを以前の状態に戻したり、過去の変更履歴を比較したり、問題が起こっているかもしれないものを誰が最後に修正したか、誰がいつ問題点を混入させたかを確認したりといった様々なことができるようになります。 また、VCSを使うと、やっていることがめちゃくちゃになってしまったり、ファイルを失ったりしても、普通は簡単に復活させることができるようになります。 それに、これらのことにかかるオーバーヘッドは僅かなものです。

参照:git バージョン管理に関してより

リポジトリとは

ファイルなどの保存場所。

決してデータベースやコンテナではないですが似たようなものです。

repo.png

バージョン管理システムの種類

おおまかに3種類のバージョン管理システムがある。

  • ローカルバージョン管理システム
  • 集中バージョン管理システム
  • 分散バージョン管理システム

ローカルバージョン管理システム

ローカルにのみリポジトリがある。

ローカルバージョン管理システム

参考にした文章

どのディレクトリにいるのか忘れやすく、うっかり間違ったファイルに書き込んだり、上書きするつもりのないファイルを上書きしてしまったりします。
この問題を扱うため、はるか昔のプログラマは、ローカルのVCSを開発しました。それは、バージョン管理下のファイルに対する全ての変更を保持するシンプルなデータベースによるものでした。

参照:git ローカルバージョン管理システムより

集中バージョン管理システム

1個のサーバーを用意してあげてそこのリポジトリに保存。

集中バージョン管理システム

参考にした文章

次に人々が遭遇した大きな問題は、他のシステムを使う開発者と共同作業をする必要があるということです。
バージョン管理されたファイルを全て持つ一つのサーバーと、その中心点からファイルをチェックアウトする多数のクライアントからなっています。 長年の間、これはバージョン管理の標準でした。

参照:git 集中バージョン管理システムより

分散バージョン管理システム

ローカルにもサーバーにもリポジトリがある。
もしサーバーが死んでも大丈夫()。

分散バージョン管理システム

参考にした文章

ここで分散バージョン管理システム(DVCS)の出番になります。 DVCS(Git、Mercurial、Bazaar、Darcsのようなもの)では、クライアントはファイルの最新スナップショットをチェックアウト(訳者注:バージョン管理システムから、作業ディレクトリにファイルやディレクトリをコピーすること)するだけではありません。リポジトリ(訳者注:バージョン管理の対象になるファイル、ディレクトリ、更新履歴などの一群)全体をミラーリングするのです。 そのため、あるサーバーが故障して、DVCSがそのサーバーを介して連携していたとしても、どれでもいいのでクライアント・リポジトリの一つをサーバーにコピーすれば修復できます。 クローンは全て、実際は全データの完全バックアップなのです。

参照:git 分散バージョン管理システムより

スナップショットで、差分ではない

commitが分かれば納得できると思う。
分散バージョン管理システムは一回一回全保存。
その他だと編集したファイルだけ保存。

  • 分散バージョン管理システム
    スナップショット

  • その他のバージョン管理システム
    a

参考にした文章

Gitと他のVCS (Subversionとその類を含む)の主要な相違は、Gitのデータについての考え方です。 概念的には、他のシステムのほとんどは、情報をファイルを基本とした変更のリストとして格納します。 これらのシステム(CVS、Subversion、Perforce、Bazaar等々)は、図1-4に描かれているように、システムが保持しているファイルの集合と、時間を通じてそれぞれのファイルに加えられた変更の情報を考えます。
Gitは、この方法ではデータを考えたり、格納しません。 代わりに、Gitはデータをミニ・ファイルシステムのスナップショットの集合のように考えます。 Gitで全てのコミット(訳注:commitとは変更を記録・保存するGitの操作。詳細は後の章を参照)をするとき、もしくはプロジェクトの状態を保存するとき、Gitは基本的に、その時の全てのファイルの状態のスナップショットを撮り(訳者注:意訳)、そのスナップショットへの参照を格納するのです。 効率化のため、ファイルに変更が無い場合は、Gitはファイルを再格納せず、既に格納してある、以前の同一のファイルへのリンクを格納します。 Gitは、むしろデータを一連のスナップショットのように考えます。

参照:git Gitの基本より

容量についての疑問点

ファイルの容量の確認

duコマンドで確認できる。duコマンドはディスクの使用量がわかる。

$ du -sh .git/objects/

全保存ってことは

ファイルの容量は増えていくばかり...
と思ったら、git-pack-objectsなるものがあり、勝手に圧縮してくれるすぐれものです。

Gitを使用する上で最低限必要な用語

  • ローカルリポジトリ
  • リモートリポジトリ
  • Gitサーバ
  • add
  • commit(コミット)
  • push(プッシュ)
  • clone(クローン)
  • pull(プル)

リポジトリとは(復習)

repo.png

ローカルリポジトリとリモートリポジトリ

  • ローカルリポジトリは自分のPC内にあるリポジトリのこと
  • リモートリポジトリはGitサーバにあるリポジトリのこと

repo_git_1.png

Gitサーバ

Git用に設定されたサーバです。

もちろん自分でたてられたりしますが、
GitHubGitLabなどの無料で使えるクラウドサーバ(厳密には開発プラットホーム)もあります。

全体像

全体像はこんな感じ

repo_git_2.png

addとは

作業ファイルはリポジトリをコピーして「作業コピー」を取得します。
その作業コピーにたして変更を加えてあげることで、変更内容のスナップショットをリポジトリにコミットします。
ファイルの状態には追跡されている(tracked)や追跡されてない(untracked)があり、
追跡されている(tracked)状態の「変更されている(modified)」ファイルを「ステージされている(staged)」状態にするために行うことがaddです。

staging

commit(コミット)してpush(プッシュ)

  • commitはローカルリポジトリにファイルを保存すること。
  • pushはリモートリポジトリにローカルリポジトリを保存すること。

gifだと分かりやすく新しいファイルのみpushしていますが、実際はリポジトリごとpushしています。

gif_push_git.gif

ここで行っているadd,commit,pushコマンド

$ git add [file]
$ git commit -m "[comment]"
$ git push -u origin master

cloneとpullの違い

ローカルリポジトリがあるかないかです。

つまり自分のPCにデータがあるかないかです。

  • cloneはローカルリポジトリがないとき
  • pullはローカルリポジトリがあるとき

clone

リモートリポジトリにリポジトリがあるがローカルリポジトリにリポジトリがない時に行います。

つまり、サーバにだけデータベースがあって自分のPCにデータベースがない時に使用するコマンドです。

gif_clone_git.gif

ここで行っているcloneコマンド

$ git clone [URL]

pull

他人がリモートリポジトリにもリポジトリが変更した時、自分もそのリポジトリをローカルリポジトリにダウンロードする必要があります。

つまり他人がサーバにデータを保存した時、それをダウンロードするために使用するコマンドです。

gif_pull_git.gif

ここで行っている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 master

2回目以降

$ 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

参照

Git 公式ドキュメント-日本語

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Sinatra

事の発端

Sinatraというワードがググっている最中に出てきてなんぞや?と思い調べて見る。

Sinatraとは

Sinatra(Padorino)のテンプレート。
Sinatoraいじったことないけれどw
Sinatraは「ruby,ruby on rails勉強しても、いまいち覚えられているかわからない・・・.」
といったときにSinatora。

特徴

超簡単にかけるらしい。
もちろんSinatraインストール必須。
インストールだけ完了しました。
今後使うかもしれないし。

※まだSinatraについては勉強中なので、この記事は完成ではありません。
完成できない理由としては、rubygemなど他の優先順位が高い勉強をしなければならないからです。

参考にしたサイト

https://type.jp/s/itac/article5.html

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

コンフリクト解決を少しだけ楽にする

解決したい問題

マージやリベースでコンフリクトが発生したとき、簡単な競合であればできるだけ手で編集はしたくないですよね。

そこで使うのが 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 するだけです。

これを使ってちょっとだけ手数が減らせる?んじゃないかと思っています。
簡単ですが以上です。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

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
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

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資格情報から削除できる。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

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}"
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

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ってプラグイン使ってください。
詳しい使い方はこちらの記事が参考になると思います。

VSCodeの機能で最低限必要なGit操作をしたい!

結論

gitは以下に紹介する本と動画でコツコツ勉強すると半年で現場で使用するのに先輩の助けがいらないくらいに使えるようになりますのでめげずに頑張りましょう。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

特定のリポジトリに特定のユーザにadmin権限を付与する方法

概要

あるユーザに、組織のowner権限は与えずに
特定のリポジトリだけ自由に編集する(admin)権限を与える方法

方法

開発者チームと別に、管理者チームを作成し、
対象リポジトリに admin 権限を与える

設定例

メンバー

  • 開発者
    • Aさん
    • Bさん
    • Cさん
  • 管理者
    • Aさん

権限

  • 開発者 には、αリポジトリのWrite権限、βリポジトリのRead権限を与えたい。
  • 管理者 には、αリポジトリのAdmin権限を与えたい。

設定内容

以下のチームを作成する。

  1. 開発者チーム
    • メンバー : Aさん、Bさん、Cさん
    • 権限 : αリポジトリのWrite権限、βリポジトリのRead権限
  2. 管理者チーム
    • メンバー : Aさん
    • 権限 : αリポジトリのAdmin権限

備考

  • 複数チームに所属しているユーザは、どちらか権限が強い方の設定が適用される。
    • Aさんは 開発者チーム 側で βリポジトリのRead権限があるので、 βリポジトリを見れる。
  • ぐぐるとよく 所有権の委譲 が引っかかって(これかな?)と思いがちだが これは組織の資産を誰かに委譲する、という機能なのでダメ。絶対。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Githubって何よ

プログラミングを始めると、Githubってのを良く目にするようになった。
あのネコのキャラクターが書いてあるやつ。

良くgitgub使いましょうとか書いてあるけど、果たしてどうなのだろうか。
必要なものなの!?

Gitとは

Wikipedia先生によると

gitは、プログラムのソースコードなどの変更履歴を記録・追跡するための分散型バージョン管理システムである。Linuxカーネルのソースコード管理に用いるためにリーナス・トーバルズによって開発され、それ以降ほかの多くのプロジェクトで採用されている。

gitでは、各ユーザのワーキングディレクトリに、全履歴を含んだリポジトリの完全な複製が作られる。したがって、ネットワークにアクセスできないなどの理由で中心リポジトリにアクセスできない環境でも、履歴の調査や変更の記録といったほとんどの作業を行うことができる。これが「分散型」と呼ばれる理由である。

とされている。

意味わからないんですけど!

簡単にまとめると、

・オフラインでもプログラムの編集などができる
・その変更履歴も管理できる

という事だそうな。

プログラミングでの開発は個人でもできるけど、チームで開発する事のほうが多いので、この機能は便利だ!!

だから必要な訳ね!

じゃあ、Githubはなんだろう?

hubっていうのは、中心とかそういう意味を表すものだった気がする。

じゃあ、Gitの中心という意味か?

Githubは、Gitの仕組みを利用して、自分の作品のコードやデザインコードを公開できるサービスの事。

代表的なのがGithubなだけで、このようなサービスを展開しているものも勿論ある。

Githubは「大手」というべき感じではないだろうか。

まとめ

つまり、Githubは、Gitの仕組みを利用して、自分の作品のコードやデザインコードを公開できるサービスの事である!!!

次回は、実際にGitを入れるという作業から公開までおこなったのでそれを書いて行こうと思う!!

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む