LoginSignup
21

More than 5 years have passed since last update.

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

Last updated at Posted at 2017-02-17

あれから数日...

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

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

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
21