概要 GitHubのリポジトリをメール等でファイルで送る必要がある時などに利用できる、zipにまとめる方法をメモします。 方法 リポジトリを全て圧縮する場合 --formatでファイル型を指定 --outputでファイル名を指定 git archive HEAD --format=zip --output=hoge.zip 特定のディレクトリを圧縮する場合 --prefixでディレクトリの指定 git archive HEAD --prefix=app/ --output=hoge.zip

narumiと申します。

git cloneの後、意図せずGit submoduleが作成されてしまい、変更をステージに上げることが出来なくなってしまいました。原因と解決方法について自分の備忘録という意味でも記事にしたいと思います。
解決の過程をあまり覚えていないので分かりづらい点も多いと思いますが何卒ご了承ください。

gitをcloneしてからadd -Aとし、commitしようとしたときに下記のエラーが出ました。

On branch master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)
  (commit or discard the untracked or modified content in submodules)
 modified:   （ファイル名） (modified content)

この時点で原因が全く分かりませんでした。
git add -Aを行っているのに変更がステージされていない？という状況が初めてでした。

git statusで詳細を見てみる

...省略
(※abcdefg12345は適当な文字列です)

-Subproject commit abcdefg12345
+Subproject commit abcdefg12345-dirty

dirtyという記載を始めてみたのでこれについて調べてみると、dirtyと書かれている方がsubmoduleで登録しているリポジトリのようです。
ですがsubmoduleという言葉を初めて聞き、なおかつsubmoduleを登録した覚えがない(そもそもやり方を知らない)

色々と試行錯誤しましたがなかなかは上手くいきませんでした。幸いにも同様の症状で困っていた方の記事を見つけ問題解決に至りました。

参考にした記事

cloneする前、もしくはした後にgit initをしてしまった覚えがあります。
cloneするタイミングからやり直すことで無事解決しました。

gitは難しいですが、色々試しながら知識を深めていきたいと思います。

以上です。お読みいただきありがとうございました。
narumi

タイトルは嘘。

リモートへのgit pushを禁ずるために、ローカルでmasterブランチにgit commitができないようにした。
以下を、gitレポジトリ内に配置すればよい。

.git/hooks/pre-commit

branch=`git symbolic-ref HEAD`
if test "$branch" = "refs/heads/master" || test "$branch" = "refs/heads/main"; then
    echo "Direct commits to the master branch are not allowed."
    exit 1
fi

executableにする。

$ chmod +x .git/hooks/pre-commit      

すると、以下のようなエラーが出るようになった。

$ git commit -m 'test' --allow-empty    

Direct commits to the master branch are not allowed.

よし。

参考

• https://gist.github.com/vlucas/8009a5edadf8d0ff7430#gistcomment-2060400

弊社では数ヶ月前から自社内において開発を行うこととなり、徐々に参画メンバーが増えていっています。
(何かのサービスを運営するというよりは、社内業務用システムを自社で作ってしまおうという趣旨のものです。)

会社用のGitHubアカウントを個人個人で作成してもらい、各自git cloneして貰おうというところ

プロジェクトへの認証は済んでいるのにgit cloneできない

との声が上がったので、備忘録として解決までの工程をまとめます。

発生した問題

プロジェクトのリモートリポジトリをgit cloneしようとしても、not foundが出てしまいcloneができない。

$ git clone https://github.com/xxxxxxxxx/xxxxxxxxxxx.git

Cloning into 'xxxxxxxxxxx'...
remote: Repository not found.
fatal: repository 'https://github.com/xxxxxxxxx/xxxxxxxxxxx.git' not found

前提条件

• GitHub上のプロジェクトリポジトリに対して該当のGitHubアカウントは認証されている
• 二段階認証は未設定

原因

• ターミナルからのgit cloneにおいて、個人用のGitHubアカウントからプロジェクトリポジトリをgit cloneしようとしてしまっていた。
• このユーザーの切り替えがうまく行っていなかった。

問題のゴール

今回はプロジェクトのリポジトリをclone出来れば良いです。
git configなどでユーザーを切り替える方法などもありますが、今回は触れません。
一旦仕事用に切り替えた後、また元に戻すといった作業が面倒だったり、切り替え忘れなどを懸念する人もいました。

解決手段

とりあえずは以下の方法。

$ git clone https://{ユーザ名}:{パスワード}@github.com/xxxxxxxxx/xxxxxxxxxxx.git

会社用のGitHubアカウントのユーザー名、パスワードをそれぞれ該当の箇所に入れた上でgit cloneしました。

弊社では以降の作業は全てSourceTreeに任せてしまっているので、あとはSourceTree側でcloneしたリポジトリを追加しておけば、Gitコマンドを覚えることなく簡単にプロジェクトへ新規参入できるというわけです。
(コマンド覚えられないし裏で何しているのかもわからないから絶対良くないと思う...)

最後に

not foundの問題はこれで解消されました。
ただ解決方法に関して一時凌ぎ感が強いので、もっとスマートな方法があるのではと思っています。
引き続き模索していきます。

本記事について

プログラミング初心者がGitとGitHubに関する知識を学んだので、その備忘録として載せております。

どうかお手柔らかにお願いいたしますm (- -)(_ _)ペコリ

Git

・ソースコードなどのファイルやフォルダの変更履歴を記録・追跡するためのバージョン管理。

・ファイルのセーブポイントを時系列で追える。時系列に沿った保管が可能。
・ソースコードのバージョンを管理。

・変更ごとにファイルをいちいち更新するという作業がなくなる。
・いつ、誰が、どこを編集したのかがわかる。

GitHub

・GItの仕組みを利用し複数人での開発ができるようなwebサービス。

・クラウドサービスのようにファイルの共有や同時編集、保存ができる。
・世界中の人が自分のプログラムやデザインデータを保存している。

・Gitを利用して複数人での開発をサポートしてくれるサービス
・mergeメソッドで追記も可能

GitとGitHubについて

・アプリケーションを作っている時に、作り直したいという時がある。そこで、ある段階まで残したいなという時にGitで管理してくれる。バージョンの管理の実現。

・多数で開発していると他の人が書いたコードを間違って消してまうこともある。予期せぬ削除やファイルの共有が行いづらい時にGitとGitHubというサービスを組み合わせると便利。

アプリケーション開発における問題

・コードの開発段階で、あるところまで元に戻したいけど、どのファイルをどのように編集すれば良いかわからない
・複数人による開発の際、他人の作ったコードを消してまう。

GItを用いたバージョンの管理

・まずファイルの内容を保存するための箱のようなものを用意する。
・保存する枠組みを用意する必要がある。
・この箱をリポジトリという。

リポジトリ

・Gitの管理下にあるファイルやディレクトリの変更履歴を保管しておく箱のような場所。
リ・ポジトリにはローカルリポジトリとリモートリポジトリがある

ローカルリポジトリ

・自分のPC上（ローカル環境）におくリポジトリ（保管用の箱）
・自分のタイングで更新ができる。保存できるスペース。大枠

リモートリポジトリ

・外部サーバー上におくリポジトリ（保管用の箱）
・インターネットを介している。自分のPCとは別の場所。
・ローカルリポジトリと同期して変更修正を行い、リモートリポジトリを反映させる。
→他の人に自分の作成したコードを共有できたり、チーム開発をしやすくしたりする。

・複数人の開発で使う。
・１人の時でも使える。Gitを使っているユーザーからここが不安とコメントすれば世界中の人からアドバイスをくれる。（プルリクエスト）選択的にこのフォルダにアドバイスをくれと言える。プルリクエストは誰かにチェックしてもらうのに役立つ。

commit

ローカルリポジトリにファイルやディレクトリを保存、変更修正すること。
→時系列で変更修正の管理ができる、また遡ることできる。

コミットメッセージ

・「どのような修正変更なのか」をわかりやすくするためにメモを添える。
・HTML CSS、Rubyのコメントのようなもの。
・中身を確認しなくてもいい。

.DS_Store

・Gitで管理しないようにする不要な変更履歴。ディレクトリの情報を記録するファイル。
・Gitの管理で手間になる。

push

commitで変更を行うと一時的にローカルリポジトリに保管されている状態になる。
→push　変更をリモートリポジトリに反映させること

commit log

commitの履歴の確認方法（Historyから確認可能）●commitの粒度（どの頻度でコミットするのかの頻度）

ある程度コミットは細かくした方がいい。

細かくcommitをするメリット

・作業の進捗を管理
・エラーが起こった際にどこでエラーが起こったかわかるので、エラーが起こった分岐点が分かり、それを境に前後比較できる

→ただ毎回GitHud Desktopを行き来するのは面倒
→それを解決するのがインデックスとaddの概念

インデックス（comittの対象←インデックスに保存されている内容）

変更修正が一時的に保存される場所

add（アド）

ファイルの追加、変更修正をインデックスに登録
すなわちcommitの対象とさせる。インデックスに箱詰めの段階ではまだcommitされていない。インデックスというジャンルに分けて、大きな保管庫リポジトリに保管している。保管庫の中にカテゴリー別で、データが保管されているので、データを取り出しやすい。インデックスは箱
リポジトリは倉庫、addは箱詰め。

GitHubを使うときの暗黙の了解

GitHubは複数人の開発や、１人で開発を行っていても世界中の人からアドバイスをもらうなど、コミュニケーションの中で利用されるウェブサービスなので開発の流れのルールが存在する。そのルールの一つとしてブランチがある。本流と言われる幹となるmasterブランチに影響を与えずに、独立した編集ができ、必要とあらば切り離しもでき、必要とあらば本流に内容を追加することができる。

ブランチ

コミットの連なり　コミットの連続
リポジトリで管理しているファイルやディレクトリの変更の流れ、毎回の変更

##ブランチは分岐可能
本流　→ masterブランチ
分岐したブランチ　→ トピックブランチ

トピックブランチのメリット

・複数人の開発においてMVCのファイルの同時作成、編集変更が起こった際に同じファイルを同時に編集できる。
・本流　masterブランチに影響を与えない
・ブランチを切ることで目的別に同時並行で開発できる
・不具合が発生した場合も対応が簡単になる

プルリクエスト

コミットごとの履歴とともに、各コミットにおける変更修正にコメントをつけることができる機能。誰にかに見てもらうもの。どのような機能に関するプルリクエストなのかwhat（ブランチに何を行ったのか）とwhy（なぜその実装を行ったのか）を記述していく。

whatの部分はアプリケーションの機能が複雑になると、コードをぱっと見ただけではわかりにくいから明記する必要がある。

whyの部分では実装目的を伝えることで欲しいアドバイスをもらえるので明記する必要がある。

マークダウンで書く

マークダウン　記法の一種

コードレビュー

コードの記述内容に関して問題ないか他者が確認を取ること
レビュアー　コードレビューの担当者

merge（統合）

分岐した履歴を戻して統合する手段

pull

・リモートリポジトリの変更をローカルリポジトリに取り込む操作
・リモートリポジトリの情報をローカルリポジトリに反映

LGTM （Looks good to me）

コードには問題ないと思う！

pullとcloneの違い

pull　

ローカルリポジトリとリモートリポジトリがもう既に紐づいている状態で、リモートリポジトリの情報をローカルリポジトリにpull（反映）すること

clone

リモートリポジトリが箱としてwebサービス上にあり、手元にローカルリポジトリが箱としてない状態で、リモートリポジトリからローカルリポジトリを作成すること

→pullとcloneでは作業を始めるデフォルトが違う。
　
自分のアプリケーションを他者に共有する場合のcloneではまず自分が自分のPCでローカルリポジトリを作成作業した後に、自分の作成したローカルリポジトリをリモートリポジトリにpush（反映）する。その反映したリモートリポジトリの情報を他者のPCのローカルリポジトリにpull（反映）する。

push（リモートリポジトリに反映すること）には権限が必要

他者がリモートリポジトリから共有されたデータをpushするには権限がいる。勝手にpushすることはできない。

片方だけ更新できている状態がよくありデータの差分を補う必要がある。（フェッチオリジン）
新しいブランチは今ある状態のマスターブランチをそのまま引き継ぐ。したがって起こりうることとして、自分が思った保存内容で反映されていないことがある。必ずマージの内容を確認、マスターブランチの内容を変更、更新時は確認する。pullした後に、マスターブランチに新規でブランチを作成した内容が反映されていない状態であれば、作業しているローカルのマスターブランチには更新情報が反映されていない状態となる。というのはマスターブランチが幹となり、そのままのマスターブランチの内容をブランチが引き継ぐからである。都度保存内容は確認。ブランチ（１）と（２）は独立しているため、タイムリーに作業するには一度マスターを更新された状態で作業する必要がある。

GitHubを使用するときの流れ

マスターからブランチを作成
ブランチで編集のちにコミット
ローカルとリモートのデータの更新の差分を解消するために、pushでリモートにデータを反映。
プルリクエストを作成公開
レビュアーが確認＋LGTM
リモートのマスターにマージ
リモートとマスターのデータの更新の差分を解消するためにpullでローカルにデータを反映

##ブランチを作成せずにマスターブランチ上でコードを書いてしまった場合
Bring my changes toを選択

stash

現在の作業を一時的に離脱したい、もしくは離脱して作業を元に戻したい時に使用

コンフリクト　

ブランチごとの内容の整合性が合わない現象（お互いごめんちゃいという現象、いざこざ）
→同じファイルを別の人が既に修正しているのでマージできない

コンフリクトを解消するためResolve Conflictsをクリック

複数人の開発ではコンフリクトは発生しやすい。

・コンフリクトを未然に防ごう
・ブランチ作成前にpullを行うこと（最新のマスターブランチの内容を反映させておくこと）
・複数人の開発の際は打ち合わせをしておく

発生のポイントを深掘り

・なぜ発生したのか
・再発防止に努める
・報告連絡相談＋確認

間違ってpushを押してしまった

pushした情報はローカルリポジトリに戻すことはできない。
しかしリモートリポジトリに間違ったcomittは取り消せる。

revert

commitされた変更とは異なる変更を追加することでcommitを取り消す。
指定するcommitを取り消しするためのcommitを追加で行う。

以上です。

目的

• リモートリポジトリの一覧を表示するコマンドをメモ的にまとめる

方法

1. ローカルリポジトリ内で下記コマンドを実行する。

   $ git branch -r