- 投稿日:2021-01-21T22:03:47+09:00
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 add
→gitcommit
をするコンフリクトを起こさない方法(防止策)
・複数人で同じファイルを変更しない
・pullやmergeする前に変更中の状態をなくしておく(commitやstashをしておく)
・pullするときは、pullするブランチに移動してからpullする
- 投稿日:2021-01-21T16:38:10+09:00
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 cleancommitしていないから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 f6cb583b7649358e7b23347eb037c72275590de8f6cb583b7649358e7b23347eb037c72275590de8があった.なので,
$vi .git/lost-found/other/f6cb583b7649358e7b23347eb037c72275590de8で消えたファイルを開いてコピぺして戻した.
- 投稿日:2021-01-21T15:19:40+09:00
サブフォルダにGitコマンドを実行する
for d in . ; do (cd "$d" && git pull && git fetch --prune); done
- 投稿日:2021-01-21T12:59:26+09:00
雰囲気で使っていたgitをちゃんと学んでみる
何の記事?
Git: もう怖くないGit!チーム開発で必要なGitを完全マスターを一通りやってみた感想を書きたいと思います。
筆者のレベル
一通りgit,GitHubを使ったことはあり、言われたことは調べながらなら出来るが、margeとrebaseってどっちがどうメリットがあるんだっけ?みたいな感じです。
何が学べるか?
gitの使い方はもちろん
* gitをなぜ使うか
* gitでファイルのバージョンを管理すると何が嬉しいのか
* gitの歴史
* GitHubってなに?
ってところから解説してくれるので本当にgitについて何も分からない人が初めて学ぼう!って時に非常に有用な講座だと思います。
それでも不安という方はGit:はじめてのGitとGitHubという講座を先にやると良い旨が書かれているのでそちらをやってみることをお勧めします。gitがどのようにファイルを保存しているかなど、gitを使うだけではなく中でどうなっているかも詳しく解説されているのでgitの使い方自体は分かるよって人にも学びがある講座かと思います。
一通りやってみた感想
gitのデータ構造がどうなっているかを通して理解を深めるように組み立てられているところが素晴らしいと思いました。
ステージに追加する時にgit addを叩いた際裏側では何が起きているかなどをイメージしやすいようにイメージ図とコマンドを対応づけて解説しており厳密には正確ではないところもありますが、イメージを掴むには非常に役立つと思います。
ネット上の多くの記事では「なぜ動くのか・どう動いているのか」ではなく「こうすれば動くよ!・こういう場合はこのコマンドを使うよ!」という内容の記事が多いのでそれらの記事で挫折した方でも別の視点から解説されたこの講座が理解の助けになるかもしれません。
これまでgitは難しそうで避けていた方、使っているけどなんとなくcommit,push,pullだけしているみたいな方は是非この講座をやってみることをお勧めします。
- 投稿日:2021-01-21T12:36:26+09:00
[備忘メモ] 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 するのが面倒なときは上記で行ける。
- 投稿日:2021-01-21T11:20:59+09:00
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.
(ざっくり訳)
メールを公開するコマンドラインプッシュをブロックする
プライベートメールを作成者のメールとして使用しているコミットをプッシュすると、プッシュをブロックし、プライベートメールを公開することを警告します。
対応 : 違うメールアドレスを設定してやり直す
# 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