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

GitHubにファイル上げるために必要なコマンド

Gitとは

簡単に言うと、バージョンを管理するアプリです。
なにかのソフトのバージョンを1.0から1.1にアップデートしたときに、なんか重たいなとか思ったときにすぐに1.0に戻すことができるものというふうに理解していればいいかなと思います。

バージョンを管理するものなんだと、現状で理解していればいいかと。

必要なコマンド

はじめは、Githubにプッシュするまでに必要なコマンドについて話します。

  • 必要なコマンド
    • git add
    • git commit
    • git push

基本的にこの3つのコマンドがあれば、GitHubにファイルをプッシュすることができます。

 実際に具体的な使い方について

 git add

git add は名前の通り追加すること

 git commit

セーブみたいなものとおぼえていたらいいでしょう。
よく例に挙げられるのはRPGゲームのセーブという例を上げる人が多いかと感じます。
なので今回もRPGのゲームのようなものという認識で捉えれてもられば良いでしょう。

 git push

このコマンドを打って初めて、GitHubの保存先に自分が作ったファイルが保存されます。

簡単な説明でしたが実際にコマンドを打つのが一番理解できるので、やって見ましょう。

 手順

前提条件

  • ファイル名
    • sample.html
  • gitバージョン
    • git version 2.21.1 (Apple Git-122.3)
  • OS
    • iOS

では早速やって行きましょう

まずはじめに、addして追加

git add sample.html

次にコミットします。

git commit -m "first commit"
//これは一番はじめにコミットするときのおまじないのようなもの

git commit -m 変更内容
// 二回目以降は変更内容を記入するのが一般的
// " "はなくてもしっかりコミットできるので、自分は省略する。
git push origin master
// これでGitHubにファイルが送られる

以上のような流れで、GitHubにファイルを保存することができます。

私も駆け出しエンジニアですが、これからエンジニアになる方は
GitHub、Gitを使えるようになっておいたほうがいいかと思います!

最後までありがとうございました。

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

【PHP】コミット時に自動でコード整形、静的解析する

目的

git commit 時に自動でコード整形、静的解析をさせる。

使用ツール

コード整形:PHP-CS-Fixer
コード整形ルール:php-cs-fixer-rules
コード静的解析:phpstan
コード静的解析:phpmd

やってみる

ツールのインストール

composer require --dev friendsofphp/php-cs-fixer
composer require --dev suin/php-cs-fixer-rules
composer require --dev phpstan/phpstan
composer require --dev phpmd/phpmd
composer update

コード整形設定ファイルを書く

vi .php_cs.dist
<?php
    return PhpCsFixer\Config::create()
        ->setRiskyAllowed(true)
        ->setRules(Suin\PhpCsFixer\Rules::create([
            'declare_strict_types' => false,
        ]))
        ->setFinder(PhpCsFixer\Finder::create()
        ->exclude('vendor')
        ->in(__DIR__)
    );

コード静的解析設定ファイルを書く

vi phpmd_ruleset.xml
<?xml version="1.0"?>
    <ruleset
        name="My first PHPMD rule set"
        xmlns="http://pmd.sf.net/ruleset/1.0.0"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://pmd.sf.net/ruleset/1.0.0 http://pmd.sf.net/ruleset_xml_schema.xsd"
        xsi:noNamespaceSchemaLocation="http://pmd.sf.net/ruleset_xml_schema.xsd"
    >
        <description>
            My custom rule set that checks my code...
        </description>

        <rule ref="rulesets/codesize.xml" />
        <rule ref="rulesets/cleancode.xml" />
        <rule ref="rulesets/controversial.xml" />
        <rule ref="rulesets/design.xml" />
        <rule ref="rulesets/naming.xml" />
        <rule ref="rulesets/unusedcode.xml" />
    </ruleset>

コミット時に上記ツールを自動で呼び出すよう設定

vi .git/hooks/pre-commit
if git rev-parse --verify HEAD >/dev/null 2>&1
then
    against=HEAD
else
    # Initial commit: diff against an empty tree object
    against=$(git hash-object -t tree /dev/null)
fi

# Redirect output to stderr.
exec 1>&2

IS_ERROR=0

for FILE in `git diff-index --name-status $against -- | grep -E '^[AUM].*\.php$'| cut -c3-`; do
    if php -l $FILE; then
        # PHPコード整形
        vendor/bin/php-cs-fixer fix $FILE

        # PHPコード静的解析
        if ! vendor/bin/phpstan analyse $FILE; then
            IS_ERROR=1
        fi

        # PHPコード静的解析
        if ! vendor/bin/phpmd $FILE text phpmd_ruleset.xml; then
            IS_ERROR=1
        fi
    else
        IS_ERROR=1
    fi
done

exit $IS_ERROR

おしまい

git commit 時に自動でコード整形、静的解析を行うようになりました。
行いたくない場合は git commit に --no-verify をつければOK。

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

Git初心者向けGitHubの流れ

Gitの基本事項をGitHubで使用する流れの備忘録

リポジトリを作る

masterブランチが作成されるスクリーンショット 2020-07-09 午後6.43.26.png

ブランチを切る(今回はtestブランチとする)
masterブランチの内容が複製されたtestブランチが作られる(リモート側で作られる)
リモートで作成完了したtestブランチをローカルにpullする。
testブランチでファイルの内容を修正する(ローカルでの作業)
testブランチでadd→commitする(ここまではローカルでの作業)
testブランチでpushする→pushするとローカルの内容がリモートリポジトリのtestブランチに反映される。

プルリクエストについて

testブランチで修正した内容をmasterブランチにマージ(統合)したい場合、プルリクエストが必要
testブランチ→masterブランチへプルリクエストを出す
GitHub上のpull requestsタブを選択しマージする
masterブランチへtestブランチでの修正を反映することが出来る。
マージを間違えた時は「revert」ボタンで取り消し可能

コンフリクトについて

自分の変更をプルリクエストしようとしたら、変更されていて自動ではマージ出来ない時

コンフリクトの例)

スクリーンショット 2020-07-09 午後6.38.32.png

GitKrakenを使用。

画像の説明
リポジトリ名(conflict-test)にtest.htmlを作成
test.htmlファイルの入ったdevelopブランチを作成

test.html(developブランチ)

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>Document</title>
</head>
<body>
  <h1>タイトル</h1>
  <h2>サブタイトル</h2>
  <h3>内容</h3>
</body>
</html>

developブランチからfeatブランチを作成し以下の内容に修正

test.html(featブランチ)

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>Document</title>
</head>
<body>
  <h1>タイトル</h1>
  <h2>サブちゃん</h2>//ここを修正した
  <h3>姉ちゃん</h3>//ここを修正した
</body>
</html>

そしてfeatブランチの内容をadd , commit , pushする

developブランチも内容を修正しpushする
今回はサブタイトルの部分をh2タグ→h3へ変更する

 <h1>タイトル</h1>
  <h3>サブタイトル</h3>//ここを修正した
  <h3>内容</h3>

そしてGitHub上でプルリクエストを
feat→developで実行
すると、、コンフリクト発生!

スクリーンショット 2020-07-09 午後7.44.12.png

Resolve conflictsを選択
スクリーンショット 2020-07-09 午後7.45.01.png

変更箇所が

  <h1>タイトル</h1>
<<<<<<< feat
  <h2>サブちゃん</h2>
  <h3>姉ちゃん</h3>
=======
  <h3>サブタイトル</h3>
  <h3>内容</h3>
>>>>>>> develop

このように表示される
上がプルリクエスト元のfeatの記述
下がプルリクエスト先のdevelopの記述
<<<<<< >>>>>>>
で囲われた部分がコンフリクト部分なので、ここを任意の内容に修正して解決する
今回はh2タグをサブちゃん(元はfeatブランチ)とh3タグは内容(元はdevelopブランチ)にして編集する

スクリーンショット 2020-07-09 午後7.49.14.png

このように画面上で不要な文字を削除し、修正を完了→Mark as resolvedを選択
スクリーンショット 2020-07-09 午後7.50.50.png
commit margeを選択

スクリーンショット 2020-07-09 午後7.51.04.png
Merge pull requestを選択

スクリーンショット 2020-07-09 午後7.51.45.png
任意でコメントを書き(今回は:サブタイトルをサブちゃんにしたと記述)Confirm mergeを選択
スクリーンショット 2020-07-09 午後7.51.53.png
コンフリクトが解消された。

補足:Delete branchを押すと今回のマージ元のfeatブランチを削除することが可能(削除してもその後同じ場所に出てくるRestor branchを選択すると復元可能)
但し、ローカルブランチのfeatは残ったままなので注意。

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

Android StudioでGithub上のプロジェクトをCloneする

今回初めてAndroid用のGitHubにあがっているプロジェクトをローカルに落とす必要があったので
自身の備忘録として残しておきます:bow:

環境

Android Studio Version4.4.0
Mac OS Catalina

対象のGitHubリポジトリを開く

Codeボタンを押下すると、"Clone with SSH"というメニューが出てくるので赤線の箇所をコピー
スクリーンショット 2020-07-09 19.14.47.png

Android Studioを開く

Get Version Controlを押下
スクリーンショット 2020-07-09 19.27.22.png
すると下記画面に遷移するので
URL:GitHubでコピーしたものをコピペ
Directory:Clone先のディレクトリを指定
問題なければ右下のCloneを押下
スクリーンショット 2020-07-09 19.31.15.png

最後にGitHubのssh接続のパスワードを入力して完了!
スクリーンショット 2020-07-09 19.30.06.png

最後に

最近Androidの勉強をはじめました・・・!
ぼちぼちAndroid/Kotlinに関する記事を書いていければなぁと思ってます:relaxed:

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

初学者用これだけは覚えておきたい gitコマンドまとめ

プログラミング初学者が、アウトプットのため気まぐれ更新。
アドバイス等あればご教示頂きたく、よろしくお願い致します。

今回は、最近使い始めたgitコマンドを備忘録的にまとめます。

基本のコマンド

git branch

存在するgit branchを取得することができる
現在いるbranch名が米印・緑色で表示される

git add -A

全てのデータがステージングされる。

git commit -m "メッセージ"

ステージングされた変更をコミット(確定)する。
ダブルクォーテーションの中には、任意のメッセージを入れることができる

git push origin branch名

ブランチ名を指定して、リモートブランチへpushする

git pull origin branch名

指定したブランチをリモートからローカルへ保存する

ブランチ系の処理

git checkout branch名

指定したブランチから抜ける

git checkout -b '新しいブランチ名' '元々のブランチ名'

今いるブランチから、抜けて、新しいブランチを設置する

マージ系

git merge branch名

マージ先のブランチに所在を移しておく。

デンジャー系

git branch --delete branch名

ローカルのbranchを削除する。
ローカルのbranchが削除されるだけで、リモートには存在する


初学者のため、認識違い等あれば、ご指摘頂きたく。

gitの尊さを実感しています。
随時更新予定。

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

Git ブランチ 管理コマンド

これは 個人の 勉強記事です

Git ブランチ管理コマンド

新ブランチ作成、現在のブランチの表示

ファイル操作で言うとmkdir, ls

参考
git コマンド branchの作り方

ローカルのリポジトリで

git checkout -b <branchName>

で作成する
(-bをつけなければ生成されないので、通常の移動先に存在しないブランチを指定したときにうっかり作成されることはない。)

git checkout -b hoge
Switched to a new branch 'hoge'

git branch -a
* hoge
  master
  remotes/origin/HEAD -> origin/master
  remotes/origin/master

これで今コマンドで作成したブランチ無事に作成できていて
私は今そのブランチにいることがわかる.

なお、リモート (GitHub など) でブランチを作成することもできるが

image.png

この場合はlocalでgit fetchしないと反映されない。
そもそもリモートで編集してその変更をローカルで取り込む (fetch) のは今のチームでは非推奨となっている。

ブランチ移動

ファイル操作で言うと cd

参考
【 git checkout 】コマンド(基礎編)――ワークツリーを特定のブランチやコミットに切り替える

https://qiita.com/sunstripe2011/items/53ae4184d021e927b3
(https://qiita.com/sunstripe2011 さんの削除された記事)

ブランチを移動する場合は

git checkout <branchname>

で移動できる。

git branch -a
* 20200701-report
  hoge
  master
  remotes/origin/20200702-daily-reoprt
  remotes/origin/HEAD -> origin/master
  remotes/origin/hoge
  remotes/origin/master

現在 20200701-report, hoge, master, のブランチがあるなか
20200701-report にいるのを確認して

git checkout hoge
Switched to branch 'hoge'
Your branch is up to date with 'origin/hoge'.
git branch -a
  20200701-report
* hoge
  master
  remotes/origin/20200702-daily-reoprt
  remotes/origin/HEAD -> origin/master
  remotes/origin/hoge
  remotes/origin/master

hoge ブランチに移動。
もう一度 現在地を確認すると、hoge ブランチにいることが再確認できた。

こうして、
20200701-report のブランチにいる状態から
git checkout hoge を使うことで
hoge のブランチに移動できることが確認できた


ブランチの削除

ファイル操作で言うと rm -f

参考
How can I delete branches in Git?

ローカルのブランチを削除したい場合は

git branch -d <branchName>

で削除することができる。

git branch
  20200707-daily-report
* 20200708-daily-report
  hoge
  master

現在 20200708-daily-report ブランチにいることを確認。
hoge はテスト用のブランチなので削除したい。

git branch -d hoge
Deleted branch hoge (was 043aab3).

これで ブランチ hoge が削除できた。
削除したブランチの16進数の id も確認できる

git はコミットもブランチも16進数の id がついている

git branch -d test0709
error: Cannot delete branch 'test0709' checked out at '/your/directory/kaede0902-daily-report'

なお、今いるブランチは そこから checkout しないと削除できない。
ホテルに人が泊まって(check in して)いたら解体出来ないみたいなことだ。

git branch -d test0709
error: The branch 'test0709' is not fully merged.
If you are sure you want to delete it, run 'git branch -D test0709'.

また、リモートで PR が pending で merge されていない段階で、ローカルのブランチを削除しようとすると警告が出る。

GitHub (リモート)側のブランチの削除

参考
復習 Git: GitHub のブランチを削除する.

CLIでやるのは非常に大変そうだ。

参考
Creating and deleting branches within your repository

しかしGitHubでなら簡単だった。

ブランチの名前が2020... レ「オ」ポートに typo されているから削除する

view all repositoriesのリンクからこれを

Screen Shot 2020-07-03 at 17.23.57.png

こうじゃ!!!

Screen Shot 2020-07-03 at 17.24.08.png

しかもゴミ箱ボタン押してしばらくは restore ができる新設設計.GitHub 愛してます!!

実践例: git による日報ワークフロー

前提

現在、私は練習のために日報を毎日 git コマンドを使って GitHub の日付ごとのブランチに日報を提出することにしています。

ここまでに学んだ git の使い方の実践例として、git を使った私の毎日の日報提出のワークフローをまとめて、
実際にそのフローで上記のコマンドがどう使われているかを紹介しようと思います。

ローカルの master からその日の日報用のブランチを作るところから解説します。
日付は仮に 2020/07/02 として進めます。日報の内容には触れません。

現在地確認

git branch

で 現在のブランチを確認

リモートの master と ローカルの master の一致

git pull origin master

リモート の master を pull ( fetch & merge) してローカルの master をリモートの master の状態と一致させる

git pull --rebaseをpushする前にやろうという話。

--rebase をつけるべきとの意見もある。

今日の日報のブランチの作成、記入。

git checkout -b 202000702-daily-report

ローカルの master から日報用のブランチを作る

git checkout -b 20200702-daily-report
Switched to a new branch '20200702-daily-report'

作成されて移動できた。

ここで 2020/07/02.md に日報を記入。

ステージングとコミット

git add .

master から作った枝だから、今作ったもの以外は 入ることがない

git commit

ステージングした日報ファイルを現在のブランチに commit。
正確には この後 vim が開いてコミットメッセージを書く。
この一行目が PR のタイトル
二行目が PR の本文 に反映される(後からも変えられる)

git commit
On branch 20200702-daily-report
nothing to commit, working tree clean

( branch名を教えてくれる)
この日報用ブランチを GitHub に push

ローカルで今自分が checkout しているブランチが hoge なのであれば、

git push origin hoge

origin master への直接 push は原則禁止です。

origin に今の commit を新しいブランチごと提出すると

git push origin 20200702-daily-report
Enumerating objects: 4, done.
Counting objects: 100% (4/4), done.
Delta compression using up to 12 threads
Compressing objects: 100% (2/2), done.
Writing objects: 100% (2/2), 373 bytes | 373.00 KiB/s, done.
Total 2 (delta 0), reused 0 (delta 0)
remote: 
remote: Create a pull request for '20200702-daily-report' on GitHub by visiting:
remote:      https://github.com/your-repository/pull/new/20200702-daily-report
remote: 
To github.com:/your-repository/kaede0902-daily-report.git
 * [new branch]      20200702-daily-report -> 20200702-daily-report

こうなる。「origin (リモートのこと)に送信したから GitHub から PR 出してね」と教えてくれる。

PR (Pull Request)

Screen Shot 2020-07-03 at 18.51.25.png

これで今 (6 minutes ago) に origin に push したブランチである 20200702-report が確認できたので

compare & pull request する

image.png

ここで コミットメッセージがタイトル、本文に反映されるので、それと PR のタイトル本文を変えたい場合はここで変更する。

現在のチームではこの書き方になっています。この後にレビュワーを指定し、メンションしてレビューをお願いします。

PR を出した後の commit の修正

自分で間違いに気付いたり、レビュワーさんにもらったコメントから出した PR の commit の修正をする場合

単純にそのブランチで作業して commit してpush すれば OK
ただ、history から commit 自体を減らしたいなら PR したブランチをローカルに pull して rebase して push -f しなければならない。とても大変なので注意。

(Git コミット管理コマンドの記事で解説します)

以上です。

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

リモートリポジトリのURLを変更する

目的

  • 現在のリモートリポジトリではない別のリモートリポジトリにpushする方法をまとめる

調査

  • 下記コマンドを実行してみて$ git remoteコマンドの使用方法を読んでみる。

    $ git remote --help
    
  • 今回の用途に合ったオプションを発見した。下記に先のコマンドの結果を抜粋した物を記載する。

    SYNOPSIS
       git remote [-v | --verbose]
       git remote add [-t <branch>] [-m <master>] [-f] [--[no-]tags] [--mirror=<fetch|push>] <name> <url>
       git remote rename <old> <new>
       git remote remove <name>
       git remote set-head <name> (-a | --auto | -d | --delete | <branch>)
       git remote set-branches [--add] <name> <branch>...
       git remote get-url [--push] [--all] <name>
       git remote set-url [--push] <name> <newurl> [<oldurl>]
       git remote set-url --add [--push] <name> <newurl>
       git remote set-url --delete [--push] <name> <url>
       git remote [-v | --verbose] show [-n] <name>...
       git remote prune [-n | --dry-run] <name>...
       git remote [-v | --verbose] update [-p | --prune] [(<group> | <remote>)...]
    ~中略~
    set-url
    Changes URLs for the remote. Sets first URL for remote <name> that matches regex <oldurl> (first URL if no <oldurl> is given) to <newurl>. If <oldurl> doesn't match any URL, an error occurs and
    nothing is changed.
    
    With --push, push URLs are manipulated instead of fetch URLs.
    
    With --add, instead of changing existing URLs, new URL is added.
    
    With --delete, instead of changing existing URLs, all URLs matching regex <url> are deleted for remote <name>. Trying to delete all non-push URLs is an error.
    
    Note that the push URL and the fetch URL, even though they can be set differently, must still refer to the same place. What you pushed to the push URL should be what you would see if you
    immediately fetched from the fetch URL. If you are trying to fetch from one place (e.g. your upstream) and push to another (e.g. your publishing repository), use two separate remotes.
    

確認

  • 下記を実行して既存のリモートリポジトリのURLを確認した。

    $ git remote -v
    
  • 下記を実行して変更後のリモートリポジトリのURLを設定する。

    $ git remote set-url --add originなどのリモートリポジトリの名前 変更後のリモートリポジトリのURL
    
  • 下記を実行して変更後のリモートリポジトリのURLを確認した。

    $ git remote -v
    
  • 筆者の環境ではリモートリポジトリのURLの変更が確認できた。

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

github profile(readme.md)の最新情報まとめ

ここでいうgithub profile(readme)とは、ユーザーのトップページをユーザー自身がカスタマイズできる新機能のこと。現在は無差別テストに当選した人のみプレビューを行える状況です。

この機能のテストに当選している人は、ユーザー名のリポジトリを作成するとき以下のような表示が出るようです。

github profile(readme)を使用するには、githubでユーザー名のリポジトリを作成して、そのルートにreadme.mdを置くとhttps://github.com/$userにその投稿が表示できます。(現在は当選した人のみ、かつプレビューのみ)

これについての情報はこちらに書かれています。

https://dev.to/web/design-github-profile-using-readme-md-8al

twitterでは、github profile(readme)を試してみた人の最新情報が投稿されています。

https://twitter.com/BjarnBronsveld/status/1280847046858215428

https://twitter.com/kerolloz/status/1280892985924820992

https://twitter.com/williamsrabia/status/1280712424962703360

新機能が公開された?

2020/07/09現在、この新機能が公開されているようです。これが全体的なものかどうかはわかりませんが、私のユーザーページをシークレットモードで開いてみたところ、readme.mdは有効になっている模様。

https://github.com/syui

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

【Git】最低限これだけ押さえる!git rebase

最低限押さえておきたいgit rebaseの手順です。

環境

  • OS:Windows10
  • Git:2.23.0
  • 使用ツール:Git Bash

イメージ図

イメージ図は以下の通り。
image.png
親ブランチをベースにgit rebaseすることにより、
①作業ブランチのコミットが親ブランチの最後尾のうしろに移動し、
②コミットハッシュ値が変わります。

手順

名称と手順中の具体値の対応を以下の通りとし、作業ブランチは親ブランチをもとに作成されたものとします。

名称 手順中の具体値
ローカルリポジトリ /c/work/hoge
親ブランチ develop
作業ブランチ feature/hoge_202007

(1) 対象のローカルリポジトリに移動(コマンドプロンプト)

$ cd /c/work/hoge

(2) 作業ブランチのcommit or stash
ワークディレクトリにcommitされていないファイルがない状態にする
①commitの場合

$ git add .
$ git commit -m "コミットメッセージ"

②stashの場合

$ git stash

(3) 親ブランチに切り替える

$ git checkout develop

(4) 親ブランチにリモートリポジトリの内容を反映、最新の状態にする

$ git pull

(5) 作業ブランチに切り替え

$ git checkout feature/hoge_202007

(6) 親ブランチをベースにリベース

$ git rebase develop

(7) コンフリクトが起きた場合は以下のコマンドで対象を確認し、解消する(コンフリクトなしの場合不要)

$ git status

→ both modifiedと表示されるファイルが修正対象(一気に表示されないので、ひとつひとつ解消する&解消できたら、(8)のコマンドを実行する)

(8) コンフリクトが解消できたら、以下のコマンドを順に実行(コンフリクトなしの場合不要)

$ git add .
$ git rebase --continue

(9) リモートリポジトリにプッシュ

$ git push -f

※親ブランチに追加された内容が作業ブランチの途中に割り込む形となるため、fオプションで強制的にプッシュします。

注意点

  • リベース前後で作業ブランチのコミットハッシュ値が変わる(イメージ図参照)。
  • 原則、自身の作業ブランチ以外では実施しないこと。

終わりに

業務用にまとめたものを覚え書きを兼ねて、汎用的な内容に整理しなおしました。
時々必要な作業で、そのたびに手間取るので、、
その解消に。

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

【Git】最低限これだけ押さえる!現場で使えるgit rebaseの流れ

最低限押さえておきたいgit rebaseの流れです。
実際に現場向けに作成した手順を汎用的な内容に整理しなおしました。

環境

  • OS:Windows10
  • Git:2.23.0
  • 使用ツール:Git Bash

使用シーン

  1. 先に親ブランチに取り込まれた変更を作業ブランチにも取り込んで使う
  2. プルリクエスト(マージリクエスト)時のコンフリクト発生→修正からのビルドエラーの回避
  3. ブランチの分岐を減らし、綺麗な状態にする

etc・・・

イメージ図

イメージ図は以下の通り。
image.png
親ブランチをベースにgit rebaseすることにより、
①作業ブランチのコミットが親ブランチの最後尾のうしろに移動し、
②コミットハッシュ値が変わります。

手順

名称と手順中の具体値の対応を以下の通りとし、作業ブランチは親ブランチをもとに作成されたものとします。

名称 手順中の具体値
ローカルリポジトリ /c/work/hoge
親ブランチ develop
作業ブランチ feature/hoge_202007

(1) 対象のローカルリポジトリに移動(コマンドプロンプト)

$ cd /c/work/hoge

(2) 作業ブランチのcommit or stash
ワークディレクトリにcommitされていないファイルがない状態にする
①commitの場合

$ git add .
$ git commit -m "コミットメッセージ"

②stashの場合

$ git stash

(3) 親ブランチに切り替える

$ git checkout develop

(4) 親ブランチにリモートリポジトリの内容を反映、最新の状態にする

$ git pull

(5) 作業ブランチに切り替え

$ git checkout feature/hoge_202007

(6) 親ブランチをベースにリベース

$ git rebase develop

(7) コンフリクトが起きた場合は以下のコマンドで対象を確認し、解消する(コンフリクトなしの場合不要)

$ git status

→ both modifiedと表示されるファイルが修正対象(一気に表示されないので、ひとつひとつ解消する&解消できたら、(8)のコマンドを実行する)

(8) コンフリクトが解消できたら、以下のコマンドを順に実行(コンフリクトなしの場合不要)

$ git add .
$ git rebase --continue

※途中でリベースを取り消す場合は以下のコマンドを実行(変更した内容も取り消される)

$ git rebase --abort

→ 変更の完了した分も元に戻ります。rebaseが完全に完了した場合は使えないので要注意。

(9) リモートリポジトリにプッシュ

$ git push -f

→ 親ブランチに追加された内容が作業ブランチの途中に割り込む形となるため、fオプションで強制的にプッシュします。

注意点

  • リベース前後で作業ブランチのコミットハッシュ値が変わる(イメージ図参照)。
  • 原則、自身の作業ブランチ以外では実施しないこと。

終わりに

時々必要な作業で、そのたびに手間取るので、その対策用にまとめました。
お役に立てれば幸いです。

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