あれから数日...
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というバージョン管理システムがあって、
それをホスティングして利用できるサービスがいくつかありますよ。という事でした。
- GitHub
- GitLab
- BitBacket
- Assembla
- Phabricator
【追記 2017/02/20】Gitを用いた開発フローについて
「GitLabFlowを使って開発するよ」
と言われてポカーンとしていた大馬鹿者です。こんにちは。
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 というファイルがあるので、それを開く。
(・・・省略・・・)
[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
これでローカルは綺麗になりました。
ゼロベースからのスタート。
気持ちいい。