【改】Gitが全然分からなかったので勉強した。辛い。

  • 7
    Like
  • 5
    Comment

あれから数日...

Gitが全然分からなかったので勉強した。眠い。
↑これから数日

業務でgitを触り始めたけど、結局分からず。
先輩に聞きながら試行錯誤したモノの、失敗したりしたので、同じ失敗をしないように備忘録として残しておく。

もう失敗したくない。

辛い。

まず始めに大まかな流れ

  • 1. Gitリポジトリから最新を取ってくる
  • 2. ブランチを切る
  • 3. 作業する
  • 4. コミットする
  • 5. プルリクないしマージリクエストを送る

git分かる人なら、この説明で「ハイヨー」って感じなんでしょうけど、
初心者からしたら何言ってんのか分からん。

辛い。

という事で始めるよ。

一応、以下の条件としておきます。

  • リモートリポジトリ
    • git://github.com/hoge/hoge.git
    • master以外は無いモノとする
  • 作業用ディレクトリ
    • hoge

1. Gitリポジトリから最新を取ってくる

cd hoge
git clone git://github.com/hoge/hoge.git

まずはプロジェクトを取ってこない事には始まらないので、ここから。
GitHubとかGitLabに上がってるプロジェクトをcloneで持ってきます。

2. ブランチを切る

git branch hoge
git checkout hoge

何故ブランチ切るのか

敷かれたレールじゃなくて、自分だけのレールがあればそっちに行きたいですよね。
自分だけのレールに、良いモノがあれば合併すればいいし、良いモノがなければ廃線にすればいいし。
ブランチってのはそういう事です。

真面目に言うと、

  • クローンしてきたままだと、ブランチがmasterになっているから
    • ブランチを指定してcloneすればいいじゃん。というツッコミは無視。
    • masterのまま作業してしまうと、以下のような事が起こる可能性があるので、散々な目に遭うし、恥ずかしい。
      • 競合(conflict)が発生してしまう
      • ビルドが通らないのにmasterに取り込まれてしまう

という事で、cloneしてきたら、とりあえずブランチを切りましょう!!!

3. 作業する

ここは何も気にせず作業してOKです。(追加するなり、編集するなり、削除するなり)
何故なら自分のレールだから。
ここでmasterのまま作業してると、前述したみたいな散々な目に遭って恥ずかしい事になる。

4. コミットする

git add .
git commit -m "気の利いたイケてるコメント."

addで、作業用ディレクトリからステージングエリアに上げて、
commitで、ステージングエリアからGitリポジトリに上げます。
( 参考⇒作業ディレクトリ→ステージングエリア→Gitディレクトリへの一連の上げ方 )

ここまで来れば、もうちょっとです!!!

5. プルリクないしマージリクエストを送る

git push origin hoge

「pull request」と「merge request」の違いはここを参照。⇒ Pull Request / Merge Request の違い

  • GitHubの場合は、これでOK
    • お疲れ様でした。
  • GitLabの場合は、もう一踏ん張り。
    • コマンド実行後、管理画面からmerge requestを投げる必要があります。

おさらい

# 作業ディレクトリに移動して、対象のプロジェクトをclone
cd hoge
git clone git://github.com/hoge/hoge.git

# とりあえずさっさとブランチ切っちゃう
git branch hoge
git checkout hoge

# 作業が終わったら、add→commit
git add .
git commit -m "気の利いたイケてるコメント."

# リクエスト投げて終了(GitLabの場合は管理画面でもう少し頑張る)
git push origin hoge

コマンドベースでおさらいした方が、分かりやすかったりする事もあるので、重複になるけど一応。





これで、masterに影響なくコミット出来る!!!
自分だけのレールだから、廃線にしたって痛くも痒くもない!
見当違いな事してたら恥ずかしいけど気にしなければOK!!!


これでもう辛くない!!!!!!!



【追記 2017/02/20】Gitホスティングサービスについて

「Gitと、GitHubと、GitLabって何が違うんだろう」
と、寝ぼけた事を言ってた大馬鹿者です。こんにちは。

Gitホスティングサービス5選【比較表付き】

Gitというバージョン管理システムがあって、
それをホスティングして利用できるサービスがいくつかありますよ。
という事でした。

  • GitHub
  • GitLab
  • BitBacket
  • Assembla
  • Phabricator

【追記 2017/02/20】Gitを用いた開発フローについて

「GitLabFlowを使って開発するよ」
と言われてポカーンとしていた大馬鹿者です。こんにちは。

Git利用時のフローはどれを使うか

Git Flowなるものがあって、
それを改善するために、GitHub Flowが出来、
更に改善するために、GitLab Flowが出来たとの事。

  • Git Flow
  • GitHub Flow
  • GitLab Flow

【追記 2017/02/21】毎回Username/Passwordを聞かれる問題

git://github.com/...じゃなくて、https://github.com/...で取得してきて、
秘密鍵/公開鍵の設定してなかったりすると、
毎回毎回 Username / Passwordを聞かれてウザったい...

って事で、Usernameはデフォルトで設定しておいて、Passwordのみ聞かれるようにしておく。

.git/config
// ローカルリポジトリの直下に .git というディレクトリがあって、
// その中に config というファイルがあるので、それを開く。

  (・・・省略・・・)

[remote "origin"]
  url = https://username@github.com/hoge/hoge.git
                ~~~~~~~~
                  ↑ここにUsernameを入れる
  (・・・省略・・・)

【追記 2017/02/23】ブランチで作業中、masterで変更があった場合

僕「作業ブランチで開発中。るんるん。」
先輩「masterに重要な変更入ったから取り込んどいて」
僕「・・・・・ん???」

作業ブランチで追加/編集/削除したファイルをメモしておいて、
masterで上書きして、
さっきメモったやつを取り込むとかしなきゃいけない???
えっ、ちょっと、面倒臭い。

何てことはしなくていいです。

#作業ブランチで以下のコマンドを叩く
git merge master

これでOK。

【追記 2017/03/03】面倒臭いからリモートをローカルに上書きしてやる

って事あるよね。
「インデントとか改行とかスペースが変わっただけでリモートと合わない...コミットするのも面倒臭い.....」みたいな。
僕だけかな。

git fetch origin
git reset --hard origin/master

これでローカルは綺麗になりました。
ゼロベースからのスタート。
気持ちいい。