目的 急にGit上から削除したいファイルができたときの対処法を学ぶこと この記事が必要なA君の話 あなたはToDoアプリの個人開発を始めました Gitを使いバージョン管理もバッチリ行っています しかし！ 開発から10日経ったある日、「機密情報が入ったテキストファイル(Secret.txt)をGit上にあげていたこと」に気づく やばい、Git上から消さないと。また、今後もずっとGit上へあげないようにしなければ。 → この記事の出番です 流れ ① : 対象ファイル(Secret.txt)を、現在のGit上から削除したい。(作業フォルダからは削除しない) ターミナル.app git rm -r --cached Secret.txt ・git rm -r --cached によって、作業フォルダにファイル(Secret.txt)を残し、Git上からのみファイルを削除できる。 ！ gir rm Secret.txtだと、作業フォルダからもファイル(Secret.txt)が削除される. ① を図で説明 ↓ ファイルの確認 ↓ コマンドでGit上からファイルを削除 ↓ Git上で削除されたことを確認 ↓ フォルダ内にはファイルが残っていることを確認 ② : 対象ファイル(Secret.txt)を、今後Git上にあげないようにする ターミナル.app echo "Secret.txt" > .gitignore ・.gitignore にGit上へあげたくないファイル名を記載すると、次回の add からGitへあげられなくなる。.gitignore以下の階層全てのフォルダに、.gitignoreの効果が適応される。 ・echo "入力したい文字" > ファイル名 によって、ファイルと入力したい文字をセットで新規作成できる。 注意 .gitignoreを作成後は以下の「add」「commit」を実行してください git add . git commit -m "コミットメッセージ" ② を図で説明 ↓ .gitignoreファイルを作成 ↓ .gitignoreファイルの中身を確認 *↓ add と commit * ③ : 本当に対象ファイル(Secret.txt)がGit上へあがらないか確認 Secret.txt へ何か変更を加えて、git statusで確認。 git status は、Gitの対象となるファイルの状態(add済みかどうかなど)を確認できる そのため、git status を実行し、Secret.txtが表示されない場合は、Secret.txtがGit上へ上がることはない という意味になる。 　③ を図で説明 ↓ Secret.txtに変更を加える ↓ Gitの対象になっていないか確認 OK!

0.事象 リポジトリをpublicにするのが恥ずかしいので、privateに設定したが、 Azure上仮想マシン(centos)からgit cloneを実行するとエラーが発生する。 [xxx@xxx xxx]# git clone https://github.com/xxx/xxx.git Cloning into 'xxx'... Username for 'https://github.com': xxx Password for 'https://xxx@github.com': remote: Support for password authentication was removed on xxx, xxx. Please use a personal access token instead. remote: Please see https://github.blog/2020-12-15-token-authentication-requirements-for-git-operations/ for more information. fatal: Authentication failed for 'https://github.com/xxx/xxx.git/' 1.環境 Azure環境OS:CentOS Linux release 7.9.2009 (Core) 2.解決策 github上で、cloneができる権限を付与したtokenの発行を行い、 パスワード入力の際にtokenを使用する。 1)githubのwebUI右上のアイコンをクリック。 2) settingsをクリック。 3) 画面を少しスクロールして「Developer settings」をクリック。 4) 「Personal access tokens」をクリックして、「Generate new token」をクリック。 5) 適当にNoteを入力、期間を選択し、「repo」にチェックを入れる。 6) 画面をスクロールし、Generate token をクリック 7) 画面に長い文字列が表示されるので、それをテキスト等に保存しておく。 8) 仮想マシンにアクセスして、git cloneコマンドをたたいてユーザを入力したあと、 　パスワードが聞かれると思うので、そのタイミングで先ほどの長い文字列をペーストするとclone完了。 3.まとめ github　difficult but useful

短いオプション(ハイフン1つ(-)に続く) 長いオプション(ハイフン2つ(--)に続く) 短いオプションはおまとめできる(割と普通) -a -b は -ab とできる。 長いオプションは、おまとめはできない(割と普通) 長いオプションは 前に no- が付けられる --hogehoge とあったとき --no-hogehoge とできる。 マニュアルページに結構書いてあるけども、書いてないのでもぢつは指定できる。意味のある動作になるかどうかは実装依存である。 例えば git add --patch --no-patch とすると、--patchの機能を取り消す。 git add -p --no-patch はOKである。 git add -p -no-p はNG(短いオプションには no- 形式は無いのである) no- とあるものは no- を外す事ができる。意味のある動作になるかどうかは実装依存である。 注意 通常は parse-option api を使うのでこの通りなのだけども、フルカスタムとかapiを使わないとかも可能なので、最終的にはコマンドごとの実装依存である。 詳しくは (翻訳) ※Examplesの test-parse-options.c は t/helper/ フォルダ内にあります。

git・githubに対する理解があまかったのであらためて再入門したら、理解していないところがわかってきたので改めて説明する。 [ HEAD ] 現在使用しているブランチの先頭のこと。 コミットを指定するときに~(チルダ)をHEADの後ろにつけることでHEADからの相対位置を表せる。HEAD~1（HEADの一個手前） ^（キャレット）を使うと親が複数あったときにどの親かを選択できる。 [ margeの種類 ] fast-forward(早送り)マージ masterから分岐したdevelopブランチに変更を加えて、masterには変化がない状態でマージをしたとき、masterはdevelopのブランチに移動するだけで完了する。 両方に変更があった場合のマージ 新しく両方の変更が取り込まれたコミットが作られ、masterブランチの先頭はこちらに移動する。 ☆ non fast-forwardマージを指定するとfast-forwardマージができる場合でも、新しくコミットを作ってマージできる。これによってブランチごとの変更の特定が容易になる。 [ rebase ] 分岐元のコミット履歴が最新の同一内容の新しいコミットが作成される。つまりコミット履歴が一直線になり、あとはfast-forwardマージを実行すれば変更は統合される。 rebaseを使用する場合、rebase後はcontinueでfast forward margeができる。 → 同じブランチから切られた複数ブランチが同時並行で修正されている場合などに便利。 [ pull ] 動作としてはmargeと同じだが、fast-forwardではない場合自動でマージコミットが作られる。 fetch+margeなので、pullしたときに新しくマージコミットが作られてしまう。 できるだけ、fetch + rebase で行ったほうがコミット履歴がきれいになる。 [ tag ] 軽量タグ ローカルで一時的に使用する使い捨て用だったりする。 注釈付きタグ コメントや署名を追加できたりとできることが多く、リリースタグで使われる。 [ コミット操作 ] amend　直前のコミットを修正 revert　過去のコミットを打ち消すコミットの作成 reset　コミットの状態を戻す 　・soft　コミットだけを戻す 　・mixed　インデックス内のコミットごと戻す 　・hard　ワークツリーでの変更までなかったことにする。 cherry-pick　別ブランチのコミットを抜き取る rebase -i　コミットの整理（統合）・書き換え・入れ替え・削除ができる squash　マージする際にコミットをすべてまとめてからマージする git・githubの運用の仕方に関すること 【git flow】 ・メインブランチ masterとdevelopの２つのブランチがある。 ・サポートブランチ タスクごとに「feature」「release」「hotfixes」のいずれかのブランチを作成し、作業を行う。 feature （master、develop、release-、hotfix-以外） developから分岐したブランチ。developにマージされる。 機能開発やバグ修正などの作業に利用する。 release（release-*） developから分岐したブランチ。masterとdevelopにマージされる。 リリース準備作業を行う hotfixes（hotfix-*） masterから分岐したブランチ。masterとdevelopにマージされる。 リリース後に緊急の修正作業が発生した場合は、masterブランチからホットフィックスブランチを作成し、修正作業を行う。 ☆　git flowというツールをinstallすることで、git flowに沿ったブランチ構成で開発ができる。 git flow ~というコマンドを使えばより効率的な開発が可能。 【GitHub Frow】 git frowに比べるとシンプルだが以下のルールが有る。一日に複数回デプロイするようなシステムで有効。 １，masterブランチは常にデプロイ可能である ２，作業用ブランチをmasterから作成する ３，作業用ブランチを定期的にプッシュする ４，プルリクエストを活用する ５，プルリクエストが承認されたらmasterへマージする ６，masterへのマージが完了したら直ちにデプロイを行う