20210121のGitに関する記事は7件です。

Git 【ブランチとマージの操作】

はじめに

学習用のメモになります。

1.ブランチ

ブランチを新規作成

git branch <ブランチ名>
git branch feature

このコマンドはブランチを作成するだけでブランチの切り替えまでは行わないよ。

*HEAD:今いるブランチを示している。

ブランチを切り替える

git checkout <既存ブランチ名>
git checkout feature

#ブランチの新規作成して切り替える
git checkout -b <新しいブランチ名>

-bオプションをつけると、ブランチの作成と切り替えを一度にしてくれます。
ブランチを利用することで分岐して作業ができます。

ブランチの一覧を表示

git branch

#全てのブランチを表示する
git branch -a

ブランチの変更・削除する

#変更する
git branch -m <ブランチ名>
git branch -m new_branch

自分が今作業しているブランチの名前を変更するよ

#削除する
git branch -d <ブランチ名>
git branch -d feature

##強制削除する
git branch -D <ブランチ名>

masterにマージされていない変更が残っている場合削除しない。

ブランチを利用した開発の流れ

masterブランチをリリース用ブランチに、開発はトピックブランチを作成して進めるのが基本。

2.マージ

マージとは、他の人の変更内容を取り込む作業のこと

git merge <ブランチ名>
git merge <リモート名/ブランチ名>
git merge origin/master

作業中のブランチにマージします。

マージの種類

1.Fast Foward

早送りになるマージ
ブランチが枝分かれしてなかったときはブランチのポインタを前に進めるだけ

2.Auto Merge

基本的なマージ
枝分かれして開発していた場合、マージコミットという新しいコミットを作る。
これによって変更履歴を統合する。

3.コンフリクト

コンフリクトはどういった時に起こるのかいうと、同じファイルの同じ行に対して異なる編集を行った時に起こります。

コンフリクトの解決の仕方

#具体例(コンフリクトしたファイル)
<h1>Gitチュートリアル</h1>
<<<<<<<HERD
<p>git addについて学ぼう</p>
=======
<p>git commitを知ろう</p>
>>>>>>>feature

< ==~>>feature:featureの変更分

#解決したファイル
<h1>Gitチュートリアル</h1>
<p>git addについて学ぼう</p>
<p>git commitを知ろう</p>

①ファイルの内容を書き換える
②「<<」 「==」 「>>」の記述を削除する
③再度git addgitcommitをする

コンフリクトを起こさない方法(防止策)

・複数人で同じファイルを変更しない
・pullやmergeする前に変更中の状態をなくしておく(commitやstashをしておく)
・pullするときは、pullするブランチに移動してからpullする

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

git fsck でcommitせずに消えたファイルを救出する

概要

git fsckは,「データベース内のオブジェクトの接続性と有効性を検証する」(参考)

データベースに存在するが,git add したのにgit resetしてしまったなどで消えた宙ぶらりんのオブジェクトをとりだせる.

自分の状況

git: Version 2.30.0 
$ git add .
$ git reset --hard HEAD^

手が滑ってgit addしたのにgit resetしてしまった.
だからコミットできない.

$ git commit -m "hoge"
On branch master
Your branch is up to date with 'gitlab/master'.

nothing to commit, working tree clean

commitしていないからreflog使った救出もできない.

$ git reflog
5b916dc (HEAD -> master, gitlab/master) HEAD@{0}: reset: moving to HEAD^
d060d9a HEAD@{1}: commit: hoge
.
.
.

解決法

git fsckで消えたオブジェクトを見てみる.
--lost-foundのオプションを加えると,
「ぶら下がっているオブジェクトを .git/lost-found/commit/ または .git/lost-found/other/ に書き出します.オブジェクトが blob の場合は、オブジェクト名ではなく中身がファイルに書き込まれます.」(参考)
なるほど.

$ git fsck --lost-found
Checking object directories: 100% (256/256), done.
Checking objects: 100% (77/77), done.
dangling commit 6a18de2e9c91d3357d7471b21a64bf7527d1e66a
dangling commit d060d9a81fe3d99bed3c519b4b41344849c40879
dangling blob 367187e5464b8e6e6faf7d21a702f0db31e6ff75
dangling commit 82997ff88a9542f69adf508066ae54e040478b28
dangling commit bbb9a5b0c0c3bd925fb160f348fa83a1a9dc68b8
dangling commit 555ec3c89716f7ab13f36443767bb4b0bce33bf0
dangling commit 6f0af95012d05fbc38bb8ddb7338bd8b0b240c48
dangling blob b33e342cdfdd49475a8ed114ff965373a851279f
dangling blob c9e63be87b5ff5c776db55708fae89e74ba613ed
dangling blob db425d36d2d0941731250c49e949c76623c3d0e8
dangling blob 6f531c6fbecb40ef9f8035e137075523f240c016
dangling blob f6cb583b7649358e7b23347eb037c72275590de8

中身を見るために一番下のハッシュを次のようにcatしてみる.

$ git cat-file -p f6cb583b7649358e7b23347eb037c72275590de8

出力された内容は,たしかに直前に編集して消えたものだった.
git fsckで出力されるdanglingにおいて,新しい宙ぶらりんのオブジェクト(ハッシュ)は一番下に追加されるようだ.
--lost-foundで書き込まれたファイルを探す.

$ ls .git/lost-found/other/
367187e5464b8e6e6faf7d21a702f0db31e6ff75  b33e342cdfdd49475a8ed114ff965373a851279f  db425d36d2d0941731250c49e949c76623c3d0e8
6f531c6fbecb40ef9f8035e137075523f240c016  c9e63be87b5ff5c776db55708fae89e74ba613ed  f6cb583b7649358e7b23347eb037c72275590de8

f6cb583b7649358e7b23347eb037c72275590de8があった.なので,

$vi .git/lost-found/other/f6cb583b7649358e7b23347eb037c72275590de8

で消えたファイルを開いてコピぺして戻した.

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

サブフォルダにGitコマンドを実行する

for d in . ; do (cd "$d" && git pull && git fetch --prune); done
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

雰囲気で使っていたgitをちゃんと学んでみる

何の記事?

Git: もう怖くないGit!チーム開発で必要なGitを完全マスターを一通りやってみた感想を書きたいと思います。

筆者のレベル

一通りgit,GitHubを使ったことはあり、言われたことは調べながらなら出来るが、margeとrebaseってどっちがどうメリットがあるんだっけ?みたいな感じです。

何が学べるか?

gitの使い方はもちろん
* gitをなぜ使うか
* gitでファイルのバージョンを管理すると何が嬉しいのか
* gitの歴史
* GitHubってなに?
ってところから解説してくれるので本当にgitについて何も分からない人が初めて学ぼう!って時に非常に有用な講座だと思います。
それでも不安という方はGit:はじめてのGitとGitHubという講座を先にやると良い旨が書かれているのでそちらをやってみることをお勧めします。

gitがどのようにファイルを保存しているかなど、gitを使うだけではなく中でどうなっているかも詳しく解説されているのでgitの使い方自体は分かるよって人にも学びがある講座かと思います。

一通りやってみた感想

gitのデータ構造がどうなっているかを通して理解を深めるように組み立てられているところが素晴らしいと思いました。
ステージに追加する時にgit addを叩いた際裏側では何が起きているかなどをイメージしやすいようにイメージ図とコマンドを対応づけて解説しており厳密には正確ではないところもありますが、イメージを掴むには非常に役立つと思います。
スクリーンショット 2021-01-21 12.58.47.png

ネット上の多くの記事では「なぜ動くのか・どう動いているのか」ではなく「こうすれば動くよ!・こういう場合はこのコマンドを使うよ!」という内容の記事が多いのでそれらの記事で挫折した方でも別の視点から解説されたこの講座が理解の助けになるかもしれません。

これまでgitは難しそうで避けていた方、使っているけどなんとなくcommit,push,pullだけしているみたいな方は是非この講座をやってみることをお勧めします。

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

[備忘メモ] GitHub Enterprise などで Proxy 経由で git clone する

git -c "http.proxy=http://111.111.1.111:80" clone https://github.your-enterprise.com/<your-team>/<your-repository>.git
cd <your-repository>
git config --local http.proxy http://111.111.1.111:80
git config --local http.sslVerify false

プロキシ下の GitHub Enterprise などから git clone したい場合、わざわざコンフィグ設定してから clone するのが面倒なときは上記で行ける。

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

push declined due to email privacy restrictions

事象 : GitHubにプッシュして怒られた

  • 環境
    • macOS Big Sur バージョン11.1
    • git version 2.28.0
$ git push
Enumerating objects: 3, done.
Counting objects: 100% (3/3), done.
Delta compression using up to 4 threads
Compressing objects: 100% (2/2), done.
Writing objects: 100% (2/2), 282 bytes | 282.00 KiB/s, done.
Total 2 (delta 1), reused 0 (delta 0)
remote: Resolving deltas: 100% (1/1), completed with 1 local object.
remote: error: GH007: Your push would publish a private email address.
remote: You can make your email public or disable this protection by visiting:
remote: http://github.com/settings/emails
To https://github.com/{ユーザ}/qiita-shitagaki.git
 ! [remote rejected] master -> master (push declined due to email privacy restrictions)
error: failed to push some refs to 'https://{ユーザ}:{トークン}@github.

原因 : 非公開のメールアドレスでのコミットをプッシュしているから

メッセージの訳
電子メールのプライバシー制限によりプッシュが拒否されました

そういえばそんな変更したな・・・

Block command line pushes that expose my email
If you push commits that use a private email as your author email we will block the push and warn you about exposing your private email.
(ざっくり訳)
メールを公開するコマンドラインプッシュをブロックする
プライベートメールを作成者のメールとして使用しているコミットをプッシュすると、プッシュをブロックし、プライベートメールを公開することを警告します。
image.png

対応 : 違うメールアドレスを設定してやり直す

# 1. コミットを取り消す
$ git reset --soft HEAD^

# 2. 非公開にしたのとは違うメールアドレスを設定する
$ git config user.email '{違うメールアドレス}'

# 3. 今一度コミットする
$ git commit -m 'Qiitaに投稿した。'
[master 177393c] Qiitaに投稿した。
 1 file changed, 22 deletions(-)
 delete mode 100644 いろいろなログの場所.md

# 4. プッシュする
$ git push
Enumerating objects: 3, done.
Counting objects: 100% (3/3), done.
Delta compression using up to 4 threads
Compressing objects: 100% (2/2), done.
Writing objects: 100% (2/2), 305 bytes | 152.00 KiB/s, done.
Total 2 (delta 1), reused 0 (delta 0)
remote: Resolving deltas: 100% (1/1), completed with 1 local object.
To https://github.com/{ユーザ}/qiita-shitagaki.git
   d631d06..177393c  master -> master
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Git $ git log の表示の先頭コミットを指定する

目的

  • $ git logコマンドの表示を特定のコミット先頭に表示する方法をメモ的にまとめておく。

方法

  • 下記コマンドを実行して特定のコミットを先頭にコミットログを表示する。

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