20200516のGitに関する記事は10件です。

プログラミング初心者がGitの使い方をまとめてみた

Gitの使い方を理解仕切れていないので、用語やコマンド等を自分のメモ用として箇条書きスタイルで記録します。

私と同じようなプログラミング未経験者の方にお役立ちできれば幸いです。
(間違い等があればコメントいただけると嬉しいです。)

Gitとは

Gitは一言で言うと、バージョン管理システムを指します
付け足しで、Githubは、Gitの作業を複数人でやりとりできるWebサービスをさします

リポジトリ

ファイルやディレクトリの状態を記録する場所
(ちなみに、ディレクトリはフォルダのこと)

リモートリポジトリ

複数人で共有するためのリポジトリ

ローカルリポジトリ

自分の手元のマシン上にあるリポジトリ

プルリクエスト

チームで開発する際に使う「編集リクエスト」のような機能

commit(コミット)

git commit
ローカルリポジトリにファイルを保存すること

push(プッシュ)

git push
ローカルリポジトリをリモートリポジトリに送信すること
イメージとしてはファイルのアップロードをする感じ

pull(プル)

git pull
リモートリポジトリから、ローカルリポジトリにダウンロードすること

branch(ブランチ)

git branch
同じファイル・ディレクトリを分岐させること。

merge(マージ)

git merge
ブランチさせた後の履歴を合わせること

fetch(フェッチ)

git fetch
リモートリポジトリの更新状態の確認ができる

clone(クローン)

git clone
ダウンロードのような機能
リモートリポジトリを、ローカルリポジトリとして保存

diff(ディフ)

git diff
ファイルの変更内容の確認

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

100日後にエンジニアになるキミ - 57日目 - Git - Gitの使い方3

昨日までのはこちら

100日後にエンジニアになるキミ - 42日目 - クラウド - クラウドサービスについて

100日後にエンジニアになるキミ - 36日目 - データベース - データベースについて

100日後にエンジニアになるキミ - 24日目 - Python - Python言語の基礎1

100日後にエンジニアになるキミ - 18日目 - Javascript - JavaScriptの基礎1

100日後にエンジニアになるキミ - 14日目 - CSS - CSSの基礎1

100日後にエンジニアになるキミ - 6日目 - HTML - HTMLの基礎1

100日後にエンジニアになるキミ - 53日目 - Git - Gitについて

最近の開発ではGitが欠かせません。
本日はGitの使い方の続きです。

昨日の講座はこちら
100日後にエンジニアになるキミ - 56日目 - Git - Gitの使い方2

昨日までのおさらい

ローカルリポジトリを作ってファイルを作成してコミットする。

Githubにアカウントとリモートリポジトリを作って
ローカルリポジトリのファイルをリモートリポジトリにプッシュする。

リモートリポジトリをローカルに複製する

ここまで出来たら残る操作の学習に移りましょう。

ブランチの仕組み(branch)

ソフトウェアの開発では複数のメンバーが同時に機能追加を行ったりバグ修正を行ったりするので
複数のリリースバージョンが存在し、それぞれを保守しなければならないといったこともあります。

並行して行われる複数のバージョン管理を行うためGitにはブランチという機能が備わっています。

ブランチ

ブランチとは作業履歴の流れを分岐して記録していくためのものです。
分岐したブランチは他のブランチの影響を受けないため同じリポジトリ中で
複数の変更を同時に進めていくことができます。

参考:
https://backlog.com/ja/git-tutorial/stepup/01/

分岐したブランチは他のブランチとマージ(合流)することで1つにまとめることが出来ます。

masterブランチ

リポジトリに最初のコミットを行うとGitはmasterという名前のブランチを作成します。
以後のコミットはブランチを切り替えるまでmasterブランチに追加されていきます。

参考:
https://backlog.com/ja/git-tutorial/stepup/01/

作業ブランチを作成する(branch)

最初はmasterブランチしかない状態です。
作業用のブランチを作成するにはbranchコマンドを用います。

git branch ブランチ名

git branch branch1

これで新しく作業ブランチを作成できました。

作業ブランチを確認する(branch)

今作業を行なっているブランチが何処なのかはbranchコマンドで確認することが出来ます。

git branch

git branch

branch1
* master

作業ブランチには*がつきます。

作業ブランチを切り替える(checkout)

作業ブランチを切り替えを行うにはcheckoutコマンドを用います。

先に移動先の作業ブランチを作成しておかないと移動できないので
あらかじめbranchコマンドで作成しておきましょう。

git checkout ブランチ名

git checkout branch1

Switched to branch 'branch1'

作業ブランチが切り替わりました。
これでコミットすると、この作業ブランチにコミットされることになります。

コマンドでオプション-bをつけるとブランチ作成とチェックアウトを同時に行えます。
git checkout -b ブランチ名

git checkout -b branch2

Switched to a new branch 'branch2'

プルリクエストとは(Pull Requests)

プルリクエストは他の開発者に更新を通知する機能です。

プルリクエストGit自身の機能ではなくGitHubが最初に提供した機能で
今では主要なGitホスティングサービスやツールで利用できます。

プルリクエストは次のような機能を提供しています。

・機能追加や改修など作業内容を担当者や関係者に通知
・ソースコードの変更箇所を表示
・ソースコードに関するコミュニケーションの場を提供

プルリクエストは一覧で見ることができるため未完了のプルリクエストを簡単に確認できます。
ソースコードをレビューして最終的にマージされるソースコードの品質を高くできます。

プルリクエストを導入した際の流れは次のとおりです。

1.開発者がGitHubにブランチをプッシュする
2.開発者がブランチからプルリクエストを作成する
3.レビュワーがコードをレビューする
4.ブランチをマージする

参考:
https://backlog.com/ja/git-tutorial/pull-request/03/

プルリクエストを作成する

Githubからプルリクエストを行うには
リポジトリのトップ画面でNew Pull Requestボタンをクリックして作成を開始します。

aaaa.png

リモートリポジトリからプルする(pull)

複数人で作業をするとリモートリポジトリがどんどん更新されていきます。
変更した内容を自分のローカルリポジトリに取り込む必要が出てきます。

リモートリポジトリからローカルリポジトリを更新するにはプルpullという操作を行います。

git pullでは全てのブランチの変更内容を取得し現在作業対象としている
ブランチ(通常はmaster)の変更内容を作業ディレクトリに反映します。

特定のブランチの変更内容だけを取り込みたい場合は
git pull リモートの名前 ブランチの名前
と指定します。

git clone」を実行すると複製元のリモートリポジトリにはoriginという名前が付きます。

デフォルトのブランチは通常masterという名前になっているため
git pull origin masterと実行するとデフォルトブランチだけを更新します。

# リモートリポジトリで変更された内容を全て取得し現在の作業ツリーに反映する
git pull

# デフォルトブランチの変更内容を取り込む
git pull origin master

# 指定したブランチの変更内容を取り込む
git pull リモートの名前 ブランチの名前

他の人の作業更新を聞いたらファイルの更新を行いましょう。
まずは作業ディレクトリに向かいます。

cd 作業ディレクトリ

作業ディレクトリに着いたらpullコマンドを実行します。

git pull origin master

改めてローカルリポジトリのファイルを見てみると更新されているようです。

まとめ

ブランチの仕組みとプルリクエストを使った更新の通知の仕組みを覚えて
開発現場での作業工程がどんな感じになるのかを知っておこう。

君がエンジニアになるまであと43日

作者の情報

乙pyのHP:
http://www.otupy.net/

Youtube:
https://www.youtube.com/channel/UCaT7xpeq8n1G_HcJKKSOXMw

Twitter:
https://twitter.com/otupython

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

gitコマンドまとめ

Gitを始めよう

# ローカルリポジトリの新規作成
 git init

GitHub上にあるプロジェクトから始めよう

#Gitリポジトリのコピーを作成する
 git clone <リポジトリ名>
 git clone <リポジトリ名><プロジェクト名>

変更をステージに追加しよう

#変更をワークツリーからステージへ追加する
#コミットする変更を準備
 git add <ファイル名orディレクトリ名>
 git .

変更を記録しよう

#ステージからリポジトリへ変更を記録する(コミット)
 git commit
 git commit -m <メッセージ>
#メッセージ付きで記録する。エディタが立ち上がる
 git commit -v

現在の変更状況を確認しよう

#現在の変更状況を確認する。ワークツリーとステージの間で変更されたファイル、ステージとワークツリーの間で変更されたファイルを表示する。
 git status

何を変更したのかを確認しよう

#git addする前(ワークツリーとステージの間)の変更差分を確認する
 git diff
 git diff <ファイル名>
#git addした後(ステージとリポジトリの間)の変更差分を確認する
 git diff --staged

変更履歴を確認しよう

#変更履歴を確認する。最新のコミットから順に表示される。
 git log
#1行で表示する
 git log --oneline
#ファイルの変更差分を表示する
 git log -p <ファイル名>
#表示するコミット数を制限する
 git log -n <コミット数>

ファイルの削除を記録しよう

#ファイルごと削除する。リポジトリ、及びワークツリーから削除される。
 git rm <ファイル名>
#ディレクトリごと削除する。リポジトリ、及びワークツリーから削除される。
 git rm -r <ディレクトリ名>
#ワークツリーにはファイルを残したいとき
 git rm --cached <ファイル名>

ファイルの移動を記録しよう

#ファイルの移動を記録する
 git mv <旧ファイル><新ファイル>
#以下のコマンドと同様
mv <旧ファイル名><新ファイル名>
 git rm <旧ファイル名>
 git add <新ファイル名>

GitHubにpushしよう

#リモートリポジトリを新規追加する
 git remote add <ショートカット名> <GitHubのリポジトリのURL>
#リモートリポジトリへ送信する
 git push <リモート名><ブランチ名>
 git push remote master

バージョン管理しないファイルは無視しよう

.gitignoreファイルに指定することで管理しないファイルをGitの管理から外す

変更をもとに戻そう

#ファイルへの変更を取り消す。ワークツリーの状態をステージと同じにする。
 git checkout --<ファイル名>
 git checkout --<ディレクトリ名>
#全変更を取り消す
 git checkout -- .

ステージした変更を取り消そう

#ステージした変更を取り消す。指定した変更をステージから取り出すだけなのでワークツリーには影響しない。
 git reset HEAD <ファイル名>
 git reset HEAD <ディレクトリ名>
#全変更を取り消す
 git reset HEAD .

直前のコミットを取り消そう

#直前のコミットを取り消す。リモートリポジトリにPushしたコミットはやり直してはいけない。
 git commit --amend

リモートの情報を確認しよう

#リモートを表示する
 git remote
#対応するURLを表示する
 git remote -v

リモートから取得しよう(フェッチ編)

#リモートから情報を取得する(フェッチ編)。リモートリポジトリからローカルリポジトリに情報を取得する。
 git fetch <リモート名>
 git fetch origin
#リモートから情報を取得する。ローカルリポジトリからワークツリーに変更を反映する
 git merge

リモートから取得しよう(プル編)

#リモートから情報を取得してマージまでを一度にやる
 git pull <リモート名><ブランチ名>
 git pull origin master
#下記コマンドと同様
 git fetch origin master
 git merge origin/master

リモートの情報を詳しく知ろう

#リモートの詳細情報を表示する
 git remote show <リモート名>
 git remote show origin

リモートを変更、削除しよう

#変更する
 git remote rename <旧リモート名><新リモート名>
 git remote tutorial new_tutorial
#削除する
 git remote rm <リモート名>
 git remote rm new_tutorial

新しいブランチを作成しよう

#ブランチを新規作成する
 git branch <ブランチ名>
 git branch feature
#ブランチの一覧を表示する
 git branch
#リモートリポジトリを含めた全てのブランチの一覧を表示する
 git branch -a

ブランチを切り替えよう

#ブランチを切り替える
 git checkout <既存ブランチ名>
 git checkout feature
#ブランチを新規作成して切り替える
 git checkout -b <新規ブランチ名>
 git checkout -b <新規ブランチ名><派生元ブランチ名>

変更をマージしよう

#変更履歴をマージする
 git merge <ブランチ名>
 git merge <リモート名/ブランチ名>
 git merge origin master

ブランチを変更、削除しよう

#ブランチを変更する
 git branch -m <ブランチ名>
 git branch -m new_branch
#ブランチを削除する。masterにマージされていない変更が残っている場合削除しない。
 git branch -d <ブランチ名>
 git branch -d feature
#強制削除
 git branch -D <ブランチ名>


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

【Git】ブランチの命名規則を調べてたらIssueドリブン開発という存在を知った

はじめに

gitでブランチを切るときに毎回、「ブランチ名どうしようか…」と悩んでいたので、良さげな命名規則がないか調べてみた
その中で、便利そうなIssueドリブン開発というものを知った

本記事では、上記の2点についてまとめる

ブランチの命名規則

ブランチ名 役割 派生元 マージ先
master 公開するものを置くブランチ
develop 開発中のものを置くブランチ master master
release 次にリリースするものを置くブランチ develop develop, master
feature-* 新機能開発中に使うブランチ develop develop
hotfix-* 公開中のもののバグ修正用ブランチ develop develop, master

feature-*hotfix-*は、*には適当な名前をつける

Issueドリブン開発

Issueとは、Github上で作成できる、ToDoリスト的なもの

使い方

  1. Webサイトのメニューバーをハンバーガーメニューに変更したい
  2. Github上で、1の旨を記載したIssueを立てる
    1. マークダウンでコメントを書けるので便利
    2. 画像も載せられるので、こんなメニューにしたい、というイメージ図も載せておける
  3. feature/#12_replace_to_hamburger_menuというブランチを作成
    1. Issueを立てるとそのIssueに番号、例えば#12が割り振られるので、それをブランチ名に含める
  4. 開発進める
  5. 開発完了
  6. Issueに書いた内容のタスクが完了したので、developブランチにマージコミットする
    1. この際、close #12などとコミットメッセージに記述すると、自動的にIssueが閉じられる

Issueを使うメリット

  • Github上でタスク管理できる
  • コミットするとIssueも自動的に閉じることができるのは便利

おわりに

ざっと調べたことを、自分の理解した形でまとめてみた
間違いなどあれば、随時修正していく

参考記事

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

Git&GitHubメモ - SourceTreeインストール

Git&GitHub 備忘① SourceTreeインストール

目的

  • 自分の作った手順書、スクリプトをメンバーに共有(閲覧してもらうレベルで良い)したい
  • 過去使ったことがありますが、かなり忘れていたので丁寧に記録する目的

Gitの特徴

  • バージョン管理システム
  • 何を管理?プログラムだけでなく文書も管理できる
    • プログラム
    • 設計書
    • マニュアル
  • Gitの利用パターン
    • PCのローカルにインストールして使うパターン
    • サーバに入れて共有するパターン
  • GitとGitHubは別物
  • GitHUBはGitサーバのオンラインサービス

必要なツール

  • テキストエディタ
  • Sourcetree
    • Gitの機能を組み込んだアプリケーション。他のアプリケーションとの比較はしてない。GitをGUIで扱うことができるということでなんとなく使ってる

Sourcetreeインストール

  • ウィザードに従うだけですが、微妙に難しいので、細かく記録しておきます。
  • SourceTree公式ページ:https://ja.atlassian.com/software/sourcetree
  • 「Windows 向けダウンロード」をクリック
    img001.png

  • ライセンスに同意し「ダウンロード」
    img002.png

  • ダウンロードしたファイル「SourceTreeSetup-3.1.2.exe」を実行
    img003.png

  • アカウント未登録であれば「Create one for free」をクリックして登録
    img004.png

  • すでに登録済みでしたので「Bitbucket」クリックして進みます。

  • ログインします
    img007.png

img011.png

  • Gitで管理したいのでGitのみチェックを入れて「次へ」 )img012.png

img014.png

  • Preferenceの画面

    • この詳細をすべてのリポジトリに使用する > いったんチェック無効
    • ユーザ名とパスワード
    • 匿名化した使用状況を開発者へ送信して開発に役に立てる設定 >お好みでチェック img015.png
  • SSHキーの取り込みは「いいえ」。後で設定できるため
    img016.png

  • SourceTreeが起動され、インストールが完了しました。
    img017.png

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

Windows + Git + https接続で複数リポジトリ対応方法

環境

・OS:Windows10Pro

背景

httpsでcloneした際に「fatal: repository 'xxx' not found」というエラーが発生。リポジトリはあるので、改めてローカルの設定を確認して対応した際のメモ。
gitの認証情報回りは、PC変えたりすると毎回調べてたりするので、備忘の為メモ

確認

現状、どのような構成になっているか確認してみる。

c:\temp>git config -l --system
http.sslbackend=openssl
http.sslcainfo=C:/tools/Git/mingw64/ssl/certs/ca-bundle.crt
credential.helper=manager

c:\temp>git config -l --global
user.name=xxx
user.email=xxx.com
credential.https://git-codecommit.ap-northeast-1.amazonaws.com/v1/repos/xxx.helper=manager
credential.https://git-codecommit.ap-northeast-1.amazonaws.com/v1/repos/xxx.username=xxx

c:\temp>git config -l --local
fatal: --local can only be used inside a git repository

どうやら、別のリポジトリの認証情報が邪魔している模様。

解決方法

git config globalの設定に下記追加
gitconfig globalの設定ファイル: c:\Users[ユーザー].gitconfig

[credential "%リポジトリURL%"]
    helper = manager
    username = %ユーザー名%
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

【revert】【rebase】git revert か rebaseで特定のコミットでの作業をなかったことに

はじめに

開発を進める中で、あのコミットの作業だけ取り消したいなーという時に使える。
自分の場合は、デバッグする中で行ったprecompileが余計だったのだが、以下の手順でその実行結果が入ったコミットだけなかったことにすることができた。

方法としては2つあり、コミットIDを特定する等の途中までの手順は同じ。

コミットIDの確認など

まずは、git logでなかった事にしたいコミットIDを確認

git log --name-status --oneline

念の為、コミットしたファイルのリストを確認

git log --name-status コミットID

(更に念押し)そのコミットを行う直前との差分を確認

git diff コミットID^..コミットID

ここで、

 ^ は、コミットIDの一つ前を指す記号。

 .. は、例えばa..b とした場合にはaからbまでの差分を表す。

ここまでの確認で、自分の取り消したいコミットの内容が明確に把握でき、問題なければそれぞれ、revertrebaseに進む。

git revert

そのIDを指定してrevert

git revert コミットID

git rebase

git rebase -i [コミットID]^

** **: 

** **:

** **:

** **:

** **:

** **:

参考にさせて頂いた記事

終わりに。

最後まで読んで頂きありがとうございます:bow_tone1:
転職の為、未経験の状態からRailsを学習しております。正しい知識を着実に身に着け、実力のあるエンジニアになりたいと考えています。継続して投稿していく中で、その為のインプットも必然的に増え、成長に繋がるかと考えています。
今現在、初心者だからといって言い訳はできないですが、投稿の内容に間違っているところや、付け加えるべきところが多々あるかと思いますので、ご指摘頂けると幸いです。この記事を読んで下さりありがとうございました。

コマンドでprecompileをしてしまい、
19:30
そのコミットの内容だけ削除したいのですが、
19:31
そういった場合はどういった方法が安全なのでしょうか?

precompileの実行結果だけが一つのコミットに入っている状況であれば、そのコミットを無かったことにすれば大丈夫です。

こちらの方法、
git logでコミット番号を確認し、
git revert コミット番号
19:33
で良いのでしょうか?

GENDOSU(新しいタブが開きます) 19:33
そのやり方でも良いですし
19:33
自分は
たとえば消したいコミットが特定できている場合は
git log --name-status [コミットID]
で一応ファイルのリストを出して
19:34
確認して
git diff [コミットID]^..[コミットID]
差分出して
19:34
問題なければ
19:35
git rebase -i [コミットID]^
して、[コミットID]の行を削除してます

青山(新しいタブが開きます) 19:35
ありがとうございます!
git diff [コミットID]^..[コミットID]
こちらの ^.. はなにを表しているのでしょうか?

GENDOSU(新しいタブが開きます) 19:37
^は、コミットIDの一つ前を指す記号ですね。
19:38
で、..は、a..b とやった場合にはaからbまでの差分を表示します。

青山(新しいタブが開きます) 19:40
git diff [コミットID]^..[コミットID]
で、消したいコミット単体でなにを変更したかわかる、ということですね!
:thumbsup:
1

19:41
それで、
git rebase -i [コミットID]^
で特定のコミットの一つ前まで表示して、
消したいコミットの行を削除する。
19:41
ということですね!
:thumbsup:
1

GENDOSU(新しいタブが開きます) 19:44
rebaseなので、履歴は書き換わってしまう方法ではあります。
19:45
個人的には revertで履歴が残るのはコミットツリーが長くなるからやだなぁと言う感じでrebaseにしてます。

izszzz(新しいタブが開きます) 19:54
precompile実行の際のコミットを取り消す際にprecompile以外のファイルの変更がある場合conflictなどが起こる可能性があるので、その作業量を加味した上でrevertするか判断してください。

青山(新しいタブが開きます) 19:46
rebaseだと履歴の書き換え、
revertだと特定のコミットを打ち消すコミットを作成するため、その履歴が増える。ということですね。
19:47
ありがとうございます!
すぐにrebaseで確認します。

GENDOSU(新しいタブが開きます) 19:54
デメリットがあるとしたら、書き換わるので、戻したい!って思った時に手順がめんどくさくなるのと
失敗すれば戻せなくなる。というのはあります。

青山(新しいタブが開きます) 20:06
コミットツリーの長さについて気にしないのであれば、慣れないうちは、rebaseのほうが安全ではあるのですね。

20:06
今回は一度rebaseの方で確認します!

git revert すると
vimに入るので
:q
で抜ける

スクリーンショット 2020-05-09 10.26.04.png

git log --graph --date=short --decorate=short --pretty=format:'%Cgreen%h %Creset[%cd] %Cred%d %Creset%s'


Revert "precompile実行"
が行われている事を確認

念には念で
git diff [コミットID]^..[コミットID]
でrevertした結果、その前後でファイルが戻っているか確認する。

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

git flowとは

git flowとは

Gitのブランチ構成のルール、及びそのルールを実現するためのツール名です。
構成のルールというと、CSSのSMACSSのようなものですね。

Git flowでは
メインブランチであるmasterdevelop
サポートブランチであるfeaturesreleaseshotfixes
の全5種類のブランチを利用します。

各ブランチの説明

メインブランチ

各メインブランチは、種類ごとに常に1つだけ存在します。

master

本番リリース用のブランチです。

develop

開発用のブランチです。開発時にはこのブランチに対してプルリクエストを出します。

サポートブランチ

サポートブランチは、機能追加やバグの修正などが行われるたびに新たに作成され、不要になったら削除されます。

features

機能追加のためのブランチです。サービス公開前は大体このブランチで作業し、developブランチに対してプルリクエストを出します。ブランチ名はなんでもOK

releases

リリースの前段にあるブランチ。機能追加中で未使用のコードなどを本番に反映させないようにするために必要。

hotfixes

本番環境(masterブランチ)で重大なバグが発生した時に、masterブランチから派生して作成されるブランチです。
修正後、masterブランチとdevelopブランチの両方に取り込まれます。

結局何をすれば良いか

  • 基本はfeatureブランチを作る→developにマージの繰り返し
  • いろいろ要件がある時に他のブランチを使う

参考

Git-flowって何?
【図解】git-flow、GitHub Flowを開発現場で使い始めるためにこれだけは覚えておこう
A successful Git branching model を翻訳しました
Gitを最大限に活用できる「Git flow」で、効率よく開発を進めよう!

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

Gitでコミットしてバージョン管理・バックアップするメモ

Gitコミットして変更履歴を残す。
復元はまだやったことない。
GitHubへのプッシュは別記事。

扱いたいディレクトリへ移動

コミットしたいファイルのあるフォルダへ。

$ ls         下の階層にある、cdで移動できるディレクトリを表示
$ cd ディレクトリ名  移動

git init

初期化。Initialize.
それぞれのフォルダの中に.gitという隠しファイルを作る。
初めてそのファイルをgitで扱う時には必ず行う。
そうじゃなければ飛ばす。

$ git init
Initialized empty Git repository in /Users/ディレクトリの階層ズラズラ/.git/

git add

ファイルを選択。

$ git add ファイル名

選択できたか確認。

 $ git status
On branch master

No commits yet

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
    new file:   index.html

Untracked files:
  (use "git add <file>..." to include in what will be committed)
    ../上の階層のファイル名やディレクトリ名
    同じ階層のaddしてないファイル名やディレクトリ名

選択できてない場合

$ git status
On branch master

No commits yet

Untracked files:
  (use "git add <file>..." to include in what will be committed)
    ../上の階層のファイル名やディレクトリ名
    ./

nothing added to commit but untracked files present (use "git add" to track)

git initできてない場合

$ git status
fatal: not a git repository (or any of the parent directories): .git

git commit

変更内容や何を作ったのかコメントにつけてコミットする。
これで.gitに今のファイルの状態が保存される。

% git commit -m "トップページ作成"                                       
[master (root-commit) b4a0bf4] トップページ作成
 1 file changed, 96 insertions(+)
 create mode 100644 templates/index.html

コミット履歴を確認

commitできてるか確認

$ git log
commit コミットID (HEAD -> master)
Author: 自分の名前 <メールアドレス>
Date:   Sat May 16 01:46:18 2020 +0900

    トップページ作成

.gitのあるディレクトリ内でgit logすることで、今までにコミットした履歴を確認できる。

コミットしたものから復元

参考:[git] 戻したい時よく使っているコマンドまとめ

git logで戻りたいコミットのコミットIDを調べて

$ git reset --hard [コミットid]

直前のコミットに戻る時は

$ git reset HEAD^

resetで戻ったコミット以降のコミットたちは無くなる。

フォルダごとコミットしたけど特定のファイルだけ戻したい時は

$ git checkout [コミットid] [ファイルパス]

GitHubなどのリモート上にプッシュした後ならこうする
参考:Gitでリモートリポジトリを巻き戻す

手順

リモートに今の(間違えた)状態をバックアップしたブランチを作る
git push origin master:master_bak
リモートのmasterを削除し、ローカルを一つ戻し、リモートにプッシュ
git push -f origin HEAD^:master
分解するとこういうことしてるらしい
git push origin :master
git reset HEAD^
git push origin master
これで順調ならバックアップを削除
git push origin :master_bak

addやcommitの後はstatusやlogで確認する習慣を!

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

GitHubのフォークを同期するメモ

GitHubを使ってWebページを共同開発するとき、どんどん更新される上流リポジトリ(元のディレクトリやファイル)を、フォークした自分のGitHub上のリポジトリ、ローカルプロジェクト(自分のPCにクローンしたリポジトリ)に反映させる方法。

改良版作りました。mergeじゃなくてrebace使ってねと言われたら。中身も省略して分かりやすく。
GitHub、作業前・プルリク前にpull-rebaseするメモ

ターミナルを使う。macOS catalina 10.15.4

上流リポジトリを指定

既に指定されている場合はこうなる。

$ git remote -v
origin  https://github.com/自分のユーザー名/リポジトリ名.git (fetch)
origin  https://github.com/自分のユーザー名/リポジトリ名.git (push)
upstream    https://github.com/上流リポジトリのユーザー名/上流リポジトリ名.git (fetch)
upstream    https://github.com/上流リポジトリのユーザー名/上流リポジトリ名.git (push)

upstreamの欄が無い時は指定する。

$ git remote add upstream https://github.com/上流ユーザー名/上流リポジトリ名.git

上流リポジトリから最新版を取ってくる

上流リポジトリから、ブランチと各ブランチのコミットをフェッチします。
フォークを同期する

上流リポジトリのファイルたちを取ってくる。

$ git fetch upstream
remote: Enumerating objects: 67, done.
remote: Counting objects: 100% (67/67), done.
remote: Compressing objects: 100% (21/21), done.
remote: Total 85 (delta 45), reused 65 (delta 45), pack-reused 18
Unpacking objects: 100% (85/85), done.
From https://github.com/上流ユーザー名/上流リポジトリ名
   5494987..ecffc86  master     -> upstream/master

SSLエラーが出る場合は再起動。

$ git fetch upstream
fatal: unable to access 'https://github.com/shataku/gourmet.git/': LibreSSL SSL_connect: SSL_ERROR_SYSCALL in connection to github.com:443 

ローカルmasterブランチに移動

$ git checkout master
Switched to branch 'master'
$ git checkout master
Already on 'master'
Your branch is up to date with 'origin/master'.

取ってきた最新版をローカルに同期してコミット

upstream/master からローカル master ブランチに変更をマージします。 これによって、ローカルの変更を失うことなく、フォークの master ブランチを上流リポジトリと同期します。
フォークを同期する

これでローカルのリポジトリに上流リポジトリの変更が反映されてコミットされる。

$ git merge upstream/master
Updating 533ff83..ecffc86
Fast-forward
 ファイル名と変更点がズラっと書いてある。省略。

このままだとローカルだけしか更新されてない。

fetch+merge=pull

詳しくは改良版へ。GitHub、作業前・プルリク前にpull-rebaseするメモ

$ git pull upstream master

ローカルから自分のGitHub上へプッシュ

特別addしなくても既にcommitされてるみたい。
この通り。

$ git status
On branch master
Your branch is ahead of 'origin/master' by 23 commits.
  (use "git push" to publish your local commits)

nothing to commit, working tree clean

なのでそのまま自分のGitHubにプッシュ。

remote add の設定
 一度でもプルリクしてたらリモートリポジトリも設定してると思う。

$ git remote -v
origin  https://github.com/自分のユーザー名/リポジトリ名.git (fetch)
origin  https://github.com/自分のユーザー名/リポジトリ名.git (push)
upstream    https://github.com/上流リポジトリのユーザー名/上流リポジトリ名.git (fetch)
upstream    https://github.com/上流リポジトリのユーザー名/上流リポジトリ名.git (push)

これでoriginが無い時は下記で設定。
(そんなことあるのか?どういう表記になるんだろうか?)

$ git remote add origin (https://自分のGitHubアドレス)

リモートURLの設定、詳しくはGitHubにプッシュ・プルリクまでのメモ

設定できてればプッシュしてよし

$ git push origin master
Total 0 (delta 0), reused 0 (delta 0)
To https://github.com/ユーザー名/gourmet.git
   533ff83..ecffc86  master -> master

ブラウザでGitHubページ確認して、最新の上流リポジトリと同じ状態になってればよし。
開発する。
そしてプルリク。
GitHubにプッシュ・プルリクまでのメモ

参考

フォークにリモートを設定する
フォークを同期する

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