Sourcetreeでしている作業 Gitのクローン生成 ブランチ操作(作成、切り替えなど) マージ チェリーピック コミット プッシュ プル Gitの履歴検索 Diffの確認 GitLabではMerge Requestを稀にするくらいでGit操作はほぼSourcetreeでしていた(周囲の環境がそうだったので)。 Visual Studio Code(VSC)でしている作業 テキストエディター コードの１行ごとのGit履歴確認 ノート作成 関わっていたAndroid開発では、エンジンが主にC++だったのでAndroid StudioでやるよりVSCの方が都合が良かったため使い始めたのがきっかけ。 Android StudioもC++ソースをジャンプしたりできる時があるのだが、プロジェクトの環境のせいかできないことがあったがVSCだと問題なくできたのでそのまま使うことにした。 さらにVSCは拡張性が非常に高く、GitLensを用いればカーソルを持っていった行の横にGitの履歴が出せるのが本当に素晴らしい。 関わった案件だと、SVNが主流だった時の名残なのかソースのコメントに残していた。 @override public void onResume() { super.onResume(); //ADD 2021.04.29 K.Namae ○○案件 ~~~~のための実装 START --> sample(); //ADD 2021.04.29 K.Namae ○○案件 ~~~~のための実装 END <-- } //~中略~ //ADD 2021.04.29 K.Namae ○○案件 ~~~~のための実装 START --> private void sample() { //何か } //ADD 2021.04.29 K.Namae ○○案件 ~~~~のための実装 END <-- みたいな感じ。いつ何のために追加、修正、削除したのかがわかるのでいいが、当然その分ソース量が増えて読みづらくなることもあった。それが読みやすいまま同じことができるGitLensさえあれば事足りることがわかった。 他の拡張機能でVSNotesというのもあり、VSC内でメモ用にファイルを作成できる。ただメモをとるだけならメモだけ独立したものでもいいが、ソースをVSCで見ながらメモをとりたい時には非常に役に立つ。これを使う前は別途テキストエディターを開いて作成していた。もちろんVSC内でそのまま(macだと)File > New Fileでファイル作成はできるのだが閲覧も含めてこっちの方が個人的には使いやすい。さらにVSNotesの設定をすれば、新規作成時にテンプレを設定することができるため、案件のメモ時は必ずそれを用いている。 今回の目的 Visual Studio CodeでSourcetreeの作業を全て実現できたら、１つの統合できるのでいいじゃん！という考え。そのためにはSoucetreeでやっていた作業をVSCでできる？という確認をする必要があった。この記事はSourtreeからVSCに移行したい人向けなので、Sourcetreeの各手順は省略する。以下からはVSCの手順について確認。 Gitのクローン生成 いつも通りGitリポジトリのURLを設定するとGitLabからクローンも問題なくできました。 リポジトリ一覧は見れるのか Sourcetreeだと以下のようにクローンしたリポジトリが一覧で確認できる 調べた限りではVSCでは同じことをする方法が不明。実際一覧で見れなくてもクローンしたプロジェクトをまとめるフォルダさえ用意しておけば問題ない。 ブランチ操作 クローンしたら最初はmasterなのでほとんどの案件でブランチを開発用に切り替えるはず。画面下部に現在のブランチ名が表示されるので、ブランチ名をクリックするとブランチ一覧が表示されるのでそこからブランチ切り替えができる もしくはSource Control > BRANCHESからも切り替えや、ブランチ一覧が確認できる。こっちで表示されるブランチを右クリックで選択すると「Delete Branch」でブランチを削除できる。ここで表示されるブランチはローカルにチェックアウトしたものらしいので、リモート(オリジナル)のブランチを削除したい場合はSource Control > REMOTESがあるのでそっちで削除をすること。 コミット&プッシュ Source Control > SOURCE CONTROLにソースの変更点が表示される。変更されているファイルを選択し右クリック > Stage Changes　もしくはファイル名の右側にある「+」ボタンを押すとコミットするファイルがStage Changedに移動する。もしそのファイルを除きたいなら右クリック > Unstage Changesもしくは「-」ボタンを押す。 右クリックしたときにStash Changesを選択するとスタッシュができる。スタッシュ内容はSource Control > STASHESで確認することができ、スタッシュを適用するには右クリック > Apply Stash > Apply Stash(Pop Stashは適用したら削除する場合)。スタッシュの削除は右クリック > Delete StashとここもSourcetreeと変わらない感覚で使える。 コミットはStage Changedに移動したら上のMessageを入力してチェックマークをクリックするとOK。Source Control > BRANCHES でコミットしたブランチが色がついており、開くとChanges to push to...とあり、↑ボタン押すとプッシュできる。ブランチのコミット状態を戻すとかもSoucetree同様なので省略。 プルはしたことがないが、おそらく同じBRANCHESにプルボタンが出るはず(残課題)。 Gitの履歴 Source Control > BRANCHES でも確認できるが、拡張機能のGit Graphを使った方が見やすくておすすめ。インストールしたら、Souce Control > SOURCE CONTROL >View Git Graphを押すとGit履歴が一覧で見ることができる。 Git Graphを表示している画面で、検索(右上の虫眼鏡 or macならcmd+f)を使用するとGit履歴をキーワードでも検索できるしハッシュ番号(SHA-1)でヒットさせることもできる。 Diffの確認 Source Control > SOURCE CONTROLで一面で確認ができるし、Sourcetreeのように他のDiff見る用のソフトを立ち上げる必要がないのが良い。差分がある行で右クリック > Revert Selected RangeでSourcetreeでいう「選択した行を破棄」ができる。Gitリポジトリの変更点の確認だけでなく、指定したファイル同士を比較して差分を確認することもできたりとなんでもできる気がする。 結論 Sourctreeユーザーで、もしVisual Studio Codeで全てやりたい！という場合は問題なさそう。むしろ拡張できるおかげでできることが増える気がする。他に便利な使い方や拡張機能があったら追記していく予定。最後にどうでもいいのだが、やはりSourcetreeのスペリングはSoucetreeであって"SouceTree"ではない気がする。 環境 Mac OS11.3(Big Sur) Visual Studio Code ver1.55.2 Sourcetree ver4.1.1

コードレビューがあったのでコードレビューを書いていましたが、間違えて出してしまったのでもう一度描き直そうとするとmergeしてしまった。 これわいけないと思い再度コミットしてプッシュしましたが、revertしてくださいと怒られました。 で、わからないのでここで備忘録とします。 １、間違った最後のところまで戻ります。 今回はmergeまで ２、masterで次に間違った箇所を右クリックして「Revert Changes in Commit」まで戻す ここで新しく記入したことをなかったこととします。 ３。プッシュします。 ４、新しくレビューしてもらうbrabchをきる ５、新しくきったBranchで右クリックして「Revert Changes in Commit」まで戻す なかったことにしたコードを再度復活させます。 ５.これでプシュして、コードレビューを出します。

超絶初心者です。 masterからmainへ変更する際のエラー git initコマンドを実行後、git branch -M mainを行うとエラー。 /work/project$ git init /work/project$ git branch -M main error: refname refs/heads/master not found fatal: Branch rename failed REDEME.mdファイルを作成後、addとcommitを行った後に再度実行すると成功。 /work/project$ echo "# project" >> README.md /work/project$ git add README.md /work/project$ git commit -m "first commit" /work/project$ git branch -M main 成功後に確認すると、refs/heads/にmainファイルが作成されていた。 失敗した段階ではrefs/heads/にはmasterファイルがなかった。 恐らく、addまたはcommitを実行した際にmasterファイルが作成され、そのためmasterからmainへのbranch名の書き換えが成功したっぽい。

1.今回の状況 作業ブランチ上で、GitHubのリモートリポジトリへプッシュした後に、コミットメッセージの誤りに気づきました。 デフォルトのブランチへはまだマージを行っていない状況です。 2.使用環境 mac.os バージョン10.15.6 Ruby 2.6.6 Rails 6.1.3.1 psql (PostgreSQL) 12.6 3.早速やってみる 今回はこちらのサイトを参考にやってみました。 参考：Gitのコミットメッセージを後から修正変更する方法！ ①修正するコミットメッセージを確認 まず修正したいコミットが何番目なのか確認します。 GitHub上では下が古く、上に向かって新しいコミットメッセージが並びます。 今回は上から2つ目の「挨拶を英語おに変更う」を修正します。 # git rebase -i コマンドを実行して修正するコミットを選択 # HEAD~nをつけることで該当コマンドが最上位に来る(今回はn=2) test_commit_mistake % git rebase -i HEAD~2 参考1: 【Git】rebaseコマンドの理解 参考2: 6. rebase -i でコミットを修正する ②該当のコミットメッセージのeditに変更 テキストエディタが起動するのでpickをeditに変更して、保存してテキストエディタを閉じます。 すると、ターミナル上で Stopped at b16ad30... 挨拶を英語おに変更う You can amend the commit now, with git commit --amend Once you are satisfied with your changes, run git rebase --continue と表示されます。この順に従って進めていきます。 ③コミットメッセージを修正 今回は「挨拶を英語おに変更う」を「挨拶を英語に変更」に修正します。 # git commit --amend -m コマンドを実行して修正する # -mをつけることでテキストエディタを開かずに修正できる test_commit_mistake % git commit --amend -m "挨拶を英語に変更" [detached HEAD 95cfc4b] 挨拶を英語に変更 Date: Thu Apr 29 08:51:45 2021 +0900 1 file changed, 2 insertions(+), 2 deletions(-) 参考:7.6 Git のさまざまなツール - 歴史の書き換え ④修正を完了させる git rebase --continueで完了です。 # rebaseを続行し、完了させる test_commit_mistake % git rebase --continue Successfully rebased and updated refs/heads/feature/introduce. 参考：git rebase についてまとめてみた 再度コミットメッセージを確認すると、修正ができていることが分かります。 test_commit_mistake % git log --oneline 02f1d4a (HEAD -> feature/introduce) やり取りを追加 95cfc4b 挨拶を英語に変更 #今回修正箇所 7712b62 挨拶を追加 7ae483a init ⑤GitHubに再プッシュ ローカルブランチでの修正が終わったので、リモートブランチに修正を反映させます。 今回は既にプッシュを行っているため、 git push　--originのコマンドを使用するとプッシュに失敗します。 # 作業ブランチにいることを確認後 test_commit_mistake % git push origin HEAD To https://github.com/hogehoge/test_commit_mistake.git ! [rejected] HEAD -> feature/introduce (non-fast-forward) error: failed to push some refs to 'https://github.com/hogehoge/test_commit_mistake.git' hint: Updates were rejected because the tip of your current branch is behind hint: its remote counterpart. Integrate the remote changes (e.g. hint: 'git pull ...') before pushing again. hint: See the 'Note about fast-forwards' in 'git push --help' for details. 今回は競合箇所がないか確認した後に --forceオプションをつけて強制的にプッシュを行います。 ※リモートブランチが強制的にローカルブランチの内容で上書きされてしまうので共同開発等、複数人で使用する際は要注意 test_commit_mistake % git push --force origin HEAD Enumerating objects: 8, done. Counting objects: 100% (8/8), done. Delta compression using up to 8 threads Compressing objects: 100% (3/3), done. Writing objects: 100% (6/6), 633 bytes | 633.00 KiB/s, done. Total 6 (delta 0), reused 0 (delta 0), pack-reused 0 To https://github.com/hogehoge/test_commit_mistake.git + 6f5ca4a...02f1d4a HEAD -> feature/introduce (forced update) GitHub上でもコミットメッセージが修正できていることが確認できました。 4.まとめ コミットメッセージを含め、不具合がないか等確認してから行う。 --forceは強制的にプッシュできるためなるべく使用しないよう気をつける。 5.最後に 記事の感想や意見、ご指摘等あれば伝えていただけるとありがたいです。 読んでいただき、ありがとうございました。

1.今回の状況 作業ブランチ上でリモートリポジトリへプッシュした後に、コミットメッセージの誤りに気づきました。 デフォルトのブランチへはまだマージを行っていない状況です。 2.使用環境 mac.os バージョン10.15.6 Ruby 2.6.6 Rails 6.1.3.1 psql (PostgreSQL) 12.6 3.早速やってみる 今回はこちらのサイトを参考にやってみました。 参考：Gitのコミットメッセージを後から修正変更する方法！ ①修正するコミットメッセージを確認 まず修正したいコミットが何番目なのか確認します。 GitHub上では下が古く、上に向かって新しいコミットメッセージが並びます。 今回は上から2つ目の「挨拶を英語おに変更う」を修正します。 # git rebase -i コマンドを実行して修正するコミットを選択 # HEAD~nをつけることで該当コマンドが最上位に来る(今回はn=2) test_commit_mistake % git rebase -i HEAD~2 参考1: 【Git】rebaseコマンドの理解 参考2: 6. rebase -i でコミットを修正する ②該当のコミットメッセージのeditに変更 テキストエディタが起動するのでpickをeditに変更して、保存してテキストエディタを閉じます。 すると、ターミナル上で Stopped at b16ad30... 挨拶を英語おに変更う You can amend the commit now, with git commit --amend Once you are satisfied with your changes, run git rebase --continue と表示されます。この順に従って進めていきます。 ③コミットメッセージを修正 今回は「挨拶を英語おに変更う」を「挨拶を英語に変更」に修正します。 # git commit --amend -m コマンドを実行して修正する # -mをつけることでテキストエディタを開かずに修正できる test_commit_mistake % git commit --amend -m "挨拶を英語に変更" [detached HEAD 95cfc4b] 挨拶を英語に変更 Date: Thu Apr 29 08:51:45 2021 +0900 1 file changed, 2 insertions(+), 2 deletions(-) 参考:7.6 Git のさまざまなツール - 歴史の書き換え ④修正を完了させる git rebase --continueで完了です。 # rebaseを続行し、完了させる test_commit_mistake % git rebase --continue Successfully rebased and updated refs/heads/feature/introduce. 参考：git rebase についてまとめてみた 再度コミットメッセージを確認すると、修正ができていることが分かります。 test_commit_mistake % git log --oneline 02f1d4a (HEAD -> feature/introduce) やり取りを追加 95cfc4b 挨拶を英語に変更 #今回修正箇所 7712b62 挨拶を追加 7ae483a init ⑤GitHubに再プッシュ ローカルブランチでの修正が終わったので、リモートブランチに修正を反映させます。 今回は既にプッシュを行っているため、 git push　--originのコマンドを使用するとプッシュに失敗します。 # 作業ブランチにいることを確認後 test_commit_mistake % git push origin HEAD To https://github.com/hogehoge/test_commit_mistake.git ! [rejected] HEAD -> feature/introduce (non-fast-forward) error: failed to push some refs to 'https://github.com/hogehoge/test_commit_mistake.git' hint: Updates were rejected because the tip of your current branch is behind hint: its remote counterpart. Integrate the remote changes (e.g. hint: 'git pull ...') before pushing again. hint: See the 'Note about fast-forwards' in 'git push --help' for details. 今回は競合箇所がないか確認した後に --forceオプションをつけて強制的にプッシュを行います。 ※リモートブランチが強制的にローカルブランチの内容で上書きされてしまうので共同開発等、複数人で使用する際は要注意 test_commit_mistake % git push --force origin HEAD Enumerating objects: 8, done. Counting objects: 100% (8/8), done. Delta compression using up to 8 threads Compressing objects: 100% (3/3), done. Writing objects: 100% (6/6), 633 bytes | 633.00 KiB/s, done. Total 6 (delta 0), reused 0 (delta 0), pack-reused 0 To https://github.com/hogehoge/test_commit_mistake.git + 6f5ca4a...02f1d4a HEAD -> feature/introduce (forced update) GitHub上でもコミットメッセージが修正できていることが確認できました。 4.まとめ コミットメッセージを含め、不具合がないか等確認してから行う。 --forceは強制的にプッシュできるためなるべく使用しないよう気をつける。 5.最後に 記事の感想や意見、ご指摘等あれば伝えていただけるとありがたいです。 読んでいただき、ありがとうございました。

Linuxの基本コマンド一覧表 自身の備忘録の為に、Linuxコマンドの一覧表を作成しておきます。 環境：Git CMD 現在のパスを表示 pwd ファイルのテキストを記載する echo "記載内容" > ファイル名 //GitHubの設定 //メールが登録されているか確認する $git config --global user.email //Githubにメールアドレスを追加する $git config --global user.email "email@excample.com" //ローカルリポジトリを作成するためのコマンド $ git init Initialized empty Git repository in /Desktop/works/.git/ //指定したディレクトリにローカルリポジトリを作成 $ git init Desktop/works //ディレクトリやインデックスの状態を確認するコマンド(ファイルがどのエリアに存在するのかを確認する。) $ git status //git status下記内容が表示される場合 // On branch master No commits yet nothing to commit (create/copy files and use "git add" to track) //GitHubにあるリポジトリをリモートリポジトリとして設定 $ git remote add origin https://github.com/M(自分のアカウント名)/（自分のプロジェクト名） //コミットログの確認 $ git log //リモートリポジトリをローカル(自分のPC)へクローンする $ git clone https://github.com/masaki/example.git //ファイルをステージングエリアに登録する $ git add //gitディレクトリに登録する $git commit //変更した内容を他のリポジトリに反映させる(2020/10以前はmain ⇒ master)。 $git push origin main //ブランチ名を確認 $git branch

はじめに 自分の作業量の指標として、Gitの差分の行数の合計を取得できればと考えた。 結果から git log --merges --since=YYYY-MM-DD --until=YYYY-MM-DD --pretty=format:"%h+%an+%s" | \ awk -F "+" '{if(match($3,"Merge pull request")){print $0}}' |\ awk -F "+" 'BEGIN{hit=0} {if(hit){"git diff --numstat " $1 " " hit"|tr '"'\n' ','"'" | \ getline l;print l;};if(match($2,"ユーザーネーム")){hit=$1}else{hit=0};}' |\ tr ',' '\n'|\ awk 'NF==3 {plus+=$1; minus+=$2} END {printf("%d (+%d, -%d)\n", plus+minus, plus, minus)}' --since=YYYY-MM-DDと--until=YYYY-MM-DDは取得したい期間を入力する。 ユーザーネームの箇所にはGitのユーザー名を入力する。 出力 26846 (+24532, -2314) 期間中に自分がPull Requestを投げてマージされたマージコミットの差分の合計を出力する。 過程 まずはコミットごとの差分行数をログで取得する --numstatオプションを指定すると差分行数を取得できる。 git log --numstat 出力例 commit 72e9433b7e626889180a7b32b734e1c1c85571d1 Author: UserName <username@.me> Date: Wed Apr 28 19:33:57 2021 +0900 コミットメッセージ 2 1 www/application/file_path.txt 3 2 www/application/src/file_path.txt commit af1bb90938cca26b1863e079c00bc4b5d5a1771e Author: UserName <username@.me> Date: Wed Apr 28 19:07:14 2021 +0900 コミットメッセージ１ 138935 206 www/application/file_path.txt 29 0 www/application/src/file_path.txt : コミットメッセージの下にファイルごとの差分行数が追加行、削除行、ファイル名の順番で出力される。 コミットごとの差分行数の合計を取得する awkを使って、先ほどのログ出力の値の合計を取得する。 git log --numstat --author='ユーザー名' --since=YYYY-MM-DD --until=YYYY-MM-DD --no-merges | \ awk 'NF==3 {plus+=$1; minus+=$2} END {printf("%d (+%d, -%d)\n", plus+minus, plus, minus)}' 出力 445568 (+303454, -142114) awkコマンドは渡したテキストを１行ごとに処理できる。処理の内容は以下になる。 NF===3 １行を空白で区切った時に３列だった場合に次の処理をする。 {plus+=$1; minus+=$2} １列目の値を変数plusに加算。２列目の値を変数minusに加算。 END {printf("%d (+%d, -%d)\n", plus+minus, plus, minus)} すべての行の処理を完了した後に合計をprintf関数で出力。 上記の結果だけでも十分に作業量の目安とできるが、 コミットごとの差分だと、プルリクエストが通るまでの修正回数が増えコミットする度に差分が増えてしまい、 最終的にマージしたコードの更新行数のみを把握できない。 親ブランチへのマージコミットの差分だけを取得する 通常のコミットは無視してプルリクのマージコミットの差分行数をgit diffコマンドを使って取得したい。 まずは2つのバージョン間の差分行数を取得する 一つのバージョン間の差分行数を取得するにはdiffコマンドに--numstatオプションを指定する git diff --numstat v1 v2 出力されるデータは以下のようになる。 44 111 www/application/file_path.txt 17 21 www/application/src/file_path.txt 49 139 www/application/public/file_path.txt 7 11 www/application/public/file_path2.txt 先ほどと同様に出力された結果をawkコマンドに渡して合計を求めることができる。 git diff --numstat v1 v2 | \ awk 'NF==3 {plus+=$1; minus+=$2} END {printf("%d (+%d, -%d)\n", plus+minus, plus, minus)}' プルリクでマージされたコミットを探す 自分がプルリクでマージしたコミットとその一つ前でマージされたコミットの差分を取得すれば、自分が作業した分の差分を取得できる。 なので、まずはプルリクでマージされたコミットの一覧を取得する。 git log --merges --pretty=format:"%h+%an+%s" | \ awk -F "+" '{if(match($3,"Merge pull request")){print $0}}' 処理の内容は以下になる。 git log --merges --pretty=format:"%h+%an+%s" --pretty=format:でログ出力の内容を指定できる。 %hコミットの省略したハッシュ %an ユーザー名 %s コミットメッセージ ログの以下のような出力は以下のようになる。 1f8c9eda+UserName+Merge pull request #1 from RelicInc/feature/CCF-29 awk -F "+" '{if(match($3,"Merge pull request")){print $0}}' この結果からawkコマンドでコミットメッセージにMerge pull requestの文言が含まれているログだけを抽出する。 列を+で区切ることでユーザー名に空白が含まれても処理できるようにしている。 自分がプルリクしてマージされたコミットから差分行数を取得する git log --merges --since=YYYY-MM-DD --until=YYYY-MM-DD --pretty=format:"%h+%an+%s" | \ awk -F "+" '{if(match($3,"Merge pull request")){print $0}}' |\ awk -F "+" 'BEGIN{hit=0} {if(hit){"git diff --numstat " $1 " " hit"|tr '"'\n' ','"'" | \ getline l;print l;};if(match($2,"ユーザーネーム")){hit=$1}else{hit=0};}' |\ tr ',' '\n'|\ awk 'NF==3 {plus+=$1; minus+=$2} END {printf("%d (+%d, -%d)\n", plus+minus, plus, minus)}' 先ほど取得したプルリクエストのマージコミットの一覧をまたまたawkコマンドに渡す。 1. if(match($2,"ユーザーネーム")){hit=$1}else{hit=0};}' もし、自分のコミットであればhit変数にコミットのハッシュ値を格納する。 if(hit){"git diff --numstat " $1 " " hit"|tr '"'\n' ','"'" | getline l;print l;}; クォーテーションが入れ子になっていて分かりにくいが下記と同様の処理。 if(hit){"git diff --numstat v1 v2 |tr '\n' ',' " | getline l;print l;}; もし、前の行の処理でhitにハッシュ値が格納されていれば、前の行のコミットとこの行のコミットを差分をgit diffで出力する。 getlineという機能を使って"git diff" | getline var;のようにダブルクォーテーションで囲んだコマンドをawk内で実行して変数に格納することができる。 しかし、コマンドの実行結果が複数行の場合は最初の１行しか変数に格納されないので trコマンドを使って改行を,に変更して１行にしている。 tr ',' '\n' 1行にまとめれた複数のgit diffの結果を複数行に戻してawkに渡す awk 'NF==3 {plus+=$1; minus+=$2} END {printf("%d (+%d, -%d)\n", plus+minus, plus, minus)}' 最後に結果の合計を求めて出力する。 おわり はじめてコマンドで動くスクリプトを書いてみたがawkコマンドが便利すぎて多用してしまった。 もっとスマートな書き方も模索していきたい。 参考 https://koyamay.hatenablog.com/entry/2014/10/06/022654 https://maku77.github.io/git/stats/count-changes.html https://www.tweeeety.blog/entry/2015/01/22/171530 https://webkaru.net/dev/bash-loop-for-while/ https://qiita.com/b4b4r07/items/e56a8e3471fb45df2f59 https://qiita.com/simarei/items/f4809314399562309e4b https://qiita.com/hnishi/items/4ee60ed515470e796f41 http://www.openspc2.org/reibun/bash/variable/002/index.html https://qiita.com/yuta-38/items/6950f5bc7a3e696f21a3 https://it-ojisan.tokyo/awk-f/ https://it-ojisan.tokyo/awk-match/ https://orebibou.com/ja/home/201707/20170723_001/ http://www.kt.rim.or.jp/~kbk/gawk-30/gawk_17.html https://blog.toshimaru.net/join-lines-command/ https://www.excellence-blog.com/2017/01/12/awk%E3%81%A7%E8%A4%87%E6%95%B0%E8%A1%8C%E5%87%A6%E7%90%86%E3%82%92%E8%A1%8C%E3%81%86/

初期設定を行う //ユーザー名の登録 $ git config --global user.name "XXXX" //メールアドレスの登録 $ git config --global user.email "XXXX@hogehoge.com" ローカルにリポジトリを作成し、リモートにプッシュする アップロードしたいフォルダの場所 フォルダ名を入力するか、ファイルをドラッグ＆ドロップする。 cd [フォルダ名] Gitのリポジトリを新たに作成する 既にあるリポジトリを再初期化するためのものでもある。 $ git init ファイルを追加 [.]は全てのファイルを追加 指定したファイルを追加したい時は $ git add <ファイル名>で指定する。 $ git add . ファイルの変更や追加をコミット $ git commit -m "任意のメッセージ" $ git commit -m "first commit" ローカルの変更を確認する $ git status originという名前に対して[URL]を関連付けさせる。 $ git remote add origin [URL] （githubにアップする場合はgithubのリモートリポジトリのURLを指定) $ git remote add origin https://github.com/XXXX/XXXXXX.git masterを更新,追加 リモートリポジトリにアップロード（プッシュ） $ git push -u origin master

はじめに チーム開発でgitを利用するためによく使うコマンドを簡単な手順書として残しておきます。 Gitがリモートリポジトリにアップロードするまで # すべての変更を含むワークツリーの内容をインデックスに追加 $ git add -A # インデックスに追加されたファイルをコメントを付けてコミットする $ git commit -am "アプリ初期化" <- コメントを入力 #リモートリポジトリの変更を、現在のブランチに取り込む(fetch + merge) $ git pull #リモートリポジトリに変更を書き込む $ git push or $ git push origin Gitの構造 Gitは以下の順番でアップロードされている ワーキングツリー -> インデックス -> ローカルリポジトリ -> リモートリポジトリ ワーキングツリー : 作業場所 インデックス : コミットする変更を準備する場所 ローカルリポジトリ : 変更履歴を記録(ローカル環境) リモートリポジトリ : 変更履歴を記録(共有できる) またgitのコマンドは下記のようにアップロードしていく git add : 「ワーキングツリー → インデックス」 git commit : 「インデックス → ローカルリポジトリ」 git push : 「ローカルリポジトリ → リモートリポジトリ」 ※インデックスがワークツリーとリポジトリの間にある理由 理由は、以下の2つ ワーキングツリー内の必要ないファイルを含めずにコミットを行える。 ファイルの一部の変更だけをインデックスに登録してコミットが可能