PCセットアップの練習のため、一度PCを初期化しました。 ソース管理はGitHubで行っておりました。 PC初期化に伴い、リモートリポジトリはGitHub上にあるもののソースコードを編集するのに必要なローカルリポジトリがPC上に存在していない状態になってしまっています。 そこで、GitHub上にあるリモートリポジトリからローカルリポジトリをクローンする一連の流れを試したので、記事にまとめてみました。 自身が業務をする上での備忘録として活用することを目的としています。 初心者がまとめた記事なので、間違った認識をしている可能性があります。 間違い等がございましたら、ご指摘いただけると幸いです。 そもそもGitとは？ エンジニアがソース管理をするサービスの中の1つです。 ソース管理するサービスはいくつもありますが、GitHubやGitLabがメジャーのようです。 どうやってソース管理をするの？ Git上でプロジェクトを作って管理をします。 また、このプロジェクトのことをリポジトリといいます。 リポジトリにはリモートリポジトリとローカルリポジトリの2種類があります。 リモートリポジトリ・ローカルリポジトリとは？ GitHubやGitLab上で作ったリポジトリのことをリモートリポジトリといいます。 リモートリポジトリがあるだけでは作業はできません。 リモートのバージョンをコピーしたものをローカルに持って行かないと作業ができないのです。 このリモートからローカルにコピーすることをクローンと呼びます。 ローカルリポジトリを作る方法 今回は既にGitHubやGitLab上でリモートリポジトリが作成されていることを前提としています。 クローンする クローンする際に使用するURLはGitHub上のリモートリポジトリ内にある画面右側にある緑色のボタン「Clone or download」をクリックするとURLがコピーできます。 一連のコマンドは下記の通りです。 クローンする git clone (URL) クローンしたリポジトリを編集してプッシュする方法 次にクローンしたリポジトリのファイルを編集したり、新しいファイルを追加したあとにリモートリポジトリにプッシュするまでの一連の流れをまとめました。 ステータスを確認 インデックスに追加 コミットする プッシュする ステータスを確認 git status インデックスに追加 git add . ステータスを確認 git status コミットする git commit -m '(メッセージ)' プッシュする git push origin master 実際の画面で見てみよう 1.クローンする GitHubにログインし、事前に作成しておいたリモートリポジトリ内にあるURLをコピーします。 ローカルリポジトリを作成したいフォルダ内でGit Bash Hereを開きます。 git clone (URL) とコマンドを入力します。 Enter すると、.gitといったフォルダが作成されます。 この.gitフォルダには、Gitの情報が保管されているので削除してはいけません。 2.カレントディレクトリを移動 Git Bushのカレントディレクトリをクローンしたリポジトリに移動させます。 2.5ファイルを編集 Git Bush上では特に操作はしません。 エディタなどでファイルの編集を行います。 3.ステータスを確認 クローン出来たか確認するため、ステータスを確認します。 git status とコマンドを入力し、上の画像のように赤字でフォルダ名が表示された場合は変更がある状態です。 4.インデックスに追加する フォルダ名が赤字で表示されたら git add . または git add (フォルダ名) とコマンドを入力します。 コマンド git add . を入力した場合は、変更のあるすべてのファイルがインデックスに追加されます。 5.ステータスを確認する もう一度、 git status とコマンド入力し、赤字が緑字になっていれば正常にインデックスに追加された状態です。 緑字になったファイルがコミット対象となるファイルです。 6.コミットする git commit -m '(メッセージ)' とコマンドを入力すればコミット完了です。 7.プッシュする コマンド git push origin master を入力したらプッシュ完了です。 きちんとプッシュまで終わっているかはGitHubで確認しておきましょう。 GitHubの該当リポジトリに入り、「commits」をクリックするとプッシュされているか確認ができます。 まとめ 流れさえ分かってしまえばどういってことない作業でした。 コマンドもそこまで複雑なものではないので、慣れれば覚えてしまえると思います。 今回はブランチという概念を無視した流れをまとめています。 本来はマスターに直でプッシュすることを禁止している場合があります。 ブランチを使ったプッシュ方法に関しては、別の記事にまとめようと思います。
PCセットアップの練習のため、一度PCを初期化しました。 ソース管理はGitHubで行っておりました。
PC初期化に伴い、リモートリポジトリはGitHub上にあるもののソースコードを編集するのに必要なローカルリポジトリがPC上に存在していない状態になってしまっています。
そこで、GitHub上にあるリモートリポジトリからローカルリポジトリをクローンする一連の流れを試したので、記事にまとめてみました。
自身が業務をする上での備忘録として活用することを目的としています。 初心者がまとめた記事なので、間違った認識をしている可能性があります。 間違い等がございましたら、ご指摘いただけると幸いです。
エンジニアがソース管理をするサービスの中の1つです。 ソース管理するサービスはいくつもありますが、GitHubやGitLabがメジャーのようです。
Git上でプロジェクトを作って管理をします。 また、このプロジェクトのことをリポジトリといいます。
リポジトリにはリモートリポジトリとローカルリポジトリの2種類があります。
GitHubやGitLab上で作ったリポジトリのことをリモートリポジトリといいます。 リモートリポジトリがあるだけでは作業はできません。 リモートのバージョンをコピーしたものをローカルに持って行かないと作業ができないのです。
このリモートからローカルにコピーすることをクローンと呼びます。
今回は既にGitHubやGitLab上でリモートリポジトリが作成されていることを前提としています。
クローンする際に使用するURLはGitHub上のリモートリポジトリ内にある画面右側にある緑色のボタン「Clone or download」をクリックするとURLがコピーできます。
一連のコマンドは下記の通りです。
git clone (URL)
次にクローンしたリポジトリのファイルを編集したり、新しいファイルを追加したあとにリモートリポジトリにプッシュするまでの一連の流れをまとめました。
git status
git add .
git commit -m '(メッセージ)'
git push origin master
GitHubにログインし、事前に作成しておいたリモートリポジトリ内にあるURLをコピーします。 ローカルリポジトリを作成したいフォルダ内でGit Bash Hereを開きます。 git clone (URL) とコマンドを入力します。 Enter すると、.gitといったフォルダが作成されます。 この.gitフォルダには、Gitの情報が保管されているので削除してはいけません。
Enter
Git Bushのカレントディレクトリをクローンしたリポジトリに移動させます。
Git Bush上では特に操作はしません。 エディタなどでファイルの編集を行います。
クローン出来たか確認するため、ステータスを確認します。 git status とコマンドを入力し、上の画像のように赤字でフォルダ名が表示された場合は変更がある状態です。
フォルダ名が赤字で表示されたら git add . または git add (フォルダ名) とコマンドを入力します。 コマンド git add . を入力した場合は、変更のあるすべてのファイルがインデックスに追加されます。
git add (フォルダ名)
もう一度、 git status とコマンド入力し、赤字が緑字になっていれば正常にインデックスに追加された状態です。 緑字になったファイルがコミット対象となるファイルです。
git commit -m '(メッセージ)' とコマンドを入力すればコミット完了です。
コマンド git push origin master を入力したらプッシュ完了です。 きちんとプッシュまで終わっているかはGitHubで確認しておきましょう。 GitHubの該当リポジトリに入り、「commits」をクリックするとプッシュされているか確認ができます。
流れさえ分かってしまえばどういってことない作業でした。 コマンドもそこまで複雑なものではないので、慣れれば覚えてしまえると思います。
今回はブランチという概念を無視した流れをまとめています。 本来はマスターに直でプッシュすることを禁止している場合があります。 ブランチを使ったプッシュ方法に関しては、別の記事にまとめようと思います。
どうも、客先常駐エンジニアのCLBです。 現在こんな環境で仕事をしています。 職場：SVN 家：Github(Git) これをやってると、「こんな理由でGitの方がいい！」と感じてきたので書いてみます。 コミットしてもコンフリクトが起こらない SVNで同じファイルを2人以上で触っていると、こんなことが起こります。 Aさん「作業出来た！コミット！」 SVN「Bさんの作業とコンフリクトしてます。」 Aさん「しゃーない。コンフリクト解消するか。」 SVN「解消を確認しました。コミットします。」 Aさん「作業出来た！コミット！」 SVN「Bさんの作業とコンフリクトしてます。」 Aさん「またかよ・・・」 「そうならないようにルールを決めるんだよ！」と言われましたが、 そのルールは大抵の場合、以下のような形になります。 SVNでロックを掛け、他の人が触れないようにする。その間、他の人の作業は中断される。 コミットをなるべくしないようにする。ちょっと前のものに戻す事はあきらめる。 Gitの場合、リモートからクローン（SVNで言うチェックアウト）すると、 リポジトリが個々のローカル環境に作成されます。 コミットもそのローカルリポジトリに行われるので、この時点ではコンフリクトは起こりません。 「待って、それじゃあローカルからリモートに移すにはどうすればいいんじゃ」 と声が聞こえてきます。Gitではこの操作をプッシュと呼びます。 SVNではコミット＝リモートリポジトリへ反映ですが、 Gitのコミットではリモートリポジトリへは反映されません。 反映はプッシュ操作を行う事で初めてリモートリポジトリへ資産が移送される仕組みです。 この時、リモートリポジトリで何らかの変更があった場合はコンフリクトが発生します。 しかしSVNの時と比べ連続してコンフリクトを解消する手間が省け、 しかもコミットを積極的に行う事が出来るようになるのです。 他の人の作業が中断されたりすることもありません。 柔軟にコミットを管理することが出来る 前の項目でも述べた通り、コミットもそのローカルリポジトリに行われるので、 コミットを後から修正したり出来ます。 特に強力なのがsquash機能です。 これは複数のコミットをまとめる事ができる機能で、 これを利用する事によりコミットログを綺麗にする事が出来ます。 SVNでは"たとえ細かい修正コミットでも無かった事にしてはいけない。" というスタンスなので、このような事は出来ません。(シュタゲかな？) 先進的なツールと連携出来る。 ※これは、私が知る範囲での話です。 問題等があれば遠慮無くコメントをお願いいたします。 Gitの良いところはGitだけでは無く、GithubやGitLabと言った先進的なツールと統合出来ることです。 これらのツールで良いところは、 マージリクエスト時の比較ツールが見やすく、効率よくレビューを行う事が出来る。 CIツールと連携してマージリクエスト時に自動的にテストを行う事ができ、その結果を上記のツール内で確認する事が出来る。 xxのソースコードの何行目と言ったステップ単位でコメントを書く事が出来る。 という点があげられます。 特にこれらの機能が1つのツールで行えるため、SVNで同様の事を実現しようとすると ビルド確認は Jenkins, タスク管理は Redmineなどツールが分散しないのが良いと感じました。 終わりに 今まで「Gitの方が良い。」とよく耳にしてましたが、 実際にやってみると「確かになぁ。」と思う部分があります。 これをみてGitを使う現場が増えてくれれば良いと思います。
どうも、客先常駐エンジニアのCLBです。 現在こんな環境で仕事をしています。
これをやってると、「こんな理由でGitの方がいい！」と感じてきたので書いてみます。
SVNで同じファイルを2人以上で触っていると、こんなことが起こります。
Aさん「作業出来た！コミット！」 SVN「Bさんの作業とコンフリクトしてます。」 Aさん「しゃーない。コンフリクト解消するか。」 SVN「解消を確認しました。コミットします。」 Aさん「作業出来た！コミット！」 SVN「Bさんの作業とコンフリクトしてます。」 Aさん「またかよ・・・」
「そうならないようにルールを決めるんだよ！」と言われましたが、 そのルールは大抵の場合、以下のような形になります。
Gitの場合、リモートからクローン（SVNで言うチェックアウト）すると、 リポジトリが個々のローカル環境に作成されます。 コミットもそのローカルリポジトリに行われるので、この時点ではコンフリクトは起こりません。
クローン
「待って、それじゃあローカルからリモートに移すにはどうすればいいんじゃ」
と声が聞こえてきます。Gitではこの操作をプッシュと呼びます。
プッシュ
SVNではコミット＝リモートリポジトリへ反映ですが、 Gitのコミットではリモートリポジトリへは反映されません。 反映はプッシュ操作を行う事で初めてリモートリポジトリへ資産が移送される仕組みです。
この時、リモートリポジトリで何らかの変更があった場合はコンフリクトが発生します。 しかしSVNの時と比べ連続してコンフリクトを解消する手間が省け、 しかもコミットを積極的に行う事が出来るようになるのです。 他の人の作業が中断されたりすることもありません。
前の項目でも述べた通り、コミットもそのローカルリポジトリに行われるので、 コミットを後から修正したり出来ます。 特に強力なのがsquash機能です。 これは複数のコミットをまとめる事ができる機能で、 これを利用する事によりコミットログを綺麗にする事が出来ます。 SVNでは"たとえ細かい修正コミットでも無かった事にしてはいけない。" というスタンスなので、このような事は出来ません。(シュタゲかな？)
squash
SVN
※これは、私が知る範囲での話です。 問題等があれば遠慮無くコメントをお願いいたします。
Gitの良いところはGitだけでは無く、GithubやGitLabと言った先進的なツールと統合出来ることです。 これらのツールで良いところは、
Git
Github
GitLab
という点があげられます。 特にこれらの機能が1つのツールで行えるため、SVNで同様の事を実現しようとすると ビルド確認は Jenkins, タスク管理は Redmineなどツールが分散しないのが良いと感じました。
Jenkins
Redmine
今まで「Gitの方が良い。」とよく耳にしてましたが、 実際にやってみると「確かになぁ。」と思う部分があります。 これをみてGitを使う現場が増えてくれれば良いと思います。
problem 現プロジェクトのソースを利用して別プロジェクトを始める時 $git clone するとpush先がclone元になってしまう。 回避する方法で時間がかかったのでまとめておきます。 SourceTreeを使うとすごく簡単でした example clone元 https://example@bitbracket.org/example/example_moto.git 保存先 https://example@bitbracket.org/example/example_saki.git とします solution 1. 何はともあれgit clone $ git clone https://example@bitbracket.org/example/example_moto.git 2. 保存先を確認 $ git remote -v origin https://example@bitbracket.org/example/example_moto.git (fetch) origin https://example@bitbracket.org/example/example_moto.git (push) push先がclone元になっています（めっちゃ当たり前ですけど。。。） ３.sourceTreeでいじっていきます pushしたいbranch/プッシュ先/originをクリック！ 4.保存先を変更 別ウィンドウが出てきて、プッシュ先のリポジトリをカスタムに変更すると後ろのURLをいじれるようになります。 内容はclone元のリポジトリになっているはずです。 ↓ URLを保存したい先に変更してOKをクリック ↓ pushすると保存したいリポジトリにpushされているはずです！ Gitは怖いですがbranch切っとけば最終なんとかなる精神でやってます 早くGitと友達になりたい 参考資料 http://undersourcecode.hatenablog.com/entry/2017/10/31/072124 そして現場の先輩に助けてもらいました。最高に感謝です。
現プロジェクトのソースを利用して別プロジェクトを始める時 $git clone するとpush先がclone元になってしまう。 回避する方法で時間がかかったのでまとめておきます。
$git clone
SourceTreeを使うとすごく簡単でした
clone元 https://example@bitbracket.org/example/example_moto.git
https://example@bitbracket.org/example/example_moto.git
保存先 https://example@bitbracket.org/example/example_saki.git
https://example@bitbracket.org/example/example_saki.git
とします
$ git clone https://example@bitbracket.org/example/example_moto.git
$ git remote -v origin https://example@bitbracket.org/example/example_moto.git (fetch) origin https://example@bitbracket.org/example/example_moto.git (push)
push先がclone元になっています（めっちゃ当たり前ですけど。。。）
pushしたいbranch/プッシュ先/originをクリック！
別ウィンドウが出てきて、プッシュ先のリポジトリをカスタムに変更すると後ろのURLをいじれるようになります。 内容はclone元のリポジトリになっているはずです。
↓ URLを保存したい先に変更してOKをクリック ↓ pushすると保存したいリポジトリにpushされているはずです！
Gitは怖いですがbranch切っとけば最終なんとかなる精神でやってます 早くGitと友達になりたい
http://undersourcecode.hatenablog.com/entry/2017/10/31/072124
そして現場の先輩に助けてもらいました。最高に感謝です。
problem 現プロジェクトのソースを利用して別プロジェクトを始める時 $git clone するとpush先がclone元になってしまう。 回避する方法で時間がかかったのでまとめておきます。 SourceTreeを使うとすごく簡単でした example clone元 https://example@bitbracket.org/example/example_moto.git 保存先 https://example@bitbracket.org/example/example_saki.git とします solution 1. 何はともあれgit clone $ git clone https://example@bitbracket.org/example/example_moto.git 2. 保存先を確認 $ git remote -v origin https://example@bitbracket.org/example/example_moto.git (fetch) origin https://example@bitbracket.org/example/example_moto.git (push) push先がclone元になっています（めっちゃ当たり前ですけど。。。） ３.sourceTreeでいじっていきます pushしたいbranch/プッシュ先/originをクリック！ 4.保存先を変更 別ウィンドウが出てきて、プッシュ先のリポジトリをカスタムに変更すると後ろのURLをいじれるようになります。 内容はclone元のリポジトリになっているはずです。 ↓ URLを保存したい先に変更してOKをクリック ↓ pushすると保存したいリポジトリにpushされているはずです！ Gitは怖いですがbranch切っとけば最終なんとかなる精神でやってます 早くGitと友達になりたい 参考資料 http://undersourcecode.hatenablog.com/entry/2017/10/31/072124 そして職場の先輩に助けてもらいました。最高に感謝です。
そして職場の先輩に助けてもらいました。最高に感謝です。
環境 Windows10 現象 git logで以下のような文字化けが発生する。 $ git log VS<E3><82><B3><E3><83><9E><E3><83><B3><E3><83><89><E3><82><92><E5><AE><9F><E8> <A3><85><E3><80><82> V<E3><82><B3><E3><83><9E><E3><83><B3><E3><83><89><E3><81><AE><E6><AD><A3><E5> <B8><B8><E5><BD><A2><E3><82><92><E5><AE><9F><E8><A3><85><E3><80><82> .gitignore<E3><82><92><E8><BF><BD><E5><8A><A0> 対処法①(毎回やる必要がある) $ git --no-pager log 対処法②(1回やればOK) $ open ~/.gitconfig config内のpagerをダブルクォーテーションで空に設定。 [core] pager = "" 参考URL GitのPagerの設定 Windowsでgit log見た時日本語が～みたいに化けた時の対処方法 - Qiita
git logで以下のような文字化けが発生する。
$ git log VS<E3><82><B3><E3><83><9E><E3><83><B3><E3><83><89><E3><82><92><E5><AE><9F><E8> <A3><85><E3><80><82> V<E3><82><B3><E3><83><9E><E3><83><B3><E3><83><89><E3><81><AE><E6><AD><A3><E5> <B8><B8><E5><BD><A2><E3><82><92><E5><AE><9F><E8><A3><85><E3><80><82> .gitignore<E3><82><92><E8><BF><BD><E5><8A><A0>
$ git --no-pager log
$ open ~/.gitconfig
config内のpagerをダブルクォーテーションで空に設定。
[core] pager = ""
想定するシチュエーション 複数人で行う開発では、branchの運用が多いと思います。 特に、Git flowのルールに則った運用が多いのではないでしょうか。 Git flowでは、基本的に開発ブランチとして"develop"ブランチがあり、 そこから派生した"feature"ブランチがあります。 ある程度規模感があって、複数人で同時並行で開発するときには欠かせないのではないでしょうか。 それぞれがdevelopブランチからfeatureブランチを作り、開発を始めますが、 自身が開発している間にも他者がコミット・プッシュ〜プルリクエスト〜developブランチにマージをしています。お互いの開発部分に重なりがある場合、もちろんのこと他者の開発部分を取り込む必要があります。 そんなときにGit rebaseを使います。 自身の修正を退避します git stash 2.developブランチに切り替える git checkout develop/*** 3.developブランチをリモートリポジトリと同期する git pull 4.自身のfeatureブランチに切り替える git checkout feature/*** 5.自身のfeatureブランチにdevelopブランチの内容を取り込む git rebase develop/*** 6.退避していた修正を戻す git stash pop これでやってるんですが、皆さんはどのようにやってますか？ 「これ違う！こうだよ！」ってアドバイス頂けたら嬉しいです。
複数人で行う開発では、branchの運用が多いと思います。 特に、Git flowのルールに則った運用が多いのではないでしょうか。
Git flowでは、基本的に開発ブランチとして"develop"ブランチがあり、 そこから派生した"feature"ブランチがあります。 ある程度規模感があって、複数人で同時並行で開発するときには欠かせないのではないでしょうか。
それぞれがdevelopブランチからfeatureブランチを作り、開発を始めますが、 自身が開発している間にも他者がコミット・プッシュ〜プルリクエスト〜developブランチにマージをしています。お互いの開発部分に重なりがある場合、もちろんのこと他者の開発部分を取り込む必要があります。
そんなときにGit rebaseを使います。
git stash
2.developブランチに切り替える
git checkout develop/***
3.developブランチをリモートリポジトリと同期する
git pull
4.自身のfeatureブランチに切り替える
git checkout feature/***
5.自身のfeatureブランチにdevelopブランチの内容を取り込む
git rebase develop/***
6.退避していた修正を戻す
git stash pop
これでやってるんですが、皆さんはどのようにやってますか？ 「これ違う！こうだよ！」ってアドバイス頂けたら嬉しいです。
