はじめに Gitコマンドを打つときに、毎回ユーザ名、トークン(パスワード)を求められる時があります。 毎回打つのがめんどくさいが、GitのSSH設定を変えられないとか、一旦お手軽に済ませたいという場合、以下のコマンドを実行で一時的に回避できます。 コマンド git_command # 3600=60分間キャッシュを使い、入力不要にするgit config --global credential.helper 'cache --timeout=3600' さいごに とりあえずお手軽にしたいときはこれ。

はじめに 取り消したり、戻したり、確認したりなどの知ってたら便利なコマンドをざっと記載します。 git管理addの状態確認 git_command git status ※編集中でaddされてないファイルは赤文字で表示される ※addされているファイルは緑色で表示される ファイルの変更内容を確認 git_command #git addする前の変更分を表示(ワークツリーとステージ)git diff#git add した後の確認(ステージとリポジトリ)#ネットでは git diff –cached のほうがよく出てくるが出力結果は同じでしたgit diff --staged コミットメッセージの複数行 git_command git commit -m "1行目" -m "2行目" コメント、変更履歴を確認 git_command git log 直前のコミットを打ち消すコミット git_command git revert ※git revert HEADと同じで＝一個前(HEAD^)の状態に戻る ※不用意な履歴が増えるのだけが懸念だが、成れないうちはこれが無難 誤pushをとりけしたい git_command git revert↓git push 怖い時は間違ってpushしたのですが、どうしたらいいか。とチームメンバーに相談するのが良さそうです。 https://www-creators.com/archives/2020 ブランチ作成+切り替え git_command git swicth -c ブランチ名#ブランチを新規作成して切り替える ブランチ確認 git_command git branch#ブランチ一覧と緑文字で今いるブランチが表示されるgit branch -a #-a でリモート側も含めたブランチを表示するgit branch ブランチ名#ブランチ名指定でブランチ作成ができる ローカルファイルを編集変更した後に、変更前の最終コミットの状態までローカルのファイルを戻したい git_command git reset --hard HEAD ※ プッシュ前のコミットに対してのみつかわないと履歴が崩れるので危ない らしい ※HEAD^ はひとつ前のコミットまで戻すという意味。二つ前ならHEAD^^となる(~は^と同じ意味) ※HEADなら現在作業中のHEADになる softコミットだけ取り消し mixedコミットとaddを取り消し hardコミット、add、フォルダのファイルも取り消し コミットしていない編集状態を消したり、戻したり Ctrl+ZやCtrl+Shift+Zで直前の状態を消したり、戻したりする感覚で状態を操作できる。 この操作で消したりした内容はメモリに確保される。 例えば、違うブランチで作業してしまい、その内容を戻し、別のブランチのファイルにその内容を反映するみたいなことができる git_command git stash#内容をもとに戻す(消してメモリに確保)git stash pop#消した内容を反映する commitされる前に戻す git_command git restore -s HEAD^ ファイル名 git pullされる前に戻す git_command ##ログ確認git reflog##例）ログの二行目に戻す場合は{1}を指定するgit reset --hard HEAD@{1} git configのスコープ git_command $ git config --local ... # 各リポジトリごとの設定 (.git/config)（優先度:高）$ git config --global ... # 現在のユーザの共通設定 (~/.gitconfig)$ git config --system ... # システム内の共通設定 (/etc/gitconfig など)（優先度:低） さいごに よく使うのだけしか結局覚えれないし、覚えなくてOK

はじめに ブランチ名のつけ方の大きな二つの概念。 GitHub FlowとGit Flowについての概要です。 現場によってバラバラだったり、全くこれと違うこともあると思いますが、ベースとして知っておきたくて残してます。 GitHub Flow 基本的にシンプルなこっちが多いみたいです。 master 本番 feature 新機能追加のブランチ Git Flow 複雑であまり使われないらしく、だいたいGitHub Flowでの運用が主になっていることが多いらしい ※masterが一週間に一回しか更新できない。とか大人の事情がある場合につかわれることが多いらしい master 本番 hotfix 軽い修正。masterの修正でmasterとdevelopmentに最終マージされる release 機能追加改修featureの内容をテストし、masterとdevelopmentにマージされる development masterと同じ状態にしておく検証機 feature 新機能追加のブランチ基本的にdevelopmentから派生しマージされる。 さいごに GitHub Flowにhotfix足して～とかそんな感じでプロジェクトごとのケースが多そうです。

はじめに 仕事中にGitHubを使っていたらCRLFとLFの混在が発覚し、対応したのでメモ代わりに記事にしておきます。 CRLFやLFが混在するとダメな理由。 CRLFはwindows系の改行コード LFはLinux(GitHub推奨)の改行コード となっています。 これが混在することで、バッチなどでShellを使ったりする場合の動作に影響がでたり、Windowsアプリでおかしいことになったりと異なる作業環境で影響が出るそうです。 個人的にVS CODEでプログラムを書いてるだけであれば、今まで大きなことは無かったですが、揃えておいた方が後々のトラブルを防げると思い対応しました。 GitHubの改行コードの変換設定について GitHubにはデフォルトで改行コードを自動で変換する仕組みがあり、基本的には何も起こらないそうですが、変換されないケースも稀にあるようです。 改行コード変換機能「git config --global core.autocrlf」の種類は以下の通り。 true:チェックアウト時に「LF→CRLF」、コミット時に「CRLF→LF」 input:チェックアウト時に「変換しない」、コミット時に「CRLF→LF」 false:チェックアウト時に「変換しない」、コミット時に「変換しない」 何にするかはプロジェクトの方針によって違うと思いますが、個人的にはCRLFへの変換を避けLFに統一という意味で input が無難かなと感じています。 改行コード変換機能の設定を確認するコマンドは↓ git config core.autocrlf inputに変更するコマンドは↓ git config --global core.autocrlf input リポジトリにCRLFとLFが混在した場合の解消方法 修正方法については以下の記事様様でしたので、是非ご確認ください。 本当にありがとうございます。 修正方法についてはこちらの記事にすごく助けられました。感謝します。 https://coding-factory.com/news/methodology/cm139 修正コマンドだけ記載しておきます。 1.フォルダ内でCRLFになっているファイルをコマンドで探す。find . -type f | xargs file | grep CRLF2.CRLFになっているファイルがあれば、LFに変換。find . -type f | xargs file | grep CRLF | awk -F: '{print $1}' | xargs dos2unix3.変換後1のコマンドで再検索し確認※変換後に残存があれば再度2をしたら解消しました さいごに 一応乗り越えれて良かったと思います。 いろんなケースがあると思いますが、今後のために備忘録でした。 コマンドについてはChatGPTに聞いたら、すごく良い解説をしてくれますので、お試しあれ！

はじめに GitHubで動作確認用のブランチを作ったときに、あれ？mainとブランチ切り替えてもローカルのソースの状態が変わらない。ってなったので、ファイルの状態をブランチ切り替えで変更できるようになるタイミングを調べました。 結論 ファイルの状態をブランチ切り替えで変更できるようになるタイミングは・・・ git commit したタイミング です。 ブランチをつくっただけ、git add でインデックスに登録しただけでは、ローカルのソースをブランチ切り替えで変更出来ませんでした。 はっきりわかっておけば安心なので、メモがてら残しておきます。

はじめに Gitでバージョン管理をしている場合に、GitHubにあげたくないファイルがあると思います。 例えばパスワードなどが記載されていたりするファイルなどですね。 その時にGitのバージョン管理から外す＝上げないようにするための方法を記載します。 Gitのバージョン管理から外す方法 .gitignoreという名前のファイルを作成する バージョン管理から除外したいファイルやフォルダがある階層に.gitignoreを置く .gitignoreに除外したいファイルのパスを記載する .gitignoreファイルの記載例 gitignore # #はコメントです。以下は一例なので、そのほかの記載はネットなど見てみてください。 # 指定したファイルを除外 #.gitignoreがおいてある階層のindex.htmlのみが除外される / index.html # 指定したファイルをすべて除外 #.gitignoreがおいてある階層配下でindex.htmlというファイル名を全部除外する index.html #指定したディレクトリをすべて除外 #.gitignoreがおいてある階層配下でdirというフォルダ配下を全部除外する dir / .gitignoreの特徴の一例 .gitignoreは複数のディレクトリに置くことができます 深いフォルダの.gitignoreが優先されます 個人的に上記を踏まえ、ディレクトリごとに簡単な記載で.gitignoreファイルを作成してもよいのかなと思っています。 慣れてきたら、まとめて無駄なく書きたい気持ちはありますが。 以下のサイトが参考になるので、もっと詳しい内容を知りたい場合はぜひ参考にしてみてください。 [Git] .gitignoreの仕様詳解 A collection of .gitignore templates ※公式の .gitignore のテンプレート集です。

はじめに 個人でGit、GitHubを使ったことはあるのですが、現職ではGitが採用されていないためチームでGitを使って開発するときにどういう風に使うかを具体的に知りたくて勉強しました。 今回は実際にGitを使いながら開発を行う際の流れと主に使うコマンドをまとめていきます。 今後自身で使っていく過程で、知識がアップデートされたら内容も更新していくかもしれません。 不備不足あればアドバイスいただけると、とてもうれしいです。 よろしくお願いします😀 開発中のGitコマンドの流れ すでに一度リモートリポジトリから git clone などをおこなっており、ローカルとリモートの同期がとれている前提です。 Gitでバージョン管理を始めるときに最初に行うコマンドについては以下を参照してください。 [【Git/GitHub】Gitでバージョン管理を始めるときに最初にするコマンド](../ 1. 現在の状態を確認し把握する 作業前に以下のコマンドを適宜用いて、状況を確認して作業に入ります。 git branch 今どんなブランチが存在するか確認するコマンドです。 ブランチ名の一覧が表示されたときに * がついている箇所が今いるブランチになります。 #ローカルブランチの一覧を表示git branch #ブランチを新規作成git branch ブランチ名 #ローカルとリモートの全てのブランチを表示git branch -a #リモートブランチの一覧を表示git branch -r ブランチとは 開発者ごとの作業フォルダのようなものです。 おおもとのmasterブランチから 「git branch ブランチ名」 を実行することで作業者専用のブランチを作成し、他の人に影響しない、かつ自分も影響を受けない状態で開発を進めることができます。 修正が完了した場合は、基本的にブランチをリモートリポジトリにpushして、プルリクエストを行い、コードをチェックしてもらった後に、masterブランチへ統合するような流れになります。 git status 変更されているファイルがないかを確認するコマンドです。 変更したけど git add されていない git add したけど git commit されていない gitも認識していない新規ファイルがある などを確認できます。 #現在の変更状況を確認git status #現在の変更状況を短い形式で表示できますgit status -s (見れたらかっこいいので個人的に使いたい笑) 特に何もなければ nothing to commit, working tree clean と表示されます。 ※コミットするものは何もない、作業ツリーはクリーンです。のような意味 git diff ファイルの変更差分を確認するコマンドです。 #git addする前の変更分を表示(ワークツリーとステージ)git diff#ファイル名の指定もできますgit diff ファイル名 #git add した後の確認(ステージとリポジトリ)git diff --staged ※ネットでは git diff –cached のほうがよく出てくるが出力結果は同じでした 用語について ワークツリー：作業中のPCフォルダのこと ステージ： git add した内容が保存される場所 リポジトリ：git commit した内容が保存される場所 git log 変更履歴(git commitしたもの)を表示する commit：コミットID Author：作成者 Date：日時 上記と git commit 時のコミットメッセージなどが表示されます。 上から順に新しいものになります。 #変更履歴を確認git log #1行表示 git log --oneline #ファイルの変更差分を表示git log -p ファイル名 #表示するコミット数を制限する(最近のを見たいときは数値をしぼったりする)git log -n コミット数 2. ブランチを作成し切り替える(作業ブランチに移動する) 作業用のブランチを作成し切り替えます。 1. git branch ブランチを確認するコマンドですが、ブランチを新規作成するときも使います。 #ブランチを新規作成git branch ブランチ名 2. git checkout git branchで今いるブランチが * で表示されます。 自身の作業するブランチにいない場合は切り替えます。 #ブランチ切り替えgit checkout ブランチ名 # 新規作成+切り替えを同時に行うこともできますgit checkout -b 新ブランチ名 git checkout はブランチ切り替え以外にファイルの変更の取り消しもできます。 以下のようなコマンドになります。 #ファイルへの変更を取り消すgit checkout -- ファイル名#ディレクトリへの変更を取り消すgit checkout -- ディレクトリ名#全変更取り消しgit checkout -- . ※- -はブランチ名とファイル名をGitが判別するために記載が必要です。 ※前回git addした内容に戻すというような処理が行われるそうです。 (前回のステージと同じ状態になる=更新前に戻る) 作業用のブランチへの切り替えが完了したら、いよいよローカルフォルダ(自身のPCフォルダ)で作成や編集です🧐 3. ファイルの編集が完了したらGitに記録 作業用のブランチでファイルを編集した後は、Gitに変更を記録します 1. git add ステージといわれる場所に記録したいインデックス(変更内容)を記録します。 ※git commit 前の準備を行うような場所 #全ファイルをステージに追加git add .#ファイル名、ディレクトリ名の指定もできますgit add ファイル名git add ディレクトリ名 なお git add の取り消しはこちらです。 #ステージ(add)を取り消したいgit reset HEAD ファイル名 インデックスの記録で行われることの概要 リポジトリに作業したファイルを暗号化+圧縮化した「ファイル1」が作成され、 ステージに今回の作業ファイルは「ファイル1」だと紐づけたものがインデックスとして保存されます。 2. git commit リモートリポジトリにあげる(git push)前に必要なコマンドです。 git addでステージ作成したインデックスをもとにツリーを作成し、コミットといわれる情報をリポジトリに保存します。 #リポジトリに変更を記録(ツリー、コミット作成)git commit -m "コミットメッセージ" ※コミットメッセージは更新内容を簡潔に短く書きましょう。 ※Windowsのコマンドプロンプトだと日本語が表示できなかったです。 # -m がない場合はテキストエディタかコマンドプロンプト上でメッセージを記載する必要があります。git commit#コミットメッセージを -m で改行したい場合は -m を改行したいポイントで追加します。git commit -m "1行目" -m "2行目" #ファイルの変更内容をcommit実行前に確認できますgit commit -v #直前のコミットを取り消したい、やり直したいgit commit --amend 直前のコミットを取り消し(amend)について Push済みのコミットは戻したらいけません。 Pushした後に誰かがクローンしたら、履歴が違うのでクローンした人があげれなくなるそうです。 そのためPushしたコミットは修正しないほうが良いそうです。 Push後の修正はgit commitでもう一回今の状況をコミットするが正解 です。 コミットに入っている情報 ツリー 作成者 日付 メッセージ add、commitまでしたときにリポジトリがもっているデータ 暗号化+圧縮化されたblobファイルのハッシュID ツリー コミット この三つを「Gitオブジェクト」と言うそうです。 ※確認するコマンドもあります git cat-file -p <オブジェクト名> ハッシュIDとは ヘッダー（ファイル内容の文字数など、ファイルのメタ情報）とファイル内容を、SHA-1というハッシュ関数で40文字の英数字に変換したもの。 ハッシュIDのうち、先頭2文字をディレクトリ名に、残り38文字をファイル名にして保存されています。保存先はローカルの .git/objects という場所です。 4. Gitへの記録が完了したら、リモートリポジトリにアップする いよいよリモートリポジトリにアップします。 ※git push する前も「1. 現在の状態を確認し把握する」で紹介しているコマンドを利用して、状況の確認はしておきましょう。 git push ローカルリポジトリで行った編集内容をリモートリポジトリにアップします。 git add、git commit を行ったものがアップされます。 git push リモート名 ブランチ名 というコマンドになります。 #ブランチ名は自分が作成したブランチ名が主になると思います。git push origin ブランチ名 よく見るpushコマンド「git push origin master」は「originというリモート名のmasterというブランチにpushする。」という意味になります。 チーム開発ではプルリクエストを行い、masterへ統合される流れがおおいので、masterを指定することはあまりないと思います。 リモート名のoriginとは リモート名とは「アクセス先のリモートリポジトリのデフォルトの名前」です。 以下のページのように初回に 「git remote add origin リモートリポジトリのURL​」 でリモートリポジトリのURLをoriginというリモート名で紐づけるのですが、originはGitのデフォルト値のようで一般的にoriginになっていることが多いようです。 【Git/GitHub】Gitでバージョン管理を始めるときに最初にするコマンド なお、リモート名の確認は 「git remote」で確認できます。 これでローカルリポジトリの内容が、リモートリポジトリにアップされました。 GitHubにログインしてWEB上でリモートリポジトリを確認すると、反映されているはずです。 プルリクエストはGitHubにログインしてWEB上で行います。 サクッと手順記載するので、参考になれば幸いです。 プルリクエスト(Pull requests)をする場合 プルリクエストの仕方 GitHubへ移動 Pull requestsをクリック New Pull Requestをクリック compareには自身が作成したブランチを選択する※compareがbaseにとりこまれます。 baseが統合先のブランチでcompareには自身が作成したブランチを選択するケースが多いと思います。 適宜コメント入力+Reviewersで誰にレビュー依頼するかを選択する Create Pull requestをクリック ここまでが、開発中によく使うコマンドや流れになります! 他に作業前の同期や調整時に使うコマンド(git fetchとかpullとか)もありますが、また後日記載していきます

はじめに 個人でGit、GitHubを使ったことはあるのですが、現職ではGitが採用されていないためチームでGitを使って開発するときにどういう風に使うかを具体的に知りたくて勉強しました。 今回はGitでバージョン管理を始めるときに最初にするコマンドをまとめておこうと思います。 ※前提としてGitがインストール済でGitHubアカウントは既に持っている状態 ※200606にolの番号リストで表示していた部分をh3に置き換えました。 それでも微妙だけど、単純に使っていくため致し方なし😐 GitとGitHubとは ざっくりですが、簡単にいうと以下のようなものです。 Git ファイルをバージョン管理する仕組み GitHub Web上でファイルの保管、共有する機能 既存のプロジェクトから作業を始める場合 PCの作業フォルダにコマンドで移動 cd ディレクトリ名 ※Gitコマンドではありません。 Windows/Macの共通のコマンドでフォルダ移動するためのコマンドです​ ローカルリポジトリにリモートリポジトリの内容をコピー(CLONE) git clone リポジトリ名​ ※リポジトリ名はリポジトリのhttps~~.gitのURLでOK リポジトリとは バージョン管理においてファイルやディレクトリを保存する場所のことをリポジトリといいます。 ローカルリポジトリ：作業者のPC内のリポジトリ リモートリポジトリ：Web上のGitHubのリポジトリ 新規プロジェクトから作業を始める場合 PCの作業フォルダにコマンドで移動 cd ディレクトリ名 ※Gitコマンドではありません。 Windows/Macの共通のコマンドでフォルダ移動するためのコマンドです 移動先のフォルダでローカルリポジトリを作成 git init​​ GitHubでリモートリポジトリを新規作成 リモートリポジトリがない場合はWebでGitHubにログインし、リポジトリのページへアクセスし 「New」 をクリックすると作成できます。 リポジトリ新規作成時にReadmeファイルを同時に作成するチェックボックスがあります。 チェックせずに進むとローカルリポジトリに紐づけるために、以降必要なコマンドを表示してくれるので参考にしてみてください。 以降の git remote や git push の流れなどが書いてあります。 originという名前にリモートリポジトリのURLを紐づける git remote add origin リモートリポジトリのURL​ git remote をしなかった場合は、毎回リモートリポジトリのURLを打たないといけなくなります。 またoriginとはGitの慣用句みたいなもので、アクセス先のリモートリポジトリのデフォルトの名前(リモート名)です。 例えば git push origin master というコマンドなら、リモートリポジトリのmasterブランチへpushするという意味になります。 ローカルリポジトリにファイルを作成し、リモートに初回プッシュをしておく git push -u origin master -uについて 今後pushするときに origin master を以後省略できるようにするためのpushコマンドのoptionです。 git pushのデフォルトが origin master なので省略できます。 -uは 初回のみ 使います。 これでGitでバージョン管理を行う準備ができました。 このあとは add commit push など様々なGitコマンドを利用しバージョン管理を行いながら開発をすすめます 今回参考にさせていただいた教材について 教材はUdemyの有料の動画教材です。 Git： もう怖くないGit！チーム開発で必要なGitを完全マスター メンターのPCがMac、テキストエディターがAtomなので環境が違うと少し詰まりますが、個人的には学習を進める上では大きな障害にはなりませんでした。 ※Windowsの場合はファイル操作などの簡単なコマンドを調べる必要はあります。 ※Git利用時にAtomを紐づけてるのですが、私はVS CODEを使っており紐づけがうまくいきませんでした。 ※テキストエディターがなくてもGitコマンドの -m というオプションを使えば問題なく進めます。 内容自体はとてもわかりやすいので、本などから入るよりおすすめ です。 操作しながら学べて、メンターの経験からこうしてるという話もあるので理解がしやすいです。 メンターの山浦清透さんにはとても感謝しております。 ありがとうございます。