What's New Qiita

20200126のGitに関する記事は4件です。

  • 投稿日：2020-01-26T22:37:06+09:00

Gitにおけるブランチ戦略について調べてみた

なんとなく使っているGitブランチ、みんなどうやって管理しているのだろう？
その謎を解明すべく、我々はジャングルの奥地へと向かった。

1.ブランチとは

Git上で別々の作業を並行して行うための仕組みをブランチという。

# testing-branchという名前のブランチを作る場合
$ git branch testing-branch

# testing-branchブランチで作業する場合
$ git checkout testing-branch

そもそも、ブランチっていつ使うのよ？SVNでいーじゃん！
などと思っていた時代がわたしにもありました。

SVNなどの中央集権リポジトリを利用していると、自分のコミットがどうやっても他人に影響を及ぼしてしまいます。
（コミットしたら、Aさんが修正したソースが壊れました:angel_tone2:とかね）

自分のソースをマージして挙動確認したい！でも他の人には迷惑かけたくない！
そんな時にとても便利なのがブランチ。

本番環境で動くソースリポジトリから自分の開発用ブランチを作って、自分が修正した分だけをテストしてマージ、なんてことが簡単にできます。

2.ブランチ戦略とは

ブランチは誰でもいくつでも作ることができる。
ブランチのブランチ、とかもできちゃう。
無法地帯の予感・・・！！！

というわけで、無法地帯にならないように計画的にブランチを作って運用していくために編み出されたもの、それがブランチ戦略。
Gitを使っているチームの数だけブランチ戦略がある。たぶん。

3.代表的なブランチ戦略

代表的なブランチ戦略について調べてみる。

  1. git-flow
  2. GitHub Flow
  3. gitworkflows
  4. 安定trunkパターン
  5. メインラインモデル
  6. GitLab Flow

1. git-flow

下記のブランチを主軸に運用する方法。

  • master
  • hotfix
  • release branches
  • develop
  • feature branches

開発の流れ

git-flow.png

下記ルールに従い運用します。

  • developはmasterの最新から作成
  • featureはdevelopの最新から作成
  • releaseはリリース対象featureマージ済developの最新から作成
  • 各featureのマージ先はdevelop
  • releaseはリリース時のバージョン調整などに使用
  • リリースモジュールはmasterから作成
  • リリースバージョンが上がるタイミングでreleaseからmasterにマージ
  • マージ済featureは削除
  • hotfixは致命的バグが発生した場合に使用

2. GitHub Flow

下記のブランチを主軸に運用する方法。

  • master
  • work branches
  • (integration branches)

開発の流れ

GitHub-flow.png

下記ルールに従い運用します。

  • masterは常にデプロイできる状態とする
  • 作業ブランチはmasterから作業内容がわかるような名前のブランチを作成する
  • 複数の作業ブランチを統合するための統合ブランチを作成しても良い
  • 開発者は作成した各ブランチにコミットする
  • 定期的にpushする
  • masterへのマージ前に、PullRequestを作成し他の開発者からレビューを受ける
  • masterへマージ後、直ちにデプロイするためにデプロイ作業を完全自動化する
  • テストを重要視する

3. gitworkflows

下記のブランチを主軸に運用する方法。

  • maint
  • master
  • next
  • pu(proposed updates, 提案中の変更)

開発の流れ

gitworkflow.png

下記ルールに従い運用します。

  • maintでは前回リリースされた安定バージョンのアップデートを管理
  • masterでは次回のリリースに入るべきコミットを管理
  • nextは、masterトピックの安定化のための テスト用ブランチとして使用。masterリリース後にgit reset --hard masterする。
  • puは、含めるにはまだ時期尚早なコミット用の統合ブランチとして使用。masterリリース後にgit reset --hard masterする。
  • マージ作業が多い
  • プルリクエストを利用しない（メーリングリストへメールすることで変更を知らせる）

4. 安定trunkパターン

下記のブランチを主軸に運用する方法。

  • stable
  • Milestone1
  • Milestone2
  • (以下略)

開発の流れ

stable-trunk.png

下記ルールに従い運用します。

  • Milestoneは必ずstableブランチから作成
  • stable = trunk = リリースされているもの / いつでもリリース可能なもの
  • 複数のリリース向けの開発、結合が可能
  • マイルストーンを新設するたびに継続的インテグレーションの設定を行う必要あり
  • 複数のバージョンのメンテナンスが出来ない

5. メインラインモデル

下記のブランチを主軸に運用する方法。

  • develop
  • version 1.x
  • version 2.x
  • (以下略)

開発の流れ

mainline.png

下記ルールに従い運用します。
- developブランチで作業
- 複数リリースバージョンを管理できる
- 複数バージョンを管理しない場合は、いわゆるdevelop & stableモデルと同じ

6. Git Lab Flow

下記のブランチを主軸に運用する方法。

  • master
  • pre-production/staging
  • production
  • (feature/hotfix)

開発の流れ

image.png

下記ルールに従い運用します。

  • pre-production = GitHub Flowの統合ブランチ = git-flowのrelease
  • 作業が終わったらfeatureブランチにコミット
  • CIでのテストをパスしたらpre-productionに自動デプロイ
  • pre-productionでのテストをパスしたらproductionに自動デプロイ

4.所感

  • GitHub flowとGitLab-flowの使い分けがまだよくわからない。
  • CI環境が整っているならマージが多く発生するフローでも問題なさそう
  • 小さいチームやプロジェクトならmasterとdevelopのみのGitHub flowが使いやすそう
  • チームの規模、リリース頻度、チームのスキルレベル、運用難易度などの観点で再度整理したい

参考

GitHub実践入門　Pul Requestによる開発の変革
大塚弘記 著/技術評論社/2014.04.25初版/

A successful Git branching model翻訳

書籍「Pro Git」のコンテンツ

git運用フローの選び方

Gitのブランチモデルについて

Using git-flow to automate your git branching workflow

(分散)バージョン管理システムの組織化

Gitlab-flowの説明

Introduction to GitLab Flow

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-01-26T10:31:53+09:00

【PART1】もしあなたがUnityのGit管理をしようとしてこられてきてたとしたら、絶対にさせてあげられてたと思うか？

UnityをGit管理したい！

タイトルをかまいたち風にしたところで、どうもBuzzです。今日はUnityでGit管理をする方法をアウトプットしていこうと思います。

前半はただGit管理の方法を書いて、後半はチームで開発するための知識を書いていきます。

なぜ書くのか

今回この記事を書いているのにはこのような経緯がありました。

プログラミングを今までやってこなかった完全な初心者の友達と「一緒にゲーム開発したくね？」
↓
僕も一緒に技術書を買って勉強し初める
↓
技術書を読み終えてひと段落したので、その初心者の友人にむけてGit管理の方法をしらべてテキストファイルにしようと思いつく
↓
どうせ書くならQiitaや！←いまここ

そんなこんなでかなり初歩的なことも書いてありますし、僕自身Gitに詳しい訳でもないので大目に見てください。間違い・ご意見ありましたらコメントしていただけると今後に役立ちます。

Gitとは？

Wikiから引用

gitは、プログラムのソースコードなどの変更履歴を記録・追跡するための分散型バージョン管理システムである。Linuxカーネルのソースコード管理に用いるためにリーナス・トーバルズによって開発され、それ以降ほかの多くのプロジェクトで採用されている。
gitでは、各ユーザのワーキングディレクトリに、全履歴を含んだリポジトリの完全な複製が作られる。したがって、ネットワークにアクセスできないなどの理由で中心リポジトリにアクセスできない環境でも、履歴の調査や変更の記録といったほとんどの作業を行うことができる。

このことから、要は開発中の煩わしいところ省いていこうぜ！ってことです。

個人開発の場合

例えばいままで一人で何かを開発するにしても、「急に動かなくなった」とか「前の状態に戻したいけど保存しちゃった！」とかそういった場合に気を配って開発していく必要がありました。

ですが便利な時代になり、「ソースのバックアップ」をとることができるようになりました。

携帯も「やべ、全部データけしちゃった！！」って状態になった時、バックアップを取っていたら、パソコンに繋ぐだけでそのデータたちが戻ってきますよね？それと一緒で、コードも「やべ、動かなくなった」に対応できるわけです。

チーム開発の場合

チーム開発の場合を考えると、もちろんコードのバックアップもそうですが、もっとメリットがあります。

Gitが主流になる前のチーム開発では一つのフォルダを複数人で共有する必要がありました。

例えば3人でチーム開発をしようとしていえて、共有フォルダにはAファイル、Bファイル、Cファイルがあった場合。

・AさんはAファイルを編集して共有フォルダに戻す！
・BさんはBファイルを編集して共有フォルダに戻す！
・CさんはCファイルを編集して共有フォルダに戻す！
背景.png

このようにそれぞれが別々のファイルを編集していれば対して問題ではなく、ただ単にソースのバックアップが面倒くさいというのという状況だけで済みます。

ですが例えばこのような状況はどうでしょうか。

家電量販店のシステムを開発しているとして、Aファイルにはすでに価格設定処理が追加されていると想定してください。

・A,B,CさんはAファイルを自分の環境に持ってくる
・AさんはAファイルに商品登録処理を追加して共有フォルダに戻す!
・BさんはAファイルに在庫管理処理を追加して共有フォルダに戻す！
・CさんはAファイルに発注処理を追加して共有フォルダに戻す!

共にAファイル.png

見ての通り地獄の始まりですよね。
この時Aさんが1番最初にタスクを終わらせて、Bさん、Cさんの順にタスクが終わったとしましょう。

その場合Aさんはいままで通り、Aファイルを編集して共有フォルダに戻すだけでいいです。
ですが、BさんCさんは違います。

この3人はもともと共有フォルダに置いてあった価格設定処理のみが書かれたAファイルをコピーしてそれぞれ処理を追加しているのですから、最初に終わったAさんはいいですが、BさんCさんにはAさんが追加した処理が反映されていない状況になります。

以上により、この時3人は反映時に以下のことに気を配る必要があります。

・Aファイルに他の二人の処理が反映されていないか
・反映されていた場合、まずそのコードの該当箇所を自分のファイルに反映
・反映したファイルで共有フォルダのAファイルを上書き

面倒くさいですよね。
まあ上書きせずに共有フォルダのAファイルに追加した処理をコピペすればいいんですが、追加処理が多かったり反映ファイルが多かったりすると「追加し忘れ」などが生じる可能性があります。

気配り軽減！Gitの登場

そこで登場するのがGitです。
Gitにはリポジトリというものがあります。
さっきの例で言うと「共有フォルダ」がこのリポジトリに当たります。
実際のソースコードはファイル単位ではなくディレクトリ（フォルダ）単位である場合がほとんどなので、先ほどを例に「Buzz電気」というお店のシステム開発をする想定で見てみましょう。

Buzz電気システムリポジトリという空間にAフォルダがあり、その中にA、B、Cと言う名のファイルがあるとします。
GitではまずそのリポジトリをClone(クローン）してきます。（本来はこの作業の前にforkをした方がいいのですが必ず行わなければならない訳ではない為、割愛しています）

クローンというのは要は「コピー」です。Aフォルダをそのまま自分のところに持ってきます。

先ほどは以下の手順が必要でした。

①A,B,CさんはAファイルを自分の環境に持ってくる

②AさんはAファイルが更新されていないか目視で確認した後、商品登録処理を追加したAファイルを共有フォルダに戻す!

③BさんはAファイルが更新されていないか目視で確認した後、Aさんが追加した箇所を見つけ出し、在庫管理処理を追加したAファイルに反映させた後、そのAファイルを共有フォルダに戻す！

④CさんはAファイルが更新されていないか目視で確認した後、AさんBさんが追加した箇所を見つけ出し発注処理を追加したAファイルに反映させた後、そのAファイルを共有フォルダに戻す!

言葉で表してもややこしい作業です。
これをGitの機能を使って再現してみます。わからない言葉が出てきても一旦スルーしてください。

①A,B,CさんはBuzz電気システムリポジトリ（リモートリポジトリ）を自分の環境にクローン（複製）する

②Aさんは商品登録処理を追加した後、リモートリポジトリをPull（プル）してからCommit(コミット）しPush(プッシュ）します。

②Bさんは在庫管理処理を追加した後、リモートリポジトリをPull（プル）してからCommit(コミット）しPush(プッシュ）します。

②Cさんは商品登録処理を追加した後、リモートリポジトリをPull（プル）してからCommit(コミット）しPush(プッシュ）します。

なんとなく楽な感じが伝わりますか？（伝んねぇよ）

まず、なんども出てきたリモートリポジトリというのが、みんなの共有フォルダみたいなものです。そこに向かって変更を加えていく訳ですが、手元にはそのリモートリポジトリの複製がある状態です。
ここからがGitの幸せなところで、手元にある複製になんらかの機能を追加したとします、Aさんは商品登録処理ですし、Bさんは在庫管理処理を追加するのでしたね。

追記後は、以前のままだと共有フォルダにあるAファイルに他の人がなんらかの処理を追加していないか、目で確認する必要がありました。

ですがGitでは共有フォルダと手元にある複製を見比べ、両者になんらかの差異があれば、手元にある複製にその差分だけ反映してくれるのです。
これが先ほど手順で出てきた「Pull」というものです。英語で見るとわかりやすいですね。Pullは「引く」ですから、リモートリポジトリ（わかりやすく共有フォルダ）から差分を引っ張ってきてくれるわけです。

これで今まで目視で確認していた面倒くさい手順から解放されるわけです。この時点「いいもの」ということはわかりますね。

Pullすることで手元のフォルダと共有フォルダ（リモートリポジトリ）の違いはなくなりました。そのあとはどうしたらいいのでしょうか？手元には自分が追加した処理と共有フォルダ（リモートリポジトリ）に反映されていた処理が記述されたAファイルがあるのですから、もちろんそのAファイルを共有フォルダに戻しますよね。そうすると正式に共有フォルダのAファイルに自分の処理が追加されるわけです。

ではそれだけ目視でコピペしていくのかと言うとそれは違います。
Gitにはコミットという行為があり、コミットとは自分が変更した箇所の集まりだと思ってください。例えば、商品登録処理であれば、商品を登録するための入力フォームを作った時点で、一旦コミットしてその変更を保存しておき、その後その入力フォームから受け取ったデータでなんやかんやする処理を追加した後にまたコミットしたり。
いつでも後戻りできるように保険を作っていくわけです。

最後にそのコミットの塊をPushという行為で共有フォルダに反映させます。これで煩わしい作業から解放されるわけですね。

実はGitにも気を配るべき事項がいくつもあるのですが、それは実際にチーム開発などするときに気をつければいいので今回は割愛しました。かなり長くなりましたがGit管理という考え方をわかって欲しかっただけなので、「もっと詳しくしりたい！」という方は、さらに詳しく書いてあるブログやQiitaなどありますので、こちらをご覧ください。
ただ百聞は一見に如かずです。すこしでも理解したら実際に触ってみることをお勧めします。新卒でIT業界に就職した方は、くれぐれも会社のGitでチャレンジしないでくださいね！！w

こちらのサイトはわかりやすく解説されています。
ここは体型的にGitを学んでいけます。

UnityでのGit管理方法

前置き長くなりましたが本題に入っていきましょうか。
ここからは簡潔にUnityでGit管理していく方法を記述していきます。

準備

僕はWindowsを持ってないのでMacでの説明になりますが、ほとんど変わらないと思うのでその都度補足説明を入れていきます。

①何はともあれ、Unityでプロジェクトを作ろう！

スクリーンショット 2020-01-26 0.39.26.png

いつも通りなんらかのプロジェクトを作りましょう！今回は/User/kohei/UnityGamesというフォルダに「Unity_de_Git」というプロジェクトを作りました。
ここはWindowsも変わらないとおもいます。

②Finder（フォルダ）で確認しよう！

スクリーンショット 2020-01-26 0.42.04.png

今回はGitについてなのでプロジェクト作成後に開くUnityの画面はとりあえず閉じて大丈夫です。
先ほど僕は/Users/kohei/UnityGamesフォルダにプロジェクトを作りました。ご自身のプロジェクト保存先をみて、プロジェクトが作成されていることを確認しましょう。
Windowsの場合もプロジェクトを作成する際、「保存先」として使用したフォルダに行けばプロジェクトがあるはずです。
ちなみに「Users/kohei/UnityGames」という保存先は「Unity/kohei/UnityGames」というフォルダがあるわけではなく、「Usersフォルダの中のkoheiフォルダの中のUnityGamesフォルダ」という意味です。

③できていましたか？中身を確認しましょう

スクリーンショット 2020-01-26 0.44.37.png
では作成したプロジェクトをダブルクリックして開いてみましょう。
バージョンによって多少違うかもしれませんが、WindowsもMacもおおよそこのような内容になっているはずです。

⑤Gitのご登場、、、の前に！

これからGit、、、といきたいところですがその前に、実はGit管理にはコマンドを使う方法というのがあり、プログラマとして勤務する人はわりかし目にする機会があるかもしれませんが、全く無知な方からすると黒い画面に呪文のような文字を打っていくことになり、今自分が何をしているのかわからない状態でGit管理をしても感覚がつかみにくいと思いますので、呪文を使わないやり方でご紹介していきます！慣れたらぜひコマンドにも挑戦してみてくださいね！

ではまずこちらにいって「SourceTree」をダウンロードしましょう！僕はMacなので「Download for Mac OS X」となっていますが、Windowsのパソコンからこのサイトにアクセスすると「Download for Windows」になっているとおもいます。もしなっていない場合は、「Download for Max OS X」ボタンの下に「Also available for Windows」と書いてあるところをクリックしてください。
スクリーンショット 2020-01-26 0.58.59.png
これはGitを直感的に管理できるソフトで、プログラマの方以外でも比較的導入しやすいGUIのGit管理ツールです。
スクリーンショット 2020-01-26 1.01.17.png
僕がダウンロードしようとした時は（2020/01/26現在)このような確認画面がでました。
「あんた、このソフトダウンロードするんやろ？ほなライセンスとポリシーに同意するんやな？」的な文です。
これは下のチェックボックスにチェックを入れましょう。すると「Download」ボタンが押せるようになるはずです。これはWindowsも同じです。
スクリーンショット 2020-01-26 1.04.08.png
スクリーンショット 2020-01-26 9.08.20.png
するとSoucetree_4.0.xxx.zipがダウンロードされました。この数値の部分はバージョンなのでそこまで重要ではありません。
これをクリックして開きましょう。Macなら自動でFinderに展開してくれると思います。Windowsはパソコンによりまちまちなので、任意のフォルダに展開してください。よく使うソフトなのでデスクトップにショートカットアイコンを作ってもいいと思います。
スクリーンショット 2020-01-26 9.13.12.png
Macの場合はいきなり「Sourcetree.app」ができるはずです。アプリケーションなので「アプリケーション」フォルダに移動させておいてもいいかもしれません。
スクリーンショット 2020-01-26 9.15.48.png

⑥実際に作業していこう！

これでダウンロードは終了しました、Sourcetreeを入れればすぐにGit管理できるのかというとそうではないのでこれからはGit管理するための設定なんだりを説明していきます。
ここからはアプリケーションでの作業になるためMacとWindowsで違うことはあまりないと思いますので、最小限に省きます。
まずはSousetreeを開きましょう！
スクリーンショット 2020-01-26 9.40.28.png
.png">

初期画面はこのような感じだと思います。まずはGithubというサービスと接続しましょう！ちなみにこのGithubもGitを使いやすくするサービスなのでGitとは別物です。
右上の歯車のマークをクリックしましょう
スクリーンショット 2020-01-26 9.43.57.png
このように設定一覧が表示されるとおもうので、「アカウント」をクリックしてください。
するとこのような画面が表示されるはずです。左下の追加をクリックしてください。
スクリーンショット 2020-01-26 9.45.10.png
するとこのような画面になると思いますのでホストを「Github」に変更してください。その他画像と違う箇所があれば画像の通りに設定しましょう。
スクリーンショット 2020-01-26 9.49.29.png
画像の通りに設定できたらアカウントの連携です。「接続アカウント」ボタンをクリックしてください。
するとWindows、Macに関わらずブラウザが開きGithubにログインを求められるとおもいます。
スクリーンショット 2020-01-26 9.58.10.png
すでにアカウントを持っている場合はログインしてください。アカウントを持っていない場合は画像下の「Create an account」をクリックして、必要事項を入力してアカウントを作成しましょう。ちなみにアカウント作成時にプランの洗濯を求められるのですが、「Freeプラン」で大丈夫です！
スクリーンショット 2020-01-26 10.01.36.png
するとブラウザからSourcetree開くか聞かれるので開いてください。
開くとこのようにアカウントが接続されていることが確認できると思います。あとは「保存」をクリックしてください。
スクリーンショット 2020-01-26 10.02.42.png
このようにアカウントが表示されたら成功です！
スクリーンショット 2020-01-26 10.05.51.png
ここまできたら一旦設定画面は閉じてメイン画面に移動しましょう。
メイン画面で①の「ローカル」が選択されている状態で②の「新規」をクリックしてください。
スクリーンショット 2020-01-26 10.08.35.png
するとこのような選択肢が表示されるので「ローカルリポジトリを作成」をクリックしてください。
スクリーンショット 2020-01-26 10.10.38.png
ローカルリポジトリというのはリモートリポジトリ（共有フォルダ）と逆で、個人個人のリポジトリです。先ほどはリモートリポジトリにあったAファイルを自分のところに持ってきました。この持ってきたものがGitでは「ローカルリポジトリ」という扱いになります。今回はローカルリポジトリから作成しているので、リモートリポジトリはまだ存在しない状態です。
スクリーンショット 2020-01-26 10.17.18.png
開くとこのように表示されるので
①にUnityのプロジェクトを作成したフォルダを選択してください。
②にはリポジトリの名前をつけることができます。任意で名前をつけてください。特に理由がなければそのままで大丈夫です。
ここで注意してほしいのは①で選択するフォルダは僕で言えば「Users/kohei/UnityGames」ではなく、今回作成したプロジェクトなので画像のように「Users/kohei/UnityGames/Unity_de_Git」になります。あくまでプロジェクトを選択してください。
設定できたら作成をクリックしましょう。「リモートリポジトリも作成する」はとりあえずチェックなしで大丈夫です。
スクリーンショット 2020-01-26 10.24.43.png
するとこのように何も表示されていなかった一覧に今作成したローカルリポジトリが表示されます。

つづく

お疲れ様でした！まだ作業は続くのですが、かなり長くなりそうなので数回に分けます。

次回はこちら←準備中です

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-01-26T10:24:39+09:00

それでも忘れるので頻出gitコマンドをまとめておく

前置き

Gitはバージョン管理に欠かせないツールですが，しばらく使っていないとすぐに忘れてしまうので，よく使うコマンドをまとめておきます．この手の記事は余るほどにあるのですが，自分用のメモという意味合いでまとめておきます．

コマンド

Initializing Local Repositories

$ git init

gitリポジトリの作成．正確には，そのディレクトリに '.git' というサブディレクトリを作ることによって，git管理を可能にする．
ローカルで作成するときはこれを用いて，GitHubにあるリポジトリを引っ張ってくるときは '$ git clone' を用いる．

$ git status

現在のgit状態をみる．非常によく使う．

Staging & Committing

$ git add [file-name] or $ git add .

変更を加えたファイルをstageに載せる．変更を行った全てのファイルをstagingしたい場合は2番目のようにする．

$ git commit -m "message"

stageにある全てのファイルをcommit

$ git log

今までのcommit履歴を表示する．2番目のようにすると，ツリー状に表示される．
$ git log --graphとすればツリー状に，さらに$ git log --oneline --decorate --graphというオプションも付ければ簡潔なツリー状に表示できる．

$ git rm [file-name]

gitはファイルの削除も差分として認識されるので，ワーキングツリー上で削除した場合は，インデックス(ステージ)に空のファイルとして残ってしまうことがある．それを防ぐために，ファイルを完全に削除したいなら$ git rmを使う1．このサイトを参照．

$ git mv [file-from] [file-to]

gitにはファイルの移動やファイル名の変更をを明示的に追跡することがないので，普通のmvを行う場合は以下のような操作をしなくてはいけない．代わりに$ git mv README.md READMEとすれば，インデックス(ステージ)に即座に反映される．

例
$ mv README.md README
$ git rm README.md
$ git add README

Undoing Changes

resetコマンドに関しては，この記事に非常に分かりやすく書いてあるので，以下のコマンドを盲目的に使う前に，実際に何を行っているのかを理解しておくといいと思います．
また，下の補足も参考に．

$ git reset HEAD [file-name]

stagingしたファイル(まだcommitしていない)をunstageする．(ワーキングツリーはそのまま)
$ git reset HEADとすると，全てのファイルがunstagingされる．

$ git reset --soft HEAD^

直前のコミットのみを取り消して，ファイル変更やインデックス(ステージ)の状態はそのままにする．

$ git reset --hard HEAD^

直前のcommitを丸々全て取り消す．そのcommitに付随したファイル変更は全て取り消される．(一つ前のcommit直後の状態に丸々戻るイメージ)

$ git reset --hard ORIG_HEAD

直前に間違えてしてしまったリセットを取り消す．commitされていなかった場合は，ORIG_HEADとして残っていないので取り戻せない．この意味で，$ git reset --hard HEAD^は注意が必要．

$ git commit --amend

直前のcommitにファイルを加えたいorコミットメッセージを変更したいときに使う．直前のcommitが上書きされる．

例
$ git commit -m "message"
$ git add [forgotten-file]
$ git commit --amend

$ git rest --soft HEAD^を使って，HEADの位置だけを元に戻してからaddし直しても機能的には同じことになるが，直前のコミットを上書きするだけならこの方が楽．たくさんのcommitを一つにまとめたいなら，以下の方法がいい．

これも同じ
$ git commit -m "message"
$ git reset --soft HEAD^ #HEAD^は，HEADの一つ前のcommitを表す(HEAD~1も同じ)
$ git add [forgotten-file]
$ git commit -m "message"

$ git checkout -- [file-name]

特定のファイルを，最後にcommitした状態まで戻す．そのcommit以降の変更は完全に消されてしまうので，注意が必要．
意味としては，$ git checkout [branch-name]と同じ要領で，そのファイルの最後のcommit位置までcheckoutするということ．'--'を付けなくてはいけない理由は，このサイトにあるように$ git checkout branch名と明確に区別するため．

Git Branching

$ git branch

branch一覧の確認. $ git branch -vとすると，それぞれのbranchのcommit内容も表示することができる．

$ git branch [new-branch-name]

新たなbranchの作成.

$ git checkout [destination-branch]

指定のbranchへHEADを移動.

$ git checkout -b [new-branch-name]

$ git branch [new-branch-name] + $ git checkout [new-branch-name]

$ git branch -d [branch-to-delete]

branchの削除．

$ git merge [branch-name]

branchのmerge．現在HEADが指しているbranchに対して，指定したbranchの内容が取り込まれる．(masterに，developブランチで行ってきた変更を取り込みたいのなら，$ git checkout masterを行ってから，$ git merge developを行う．)
ちなみに$ git merge [branch-name] --no-ffとすると，mergeする二つのbranchが直接つながっているときにも，Fast Forward Mergeを行わずにcommitツリーが分かりやすくなるので，こちらをおすすめ．

Remote Repositories

$ git remote

リモートリポジトリ一覧の確認．$ git remote -vとすると，urlつきで表示される．

$ git remote add [remote-name] [remote-url]

リモートリポジトリを[remote-name]として登録．

$ git remote rename [old-name] [new-name]

リモートリポジトリのrename．

$ git remote rm [remote-name]

リモートリポジトリの削除．

$ git clone [remote-url] [directory-name]

リモートリポジトリを，現在のディレクトリ直下にコピー．[directory-name]を付けないと，リモートリポジトリの名前がそのまま使われる．このとき，リモートリポジトリの名前は，自動的に'origin'になる．

$ git push -u [remote-name] [remote-branch]

branchの内容をリモートリポジトリのbranch反映させる．$ git push -u origin masterのように使うが，共同開発をしているときにはこの記事にあるように，リモートリポジトリのmasterブランチにプルリク無しでmergeしてしまうので絶対にやってはいけない！ 必ず新たなブランチを切ってから，$ git push -u origin developなどと行う2．
ちなみに，オプションの'-u'は次回から$ git pushとだけ打っても同様の操作が行われるように記憶するもの(参照)

$ git fetch [remote-name]

リモートリポジトリの変更内容を，リモート追跡ブランチに取り込む(参考)．
下のようにすると，リモートリポジトリの特定のbranchのcommit履歴を追従できる．

例
$ git fetch origin
$ git branch review-ai-fix origin/fixing-ai-heuristics #新たにreview-ai-fixというbranchをローカルリポジトリに作ってそこにorigin/fixing-ai-heuristicsの内容を反映させる
$ git checkout review-ai-fix
$ git log --graph

$ git pull [remote-name] [remote-branch-name]

リモートリポジトリの内容を取り込んで，さらにHEADの位置にmergeする．下の操作と同じ．(pull=fetch+merge)

$ git fetch origin
$ git merge origin/master #origin/masterというリモート追跡ブランチが，HEADが指しているbranchにmergeされる

Tags

$ git tag ([commit-hash]) [tag-name]

特定のcommitにtagを付ける．[commit-hash]を省略すると，HEADの位置に付けられる．

$ git tag -a [tag-name] ([commit-hash]) -m "message"

注釈付きtagをつける．

$ git tag

tag一覧の表示．

$ git push [remote-name] [tag-name]

単にcommitをpushしただけではリモートにtagは反映されないので，個別にこのコマンドを打つ必要がある．(tagのpushは全く独立だという認識を持っておいた方がいい．tagを付ける前後で差分もない．) 全てのtagをまとめてリモートに反映させるときは$ git push [remote-name] --tags

$ git tag -d [tag-name]

ローカルでtagの削除．

$ git tag origin --delete [tag-name]

リモートでtagの削除．(ローカルでtagを削除した後に$ git push [remote-name] [tag-name]としても反映されない．反映させるという意味では，$ git push [remote-name] :[tag-name]とすれば，反映される．)

補足

branchについて

branchは，commitによって形成された以下のようなツリーの，各commitに紐付けられた名前だと考える．下の画像のC0,C1,$\dots$にはそれぞれ，'b8afr45'のようなハッシュ値が紐付けられている(それらは$ git log --oneline --decorate --graphを行えば確認できる)．それらに特定の名前がついたものが，branchであるという認識をしておいた方がいい．
つまり例えば，$ git checkout [branch-name]とすることと，$ git checkout そのbranchが指しているノードのハッシュ値とすることは同様の操作をしている．
また，HEADとは「今いる場所」を示し，HEADがC7にいる場合，C3はHEAD^(またはHEAD~, HEAD~1)，C1はHEAD^^(またはHEAD~2)と指定することができる．(HEADがC4にいる場合，HEAD^はC3，HEAD^^はC1を指す．)
ちなみに，commitにtagをつけるものには$ git tag [tag-name]というコマンドもある．(詳しくはこの記事を参照．)こうすると，上の操作は$ git checkout [tag-name]とも書ける．
Screen Shot 2020-01-24 at 22.38.02.png

resetとcheckoutの違いについて

まず，commitによるツリーの動きはこの記事が非常に分かりやすく，ファイルを変更することでワーキングツリーが動き，stagingすることでインデックス(ステージ)がそれに追従し，commitをすることで，HEADが追従して，ここで初めてハッシュ値が生成されて，commitツリーに新たなノードが加わるというイメージを持つといい．
Screen Shot 2020-01-24 at 22.38.02.png Screen Shot 2020-01-24 at 22.38.02.png
resetコマンドは，--soft, --mixed(デフォルトはこれ), --hard というオプションに基づいてHEADの位置を特定のcommitノードまで移動させる操作であるが，そのときHEADが指し示していたbranchも一緒に移動する．(例えば，HEADがmasterブランチを指している状態(上図のC7にHEADがある状態)で$ git reset --soft C0のハッシュ値とすると，HEADもmasterもC3に移動する) このときC7の情報はgitのデータベースには残っているため$ git reflog3としてハッシュ値を取得すれば$ git reset --hard ハッシュ値として戻ることができるが(もしくは，$ git reset --hard ORIG_HEADとする)，
これに対してcheckoutコマンドは，HEADの位置のみを変更する．(先の例だと，HEADのみがC3に移動するが，masterブランチはC7に残ったままになる．)
このような違いがあるので，単に過去の履歴を参照したかったりbranchの切り替えを行うにはcheckoutを用いるのが得策であり，resetは直前のcommitやaddの操作を取り消したいときなど最小限に留めておくのが原則である．(そもそもgit管理の原則はこまめにcommitを行うことで履歴を残すことにあり，ツリーを綺麗にしておくことではない．)

参考記事

Gitがよく解る記事

  1. ワーキングツリーにはファイルを残したいがgit管理下にはおきたくない場合は，.gitigonoreにファイル名を記述する．(変更した.gitignoreをcommitすることを忘れない．) ↩

  2. $ git push -u [remote-name] [remote-branch]は，[remote-name]にある[remote-branch]というbranchに，ローカルレポジトリのHEADの内容を反映させるコマンドである．だから，$ git push origin masterとしてしまうと，originにあるmasterに，プルリク無しでmergeされてしまうのである．$ git push -u origin developとするのは，originのdevelopブランチにmergeするだけであって(無ければ自動的に作られる)，それをoriginにあるmasterにmergeするようにお願いするのが，プルリクである．そのため，$ git push -u origin developの'develop'は自分のdevelopブランチを指しているわけではないので，pushをする前にはcheckoutをしてpushしたいcommitの位置にHEADを持ってきておく必要がある． ↩

  3. このサイトにあるように，$ git logはHEADが指すcommitとその祖先を出力するが，$ git reflogはHEADが辿ってきた順序をリストとして出力する．そのため，resetコマンドで一つ前のcommitノードに戻ってしまった場合は$ git logではその前のcommitが確認できないが，$ git reflogでは確認することができる．($ git reflogに--graphオプションがないのも，$ git reflogは単にHEAD履歴の順序リストであるからである．) ↩

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-01-26T00:45:34+09:00

Laradocを使ってLaravel6の開発環境をインストールする

はじめに

こちらの記事はTechpitに販売されている教材を進めるにあたって、教材を参考（ほぼ丸写し）にさせてもらって作成しています。
参考箇所はプレビュー部分なので、誰でも見ることができます。
URLも貼っておきます → Laravelで飲食店検索LINE Botを作ろう！
開発者はコチラの方です → やんばるさん(@shonansurvivors)

前提

Dockerをインストールしていること。
今回は略しますが、開発者のプレビューでもインストールの方法を丁寧に解説されていますので、よければご覧ください。

ユーザライブラリフォルダの直下にフォルダを作成

今回はユーザライブラリフォルダの直下にlaravel-projectフォルダを作成します。
下記のコマンドを叩けばユーザライブラリフォルダの直下にlaravel-projectフォルダを作成できます。
さらにlaravel-projectフォルダに移動。

$ cd
$ pwd
/Users/Macでのユーザー名

$ mkdir laravel-project
$ cd laravel-project

Laradocのインストール

GitHubからlaradockのファイルをコピーします。

$ git clone https://github.com/Laradock/laradock.git

Cloning into 'laradock'...
remote: Enumerating objects: 10007, done.
remote: Total 10007 (delta 0), reused 0 (delta 0), pack-reused 10007
Receiving objects: 100% (10007/10007), 8.99 MiB | 1.61 MiB/s, done.
Resolving deltas: 100% (5432/5432), done.

もし下記のようなメッセージ（XcodeとiOSのライセンスの同意）が出たらリンク先を参考にしてみてください。

Agreeing to the Xcode/iOS license requires admin privileges, please run “sudo xcodebuild -license” and then retry this command.

Gitコマンド実行時に、XcodeとiOSのライセンス同意を求められた場合の解決法

しばらく時間がかかりますが、完了すると、laravel-projectにlaradockフォルダが作成されます。

$ ls
laradock

laradockの.envファイルを作成

laradockフォルダに移動します。cpコマンドでlaradockにあるenv-exampleファイルをコピーし、.envファイルを作成します。

$ cd laradock
$ cp env-example .env

これでenv-exampleファイルをもとに.envファイルが作成できました。

laradockの.envファイルを編集する

テキストエディタでlaladockフォルダの.envファイルを開き下記のように変更。

APP_CODE_PATH_HOST=../laravel
DATA_PATH_HOST=../data

Dockerを使って開発環境を起動する

引用させていただきます。

次にDockerを使って開発環境を起動します。
Docker上で動く各サービスの単位をコンテナと呼びます。
ここでは、以下3つのコンテナを起動します。
・workspace
・php-fpm
・nginx

laradocディレクトリにいることを確認し、下記のコードを実行する。

$ docker-compose up -d workspace php-fpm nginx

docker-composeは、複数のコンテナを同時に取り扱うDocker Composeという機能を使うためのコマンドです
upは、Docker Composeでコンテナを起動するときに使うコマンドです
-dは、コンテナを起動した後に、ターミナルの操作に戻るためのオプションです

結構時間かかります。

Creating laradock_docker-in-docker_1 ... done
Creating laradock_workspace_1        ... done
Creating laradock_php-fpm_1          ... done
Creating laradock_nginx_1            ... done

上記のメッセージが表示されたらコンテナの起動が成功している。

Dockerコンテナの起動確認

ブラウザを起動し、 localhost とだけ入力。「404 Not Found」のエラーが出れば、Dockerが起動しているのでひとまずはOK。

Laravelのインストール

laradocフォルダにいることを確認した後、Laravelをインストールします。

$ docker-compose exec workspace composer create-project --prefer-dist laravel/laravel . "6.2.*"

Installing laravel/laravel (v6.2.0)
  - Installing laravel/laravel (v6.2.0): Downloading (100%)         
Created project in .
.
. // 中略
.
Package manifest generated successfully.
> @php artisan key:generate --ansi
Application key set successfully.

てな感じでlaravel-project直下にlaravelのフォルダが作成される。
localhost　へブラウザでアクセスしてみるとLaravelのウェルカムページが表示される。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

日付別

タグ一覧