20210118のGitに関する記事は9件です。

Git 基本コマンド

はじめに

この記事には、Gitを使う際よく使う基本的なコマンドをまとめました。

参考文献

この記事は以下の情報を参考にして執筆しました。

目次

  1. git init - リポジトリを初期化
  2. git status - リポジトリの状態を確認
  3. git add - ステージ領域へファイルを追加
  4. git commit - リポジトリの歴史を記録
  5. git log - コミットログを確認
  6. git diff - 変更差分を確認
  7. git branch - ブランチを一覧表示
  8. git checkout -b - ブランチを作成し、切り替える
  9. git merge - ブランチをマージ
  10. git log --graph - ブランチを視覚的に確認する
  11. git reset - 歴史を戻る
  12. git commit --amend - コミットメッセージを修正
  13. git rebase -i - 歴史を押しつぶして改変
  14. git remote add - リモートリポジトリを登録
  15. git push - リモートリポジトリへ送信
  16. git clone - リモートリポジトリを取得
  17. git pull - 最新のリモートリポジトリブランチを取得

1. git init - リポジトリを初期化

リポジトリを新規に作成するときに使用するコマンド。
initコマンドを実行すると、現在のディレクトリまたは指定したディレクトリに「. git」というリポジトリを構成するディレクトリが作成される。

2. git status - リポジトリの状態を確認

現在の状況を確認するためのコマンド。
具体的にはファイルの追加や修正、addでインデックスに登録など、現在どのような状態かを確認することができる。

3. git add - ステージ領域へファイルを追加

Gitのaddコマンドは追加されたファイルなどをバージョン管理の対象として追加するコマンド。

4. git commit - リポジトリの歴史を記録

追加・変更したファイルをGitに登録するためのコマンド。
通常のファイル操作では変更した内容を上書き保存すれば、ファイルの内容が変更されるが、Gitのリポジトリに変更内容を登録(保存)するためには、git commitを使用する必要がある。

5. git log - コミットログを確認

リポジトリの中に記録してあるコミット履歴(プログラムの変更履歴)を確認することができるコマンド。

6. git diff - 変更差分を確認

異なるコミットと作業ツリーの比較するコマンド。
オプションにより、インデックス、任意のコミットなど対象を任意に指定できる。

7. git branch - ブランチを一覧表示

ブランチ名の一覧を表示するとともに、現在のブランチを確認するためのコマンド。

8. git checkout -b - ブランチを作成し、切り替える

新しくブランチを作成し、現在のブランチから新しいブランチに切り替えるコマンド。

9. git merge - ブランチをマージ

現在のブランチ(HEADの指している場所)へ、他のブランチの更新を取り込むコマンド。

10. git log --graph - ブランチを視覚的に確認する

コミットログをグラフでわかりやすく表示するコマンド。

11. git reset - 歴史を戻る

Gitでコミットした内容を取り消すためのコマンド。
主にローカルリポジトリに対して行う。

12. git commit --amend - コミットメッセージを修正

直前のコミットメッセージを修正するためのコマンド。

13. git rebase -i - 歴史を押しつぶして改変

ミスがある歴史とその修正の歴史を含めてあたかもミスがなかったように改ざんするコマンド。

14. git remote add - リモートリポジトリを登録

ローカルリポジトリにリモートリポジトリを登録するためのコマンド。

15. git push - リモートリポジトリへ送信

現在のブランチのローカルリポジトリの内容をリモートリポジトリに送信するためのコマンド。

16. git clone - リモートリポジトリを取得

既存のリポジトリをターゲットとして使用するGitコマンドラインユーティリティで、ターゲットリポジトリのクローンまたはコピーを作成するコマンド。

17. git pull - 最新のリモートリポジトリブランチを取得

リモートリポジトリの最新の状態をローカルリポジトリに反映させるためのコマンド。

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

Gitの基本コマンド

はじめに

この記事には、Gitを使う際よく使う基本的なコマンドをまとめました。

参考文献

この記事は以下の情報を参考にして執筆しました。

目次

  1. git init - リポジトリを初期化
  2. git status - リポジトリの状態を確認
  3. git add - ステージ領域へファイルを追加
  4. git commit - リポジトリの歴史を記録
  5. git log - コミットログを確認
  6. git diff - 変更差分を確認
  7. git branch - ブランチを一覧表示
  8. git checkout -b - ブランチを作成し、切り替える
  9. git merge - ブランチをマージ
  10. git log --graph - ブランチを視覚的に確認する
  11. git reset - 歴史を戻る
  12. git commit --amend - コミットメッセージを修正
  13. git rebase -i - 歴史を押しつぶして改変
  14. git remote add - リモートリポジトリを登録
  15. git push - リモートリポジトリへ送信
  16. git clone - リモートリポジトリを取得
  17. git pull - 最新のリモートリポジトリブランチを取得

1. git init - リポジトリを初期化

リポジトリを新規に作成するときに使用するコマンド。
initコマンドを実行すると、現在のディレクトリまたは指定したディレクトリに「. git」というリポジトリを構成するディレクトリが作成される。

2. git status - リポジトリの状態を確認

現在の状況を確認するためのコマンド。
具体的にはファイルの追加や修正、addでインデックスに登録など、現在どのような状態かを確認することができる。

3. git add - ステージ領域へファイルを追加

Gitのaddコマンドは追加されたファイルなどをバージョン管理の対象として追加するコマンド。

4. git commit - リポジトリの歴史を記録

追加・変更したファイルをGitに登録するためのコマンド。
通常のファイル操作では変更した内容を上書き保存すれば、ファイルの内容が変更されるが、Gitのリポジトリに変更内容を登録(保存)するためには、git commitを使用する必要がある。

5. git log - コミットログを確認

リポジトリの中に記録してあるコミット履歴(プログラムの変更履歴)を確認することができるコマンド。

6. git diff - 変更差分を確認

異なるコミットと作業ツリーの比較するコマンド。
オプションにより、インデックス、任意のコミットなど対象を任意に指定できる。

7. git branch - ブランチを一覧表示

ブランチ名の一覧を表示するとともに、現在のブランチを確認するためのコマンド。

8. git checkout -b - ブランチを作成し、切り替える

新しくブランチを作成し、現在のブランチから新しいブランチに切り替えるコマンド。

9. git merge - ブランチをマージ

現在のブランチ(HEADの指している場所)へ、他のブランチの更新を取り込むコマンド。

10. git log --graph - ブランチを視覚的に確認する

コミットログをグラフでわかりやすく表示するコマンド。

11. git reset - 歴史を戻る

Gitでコミットした内容を取り消すためのコマンド。
主にローカルリポジトリに対して行う。

12. git commit --amend - コミットメッセージを修正

直前のコミットメッセージを修正するためのコマンド。

13. git rebase -i - 歴史を押しつぶして改変

ミスがある歴史とその修正の歴史を含めてあたかもミスがなかったように改ざんするコマンド。

14. git remote add - リモートリポジトリを登録

ローカルリポジトリにリモートリポジトリを登録するためのコマンド。

15. git push - リモートリポジトリへ送信

現在のブランチのローカルリポジトリの内容をリモートリポジトリに送信するためのコマンド。

16. git clone - リモートリポジトリを取得

既存のリポジトリをターゲットとして使用するGitコマンドラインユーティリティで、ターゲットリポジトリのクローンまたはコピーを作成するコマンド。

17. git pull - 最新のリモートリポジトリブランチを取得

リモートリポジトリの最新の状態をローカルリポジトリに反映させるためのコマンド。

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

FreeBSD-STABLEをJenkins使って追いかける(Git対応)

FreeBSDのソースがGitへ移行

先日、FreeBSD開発ソースの管理システムがsubversionからgitへ変更になりました。
これを機にJenkinsを使って、毎晩勝手にソースを更新してビルドしておき、いつでも最新にアップデートできるようにしたいと思いたち、これを書いています。

FreeBSDのソースコードリポジトリの確認

詳しい情報は以下からたどっていき、
https://wiki.freebsd.org/git
こちらの方に記載されています。
https://github.com/bsdimp/freebsd-git-docs/blob/main/URLs.md

一通り目は通しておきましょう。
この記事はstable/12ブランチを使いますが、CURRENTやstable/11を参照する場合は上記のURLを参照してください。

Jenkinsの準備

Jenkinsをインストールします。
pkgがお手軽です。

# pkg install jenkins

jenkins自体は本題ではないので、細かいところは省略します。
きっと他にいい記事があると思います(他力本願)。
あと、Gitが使えるようにプラグインを入れておきます。

ジョブを作成する

新規ジョブ作成でフリースタイルのジョブを作成して、以下のように設定します。
リポジトリURL: https://git.freebsd.org/src.git
ブランチ: stable/12
また、ワークスペース直下にソースがあるとこの後面倒なので、Checkout to a sub-directoryを追加してサブディレクトリにソースをチェックアウトします。ここではsrcを指定してます。

jenkins-freebsd-git-1.PNG

さらにビルドのスクリプトとして以下を指定します。

jenkins-freebsd-git-2.PNG

export MAKEOBJDIRPREFIX=${WORKSPACE}/obj
HW_NCPU=$(sysctl -n hw.ncpu)
cd ${WORKSPACE}/src
make -j ${HW_NCPU} clean
make -j ${HW_NCPU} buildworld
make -j ${HW_NCPU} buildkernel

CPUコアをフルに使って並列ビルドしたいので、-jオプションでCPUの数を渡します。
ここではsysctlコマンドを使っています。使っているマシンは4コア8スレッドのタイプなので、ここでは8になりますが、sysctlを使うことで、環境に合わせて自動的に並列数が指定できます。

環境変数MAKEOBJDIRPREXでワークスペースの下にビルドしたオブジェクトの出力先ディレクトリを指定します。

MAKEOBJDIRPREXはmakeのオプションとして指定することもできるのですが、それでやるとビルド途中でエラーになることがあるため、環境変数で指定しました。

ビルド

通常通りJenkinsでビルドを実行します。
時間をおいて何度か実行すると以下のように変更点が見えて便利。

jenkins-freebsd-git-3.PNG

うまくビルドできたら1日1回など適度な間隔で定期実行しましょう。
これでいつでも最新を追えますね。


初めて記事書いてみたけどこれでいいのかな...?


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

新しいPCでgit pushする方法[Windows10]

もともと使用していたPCと違うPC(新しいPC)で開発をしようと思い、調べたところ、結構簡単に設定が出来ました。ただ答えにたどり着くまでに、Git初心者の私はかなり時間を要したので、今後のためにも備忘録としてまとめておきます。

①公開鍵をGitBash上で生成

開発したいディレクトリ状でGitBashを開き、
下記のコマンドを打って、GitBash上で公開鍵を生成します。

$ ssh-keygen -t rsa -b 4096 -f ~/.ssh/[filename]

~ の部分は現在のディレクトリを入力してください。
filenameには自身の好きな名前でOK。
今回は、〇〇(自分の名前)_rsa_github とかにしておきました。

Enterを押すといろいろでてきます。
とりあえずEnterを3回押したら、公開鍵が生成されます。

Generating public/private rsa key pair.
Enter file in which to save the key (/c/Users/PCユーザー名/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /c/Users/PCユーザー名/.ssh/任意のファイル名.
Your public key has been saved in /c/Users/PCユーザー名/.ssh/任意のファイル名.pub.
The key fingerprint is:
フィンガープリント
メールアドレス
The key's randomart image is:
+---[RSA 2048]----+
ランダムアートが表示される
+----[SHA256]-----+

次に、公開鍵が生成されたフォルダに移動します。
先ほどのログに出てきている「/c/Users/PCユーザー名/.ssh/任意のファイル名.pub」が、公開鍵が生成されたフォルダなので、

$ cd /c/Users/PCユーザー名/.ssh/任意のファイル名.pub

とコマンドを打って、ディレクトリを移動。
ちなみに、.pubがついていない方は、公開鍵ではなく秘密鍵です。

次に、下記コマンドを打って、生成した公開鍵をコピーします。

$ pbcopy < ~/.ssh/任意のファイル名.pub

これでOK!

②公開鍵をGitHub上で設定

1.GitHubを開き、「Settings」から「SSH and GPG keys」を開く。
2.「SSH keys」の「New SSH key」をクリックして開く。
3.Titleに名前を付けます。(なんでもOK)
 Keyには、先ほど生成した公開鍵を貼り付けます。
4.「Add SSH Key」をクリック。

鍵のアイコンが出てきたら設定完了です!

③開発したいディレクトリ上でGitBashを開き、git clone

$ git clone リモートリポジトリのURL

問題なくgit cloneできたら、
ダウンロードされたローカルリポジトリの中へ移動します。

④ローカルリポジトリ上でgit remote add

$ git remote add ユーザー名 リモートリポジトリのURL

これで完了です!

あとはいつもどおりgit add→git commit→git pushできるはず!!

参考サイト様

【GitHub】端末がクラッシュ→別PCから開発を再開しようとしたらgit push出来なかったので対処した
[Windows 10] Git BashでGitHubにSSH接続

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

.gitignoreの内容が反映されないときに確認するべきこと

.gitignoreに書いてあるのに反映されない!!

ご存知の通り、.gitignoreファイルに指定したファイルやフォルダは、gitの管理対象外になります。
つまり、いくら変更を加えてもSourceTreeで確認することはできません。
スクリーンショット 2021-01-18 15.37.53.png

しかし、なぜか.gitignoreに書いてある内容が反映されないのです:worried:
書き方が間違ってるわけでもないのに・・・

原因は「リモートリポジトリ」に管理対象外にしたいファイルが残っているから

例えば、下記のような.gitignoreファイルがあったとします。

node_modules
.env
local_properties.json

# editor
.idea/
.vscode/
.settings/
.editorconfig

プロジェクト直下にあるlocal_properties.json.gitignoreファイルに記載があるのに、なぜかgitの管理対象になっています。

なぜか?

リモートリポジトリにlocal_properties.jsonが存在していたため、ローカルでも管理対象になっていたようです。。。

一度gitにアップ(つまりリモートリポジトリにpush)したファイルであるlocal_properties.jsonを、.gitignoreに追加しても追跡され続けていたのが原因でした:disappointed_relieved:

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

【GitHub】Contributionのルール

こんにちは!
今までGitHubのContributionの色の付け方
皆さんご存知ですか?

大前提、ポートフォリオ作ることばっかり考えていて、
GitHubの事全く考えていませんでした。
先日、MENTAの先生から

「GitHub意識して、Pushしときなよー」

って

!?

ちょこちょこ調べながら使ってたけど、
本格的なやらねば!!

そんな思いから記事にしようと思います!

この記事でわかること

1.GitとGitHubの違い
2.Contributionのルール(草生やし方)

1.そもそもGit/GitHubって?

Gitって?
分散型バージョン管理
(バージョンとは更新したり、アップデートした時に変化する[ver.]みたいなの!)
・コンピュータ上でファイルの編集履歴を管理

Gitでできる事
・古いバージョンに間単に戻せる
・新古ファイルの一元管理可
・編集履歴を複数人で共有可
・複数人で修正した部分を1つに統合可

GitHubって?
・Gitの仕組みと連携して、他ユーザーとのやりとりがしやすいWEBサービスの名前

2.Contributionのルール

そもそもContributionとは?
・過去1年間こんだけ活動したよ!を可視化した表
スクリーンショット 2021-01-18 11.03.52.png
(草が生えてなくて恥ずかしいです....)
Contributionとはの英語記事

Contributionを生やすには?
・masterブランチor gh-pageブランチへのコミット
・IssueやPull Requestの新規

草の色を深くするには?
・過去1年間の中で相対的な、数を示してる
参考にさせて頂きました!

アウトプットってすごい、、
一気に定着しますね!!!
Gitの仕組みなど記事にしていくつもりなので、
またご覧いただけると幸いです( ´ ▽ ` )ノ

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

【初心者向け】git checkoutについて

結論

リモート追跡ブランチに移動するコマンドは、'git checkout origin/ブランチ名'
ローカルの作業ブランチに移動するコマンドは、'git checkout ブランチ名'

リモート追跡ブランチはローカルのブランチである。

※リモート追跡ブランチ=トラッキングブランチ

経緯

リモートブランチにcheckoutする際、originとブランチ名の間に'/'が必要か迷う事があった。

git checkoutするコマンドは'/'が必要で、git pushするコマンドは'/'が必要ない。

git checkout origin/ブランチ名
git push origin ブランチ名

この'/'の有無はどういう意味?

疑問

git checkout origin ブランチ名だとリモートブランチにcheckoutできないの?
git push origin/ブランチ名だとリモートブランチにpushできないの?
origin/ブランチ名がくっついているのにorigin/ブランチ名を1つのブランチ名として認識されないの?

この疑問を解決するため、検証を実施します。

検証

'git checkout origin ブランチ名'でcheckoutできるのか

develop/#2の状態からgit checkout origin develop/#1を実行

masahiro@MacBook-Air project % git branch
  develop/#1
* develop/#2
  master
masahiro@MacBook-Air project % git checkout origin develop/#1
error: pathspec 'origin' did not match any file(s) known to git
error: pathspec 'develop/#1' did not match any file(s) known to git

→エラー発生

翻訳すると、
エラー:pathspec'origin'がgitで認識されているファイルと一致しませんでした
エラー:pathspec'develop/#1'はgitに認識されているどのファイルとも一致しませんでした

'git push origin/ブランチ名'でpushできるのか

develop/#1の状態から'git push origin/develop/#1'を実行

masahiro@MacBook-Air project % git branch
* develop/#1
  develop/#2
  master
masahiro@MacBook-Air project % git push origin/develop/#1
fatal: 'origin/develop/#1' does not appear to be a git repository
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

→エラー発生

翻訳すると、
致命的:'origin/develop/#1'はgitリポジトリではないようです
致命的:リモートリポジトリから読み取ることができませんでした

正しいアクセス権があることを確認してください
リポジトリが存在します。

検証結果:①、②ともにエラーが発生し実行できませんでした。

考察

①のエラーでは'origin''develop/#1'がgitにありませんと認識している。
→疑問③の'origin/ブランチ名'を1つのブランチ名として認識されているのでは?

②のエラーでは'origin/develop#1'はリモートリポジトリから読み取れませんでした。
→リモートに存在しないということ?

まだ納得できないので納得できる記事を探しました。

調査結果

下記の記事により納得することができました。

・git checkoutについて→https://www-creators.com/archives/1388#git_checkout
・git fetch,marge,pullについて→https://qiita.com/wann/items/688bc17460a457104d7d
・トラッキングブランチについて→https://yu8mada.com/2018/08/11/how-to-confirm-and-set-up-tracking-branches-in-git/#content-1

まとめ

git の仕様上、作業ブランチをリモートブランチに切り替えて直接更新することはできない。
'origin/ブランチ名'はリモートブランチではなくリモート追跡ブランチであり、
リモート追跡ブランチ(トラッキングブランチ)はローカルブランチであることが分かりました。

git初心者の私は、'git checkout origin/ブランチ名'でリモートブランチに移動していると思っていたが、
リモートブランチではなく、実際はローカルに存在するリモート追跡ブランチでした。

この違いを知っていれば、コマンド実行時に'/'で悩まされなくて済むと思います。
そして今回、トラッキングブランチの存在ついても知る事ができました。
ここの知識も深めていく必要があると感じました。

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

【ダメ。ゼッタイ】脱法ブランチ名やプッシュ乱用を防いでgitを治安維持する

運用規則やgitのベストプラクティスを知っててもmaster直修正しちゃいたい誘惑ってありますよね。ギリギリ踏みとどまっても今度はブランチ命名タスクが来て、次にコミット命名です。このgit運用を手抜きしたい誘惑は凄まじく、依存性もあり一度やってしまうと、もう元の生活には戻れず手抜きが横行します。

そこで、CodeCommitならばIAM絞ってとても柔軟にgit運用の統制を設定でき、社内のgit治安が良くなるという話をします。

Git Flow, Github Flowをベースに少し手を加えた以下の制約を導入したいとします。betaはカナリアリリース用の社内独自ブランチです

  • 作成できるブランチ名の制限。master, beta, feature/*, hotfixのみ。自分の名前のブランチ名とかダメ絶対。
  • master, betaは直コミット禁止し、プルリクのみが更新できる。
  • プルリクのマージはマージコミット残し必須。Fast-Fowardは不可

以下のポリシーをHogeCorporationGitFlowPolicyとでも命名して作成し、全開発者に適用するようアタッチします。元々のCodeCommitへの操作権限を有するユーザーを前提にしています。初めてStringNotLikeを使いました。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": [
        "codecommit:*"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotLike": {
          "codecommit:References": [
            "refs/heads/master",
            "refs/heads/beta",
            "refs/heads/feature/*",
            "refs/heads/hotfix"
          ]
        },
        "Null": {
          "codecommit:References": false
        }
      }
    },
    {
      "Effect": "Deny",
      "Action": [
        "codecommit:GitPush",
        "codecommit:DeleteBranch",
        "codecommit:PutFile",
        "codecommit:CreateCommit",
        "codecommit:MergeBranchesByFastForward",
        "codecommit:MergeBranchesBySquash",
        "codecommit:MergeBranchesByThreeWay",
        "codecommit:MergePullRequestByFastForward",
        "codecommit:MergePullRequestBySquash"
      ],
      "Resource": "*",
      "Condition": {
        "StringEqualsIfExists": {
          "codecommit:References": [
            "refs/heads/master",
            "refs/heads/beta"
          ]
        },
        "Null": {
          "codecommit:References": false
        }
      }
    }
  ]
}

もう少し拘って以下も設定したかったのですが、よく分かりませんでした。導入できたら記事更新します。 (教えて優しい人)

  • masterへのプルリクはfeature系から禁止して、betaかhotfixからのみ可
  • commit名にも命名規則としてprefix必須&ホワイトリスト作成
  • セルフマージ禁止(PRと承認の同一人物禁止)

参考

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

【超凡ミス】git push heroku masterしたら「error: failed to push some refs to 'https://git.heroku.com/******.git'」

はじめに

ある教材のハンズオンをしてたらエラーが出たので記録しておきます。

※結論:超凡ミスでした

実行コマンドとエラー内容

作成したアプリケーションをHerokuにデプロイしようと以下のコマンドを実行すると

$ git push heroku master
error: src refspec master does not match any
error: failed to push some refs to 'https://git.heroku.com/******.git'

のエラーが...

原因と解決方法

GitHubのメインブランチがmasterではなくmainなのでそれに合わせて以下のコマンドが正解でした。

$ git push heroku main

実行結果

Enumerating objects: 779, done.
Counting objects: 100% (779/779), done.
Delta compression using up to 8 threads
Compressing objects: 100% (718/718), done.
Writing objects: 100% (779/779), 7.83 MiB | 426.00 KiB/s, done.
Total 779 (delta 234), reused 0 (delta 0), pack-reused 0
remote: Compressing source files... done.
remote: Building source:
...
(中略)
...
remote:        https://quiz-laravel-vuejs.herokuapp.com/ deployed to Heroku
remote:
remote: Verifying deploy... done.
To https://git.heroku.com/******.git
 * [new branch]      main -> main

無事pushできました。

さいごに

2020年10月5日にGitHubのデフォルトブランチがmasterからmainに変わりました。

それ以前に作成された教材でHerokuにデプロイする時は

$ git push heroku master

になっているので気をつけてください!

GitHub、これから作成するリポジトリのデフォルトブランチ名が「main」に。「master」から「main」へ変更

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