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

シチュエーション別Gitコマンド逆引き辞典[Memo]

はじめに

この記事は個人的なメモとして残しておく想定とします。
なので追記や修正はこれからしていく予定です。

ブランチ切って一人で開発

developが更新されてそれを取り込みたい時

「xxxクラス作ってdevelopにマージしときました!皆さん使ってください。」
「ありがとうございます!使います!」
って言って使わせてもらいたい時がありました。
developブランチから自分のブランチに変更を取り込みます。

pull

git pull origin develop

コンフリクトが起これば、解消して、

git add <files>
git commit -m "コンフリクト解消"

コンフリクト解消後に解消コミットする必要があります。
それによってコミット履歴が汚れてしまいます。。。

pull --rebase

git pull --rebase origin develop

developのコミットを取り込んで、その上に今のブランチのコミットを重ねるイメージ。
コンフリクトしたら解消しつつ、

git rebase --continue

またコンフリクトしたら解消とgit rebase --continueを繰り返す。。
コンフリクトを解消してもコミット履歴が汚れることなく全部自分のコミットにまとめることができます。
あたかも最新のdevelopブランチから派生したような見た目になります。

コミット単位小さすぎた時

「これプルリク通ったとしても、コミット粒度小さすぎてdevelopのコミット履歴を汚してしまうな。。。」
「全部1コミットにまとめて、やったことはプルリクのコメントで書けば良いやん!」
となる時がありました。
というわけで、複数コミットをまとめます。

rebase -i

例えばこのようになっていたとします。
紆余曲折あって一部初期化処理を追加*3としてしまった。。。
これら3つのコミットはセットなので1つにまとめます。

$git log
commit 67c6c855922449b9b9b8a06f1f50b1b2b6baa65 (HEAD -> feature/hoge1)  

    <file3>一部初期化処理を追加

commit 2fdc0529b18102fa4fd3dfbc4ae2141c79fd404

    <file2>一部初期化処理を追加

commit 282a1380c153a8fe5cc29e24baca840197de3fc

    <file1>一部初期化処理を追加

commit 2dfb8cd50d099e0c30ba0bd35a858b084abccdc2 (master, develop)

    first commit

HEADから3コミット分をまとめる例です。

git rebase -i HEAD~3

editorが開き、上3行を変更します。

#pick 282a132 <file1>一部初期化処理を追加 -> このコミットメッセージは"初期化処理を追加"に変更
#pick 2fdc052 <file2>一部初期化処理を追加 -> このコミットメッセージいらね
#pick 67c6c85 <file3>一部初期化処理を追加 -> このコミットメッセージもいらね

r 282a132 <file1>一部初期化処理を追加
s 2fdc052 <file2>一部初期化処理を追加
s 67c6c85 <file3>一部初期化処理を追加

# Rebase 2dfb8cd..67c6c85 onto 2dfb8cd (3 commands)
#
# Commands:
# p, pick <commit> = use commit
# r, reword <commit> = use commit, but edit the commit message
# e, edit <commit> = use commit, but stop for amending
# s, squash <commit> = use commit, but meld into previous commit
# f, fixup <commit> = like "squash", but discard this commit's log message
# x, exec <command> = run command (the rest of the line) using shell
# b, break = stop here (continue rebase later with 'git rebase --continue')
# d, drop <commit> = remove commit
# l, label <label> = label current HEAD with a name
# t, reset <label> = reset HEAD to a label
# m, merge [-C <commit> | -c <commit>] <label> [# <oneline>]
# .       create a merge commit using the original merge commit's
# .       message (or the oneline, if no original merge commit was
# .       specified). Use -c <commit> to reword the commit message.
#
# These lines can be re-ordered; they are executed from top to bottom.
#
# If you remove a line here THAT COMMIT WILL BE LOST.
#
# However, if you remove everything, the rebase will be aborted.
#
# Note that empty commits are commented out

r: rewordはコミットメッセージ変更
s: squashはいらないので前のコミットに結合
p:pickはコミットメッセージを残す時に使う
保存&閉じるとまたエディタが開き、今度は一番上のコミットメッセージを編集します。

#<file1>一部初期化処理を追加
初期化処理を追加

# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
#
# Date:      Fri May 15 23:04:15 2020 +0900
#
# interactive rebase in progress; onto 2dfb8cd
# Last command done (1 command done):
#    reword 282a132 初期化処理を追加
# Next commands to do (2 remaining commands):
#    squash 2fdc052 <file2>一部初期化処理を追加
#    squash 67c6c85 <file3>一部初期化処理を追加
# You are currently editing a commit while rebasing branch 'feature/hoge1' on '2dfb8cd'.
#
# Changes to be committed:
#   modified:   file1.kt
#

保存&閉じるとまたエディタが開き、いらないメッセージは消します。

 This is a combination of 3 commits.
# This is the 1st commit message:

初期化処理を追加

# This is the commit message #2:

#<file2>一部初期化処理を追加

# This is the commit message #3:

#<file3>一部初期化処理を追加
...

やっと編集終わって、

$git log
commit 6ab47738e0989664d3f7ade37c6df0c7b2b (HEAD -> feature/hoge1)  

    初期化処理を追加

commit 2dfb8cd50d099e0c30ba0bd35a858b084abccdc2 (master, develop)

    first init

あとは

git push -f origin feature/hoge1

後プルリクしました。

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

【しくじりプログラミング】失敗事例から学ぶGitの正しい使い方

書こうと思ったきっかけ

私がGitを使い始めたときは、様々な誤った使い方をしました。そのせいでよく先輩から指摘を受けました。そして自分が指導する立場になって後輩がGitを使っているのをみていると、やはり同じような失敗をしていました。そこでこれ以上被害者を増やさないためにも、私が失敗した知見をもとに間違った使い方と正しい使い方を書いていきます。

対象者

Git初心者で、とりあえず使い方はわかったぜ!という人。
使い方が不安な人。

なぜGit(バージョン管理システム)を使うのか

後輩から「Gitが面倒くさい。なぜ使うの?」と言われたことがあるので、はじめになぜGitを使うのかから書いていきます。私がGitを使うのには大きく3つの理由があると思っています。

1 Bagの原因を素早く突き止めたい

例えば、規模なプログラムの場合、作っている途中でバグが出たときに、バグを修正しようと思ってソースコードに手を加えたが、そのせいで新たなバグを生んでしまった。しかし、何を変更したことが影響したのか既にわからない状態です。こんなときにGitで管理していれば、正常だったバージョンとのDiffを見ればどこを変更したのかがわかりますし、最悪の場合、良かったときの状態に戻せます。

2 変更履歴を残したい

例えば自分で書いたレポートを添削してもらい、一部を書き直して「ver2」など新しいファイルを作ったことは無いでしょうか。もしくは、保存してファイルを閉じてしまったあとで、前書いた状態に戻したいと思ったことは無いでしょうか。そんなときにGitで管理していればコミットごとに変更履歴を残すことができ、変更した差分を見たり、特定のコミットの状態に戻したりできます。こうすることで修正毎にいくつもファイルを作らなくても管理ができるのでスッキリします。過去に書いたものをつなげる事もできます。聞いた話によると、卒上論文をGitで管理している先輩もいるそうです。
また、変更履歴を残すことで過去にどんなバグを起こしたかを振り返ることができるので、上達への近道になるかもしれません。

3 今まで書いたコードを汚さずに新しい機能を追加したい

RPGゲームで難しい選択肢に直面したとき、一旦セーブして別のセーブデータを作り、試してから進めたことはありませんか。それと同じで、現在のコードに新しいコードを追加すると失敗する可能性があるので、一旦別のブランチを作って機能を試し、バグが出なかったらマージする手法をとります。「セーブ=コミット」、「ブランチ=新しいセーブデータ」「マージ=セーブデータの結合」とイメージしてもらうとわかりやすいかと思います。Gitの場合はマージするときにどちらの変更を適用するかを選ぶこともできます。

本題

ここからは実際に起きた誤った使い方の事例を挙げていきます。

長期間コミットしない

せっかくリポジトリを作ったのにも関わらず、コミットをしなかったせいで、結局Gitの機能を活かせていない人がいました。Gitはバージョン間の差分を見ることはできますが、コミットしなければそのバージョンが作成されません。新しいモジュールを追加する毎にコミットしましょう。

コミットしたのに長期間プッシュしない

ローカルでコミットをしたのにリモートリポジトリにプッシュしない人がいました。ローカルのデータが何らかの問題によってなくなったときに作業ができなくなってしまうので、コミットしたら一緒にプッシュもしましょう。クローンすれば前の状態がそのまま戻ってくるので安心できます。

コメントが適当

私が見たものだと「ちょこっと変更」、「整理」、「OO関数を追加」がありました。書いたプログラムは時間が経てば他人のコードです。これでは具体的に何を変更したのかがわかりません。コメントは、そのバージョンを表すタイトルです。例えば、「タイマーが途中で止まる問題を修正した」「閉じるボタンを追加」といったように、編集に関わる他人が見て何を変えたのかすぐにわかるコメントを心がけましょう。ちなみに「ooの関数を追加した」レベルで細かく書く必要はありません。コードの差分を見れば関数を追加したことはわかりますし、その関数が何なのか他人はわかりません。

実験したい機能毎にブランチを作る

新しい機能を追加するときはブランチを分ければいいんでしょ?と聞きかじった知識を実践したひとがいました。まるでぶどうの房のように小さい機能毎にブランチを分岐させて実験し、いざコミットするときに大量のコンフリクトが発生して苦労しました。(私ですw)
ブランチは、新機能を追加して依存関係やバグを修正する場であり、自分が知らないことを実験する場ではありません。ちょっとためしたいからといってやたらにブランチを増やさないようにしましょう。一度も作ったことの無いものはプロジェクトを作って試すのがよいでしょう。

変更毎に別ファイルを作る

せっかくGitを使っているのに、コミットしないでバージョンごとにファイルを作り直している人を見かけました。
変更した内容はコミットで保存しましょう。

リポジトリ内の全てのファイルをコミットしない

Gitはコミットするファイルを選ぶことができます。しかし、編集していないファイルだからといってコミットしないと後々面倒なことになります。Githubにプッシュできる内容は、現在コミットしてあるファイルだけです。そのため、そのままプッシュすると未コミットのファイルがプッシュされません。また、ブランチを作った場合はコミットしていないファイルはどこにも所属していない扱いになるので管理がややこしくなります。未コミットのファイルがコミット済みのファイルに結びついていた場合に面倒です。
イニシャルコミットでプロジェクト内の全てのファイルをコミットし、削除したファイルも含めて全ての変更をコミットすることを勧めます。

プロジェクトの外のディレクトリにリポジトリを作る

リポジトリの中に更にプロジェクトが入っているような入れ子の構造だと、環境によってはうまく認識がされないことがあるので、プロジェクト自体をリポジトリにしてしまうことをお勧めします。管理も楽になります。
リポジトリ.PNG

masterブランチで作業する

基本的にはmasterで作業してはいけません。個人で書いている場合に問題はあまりありませんが、複数人で開発している場合は深刻な問題が出てきます。ある開発者が途中まで作ったプログラムに自分で機能を追加したいとき、masterをそのまま書き換えたら作業中のものが混ざってしまい、他の開発者が使うときに混乱してしまいます。ですので、基本的には自分で作業するブランチはmasterから枝分かれさせてそこで作業します。バグの確認が済んでからマージし、プルリクエストを送りましょう。そうすることで常にmasterは開発の最新版を安定した状態で保つことができ、バグの混入などにより開発が停滞することを防ぐことができます。
Gitの管理手法の一つに「Git Flow」があります。この手法もmasterは最後までいじらず、developブランチで作業し、機能の実装やバグフィックスなどタスクごとにブランチを作成し作業を行います。作業が完了したらdevelopブランチにマージします。
gitflow.PNG

おまけ

Q&A

Q1:GitとGithubの違いは何?
A1:Gitはバージョン管理ツール、Githubはソースコードの共有や共同編集をするためのサーバシステムです。(GithubではGitの機能の一部を使うことができる)Githubではファイルを直接uploadする事もできますが、それだと厳密なバージョン管理はできないので、ローカルに作ったGitのリポジトリで管理し、プッシュするのが基本です。

Q2:プルリクエストはどんなときに使うの?
A2:Githubでは誰でも好き勝手に編集していいわけではありません。通常、リポジトリの管理者が編集をします。
Githubにあるコードをクローンしローカルで編集したら、その編集を元のリモートリポジトリに適用してもらいたいときに使います。

Q3:developで作業中なのにmasterを変更してしまった。
A3:masterをdevelopにコミットするときにdiffを見ながらひとつひとつ手作業で変更を適用していきましょう。そもそも面倒なのでmasterを編集するのはやめましょう。

Q4:Git Flow以外のブランチはどんなときに作ればいい?
A4:例えばOSのバージョンごとに少しソースコードが異なる場合にブランチで分けることがあります。macOS用、windows10用、Ubuntu18.04、Ubuntu16.04用などです。他にも使用する機器ごとに分岐させることもありますが、そこは経験しながら少しずつ分かっていくと思います。

Q5:リベースって何?マージとどう違う?
A5:リベースを行うとリベース先のブランチがリベース元のブランチにつけ変わります。プログラムをリリースする際にマージではなくリベースを行うとブランチの枝分かれがスッキリします。
詳しくはhttp://liginc.co.jp/web/tool/79390#m1
を参考にするとわかりやすいです。

Q6:リセットするときにhardやsoftなどオプションがあるけど何が違うの?
A6:リセットを行うとローカルリポジトリのブランチは選択したコミットの状態に戻ります。そのときに何を消すかがオプションによって変わります。
Mixed:作業中の内容を保持したまま、リポジトリの状態を指定したコミットまでリセットします。インデックスはリセットされます。
Soft:Mixedと同じく作業中の内容を保持したまま指定したコミットまでリセットします。リセットされる前のファイルの内容はインデックスに登録された状態になります。
Hard:指定したコミットまでファイルの内容を完全に戻します。リセット前のコミットまでの変更は全てなくなります。最終手段なので私はあまり使いません。

おすすめのバージョン管理ツールの紹介

TortoiseGit...Gitをコマンドラインで始めたが、謎の呪文を打つばかりで全体像がつかめないという人はまずはこれを使うことお勧めします。Windowsしか対応していないですが、フォルダに入った状態で右クリックすれば様々なコマンドをGUIで簡単に操作することができるので理解が深まります。
GitKraken...GitをGUIで使うことができるツールです。TortoiseGitと違い、Atomエディタ上で動くのでMacやLinuxでも使うことができます。
CadLib.io...プログラミング向けではないですが、回路図を書く人がバージョン管理をしたいときに使います。
GrabCAD Workbench...CADモデリング用のバージョン管理ツールです。CADで図面を書く人がバージョン管理をしたいときに役に立ちます。上書きしてしまったけどやっぱり前の状態に戻したいってときに役に立ちます。

最後に

今回書いたことが誰かの役に立ってくれたら幸いです。何かあればコメントをお願いします。

参考

https://hm-solution.jp/lifehack/post2475.html
https://qiita.com/KosukeSone/items/514dd24828b485c69a05
https://www.atmarkit.co.jp/ait/articles/1708/01/news015.html
https://www.sejuku.net/blog/72311

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

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

昨日までのはこちら

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日後にエンジニアになるキミ - 55日目 - Git - Gitの使い方

Githubについて

Github
Gitを利用した、開発者を支援するWebサービスの名前です。

ローカルリポジトリに登録したものをリモートリポジトリに登録してみましょう。

GitHubのアカウント登録

Githubはのアカウントを作るところから始めます。

まずは
GitHubのトップページ
にアクセスします。

ここで、ユーザ名とメールアドレス、パスワードを入力して
アカウント登録を行います。

スクリーンショット 2020-05-15 18.16.22.png

無料で使えるFreeプランがあります。

Freeを選んでからFinish sign upボタンをクリックします。

スクリーンショット 2020-05-15 18.21.20.png

GitHubでリポジトリを作成する

登録できたらSign inからログインします。

スクリーンショット 2020-05-15 18.18.03.png

まずはリポジトリを作成します。

GitHubにログインした状態でNewボタンを押下します。

スクリーンショット 2020-05-15 18.27.53.png

次に表示される画面ではRepository nameの入力のあと
必要に応じてDescriptionに説明書を入力します。

リポジトリの種類をPublicPrivateを選択しますが
Privateリポジトリは有料会員のみなのでPublicを選びます。

最後にリポジトリの中にあらかじめREADMEファイルを作成しておく場合はInitialize this repository with a READMEにチェックを入れます。

.gitignorelicenseについては後で追加や変更ができますのでNoneを選択します。

スクリーンショット 2020-05-15 18.37.52.png

ここではリポジトリ名をsampleとしてpublicリポジトリを作成します。

入力が終わりCreate repositoryをクリックするとリポジトリの作成は完了です。

スクリーンショット 2020-05-15 18.40.55.png

sampleリポジトリが作成されました。

リモートへプッシュを行う(push)

昨日までの操作ができていたら
ファイルをリモートへプッシュしてみましょう。

ファイルを作ったディレクトリに移動してリモートリポジトリの情報を追加します。
この情報は、先ほどGitHub上に表示された、リモートリポジトリのアドレスです。

自身のリポジトリの名前などに適宜変更しましょう。

git remote add origin https://github.com/username/projectname.git

次にpushコマンドです。
コマンドを打つとユーザー名とパスワードを求められますので
入力してエンターキーを押して進みます。

git push origin master

Username for https://github.com:
Password for 'https://xxxxxx@github.com':

Enumerating objects: 3, done.
Counting objects: 100% (3/3), done.
Delta compression using up to 8 threads
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 366 bytes | 366.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To https://github.com/xxxxxx/xxxxxx.git
* [new branch] master -> master

うまくいけば上記のようなログが表示されて終了します。

プッシュした後にリポジトリをみるとファイルが登録されているのが分かります。
スクリーンショット 2020-05-15 18.50.30.png

リモートリポジトリをクローンする(clone)

手順としては先にリモートを作っておいた方が楽かもしれません。

先に空のリモートを作成しておいてそれをローカルに持ってきて
そこにファイルを追加する方法です。

ここではcloneコマンドでリモートリポジトリを
ローカルリポジトリに複製します。

ターミナルなどでどこかのディレクトリに移動しておき
下記のコマンドを実行します。

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

実行が終わると今いるディレクトリに新しくリポジトリが作成されます。

そこにファイルを追加していき、コミット、プッシュという手順で
どんどん更新していきます。

まとめ

リモートへのプッシュ方法
リモートからのリポジトリ複製方法を覚えておき
いつでもどこでも更新が行えるようになろう。

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

作者の情報

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

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

Twitter:
https://twitter.com/otupython

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

[Docker] [Gitlab] Gitlab基本安裝

目的

這是一次安裝經驗紀錄,當我們需要自己架設 版本控管 環境時,以前用過幾個不同環境,最早是都放在github

之後到公司後好像許多公司都會自己做這段,之前是用GOGS但覺得沒那麼好用,後來無意間發現同事推薦這款發現功能真的挺齊全的就決定來使用看看

預先準備環境:Docker

安裝Gitlab

  1. 建立綁定資料夾
mkdir -p /docker/gitlab/config
mkdir -p /docker/gitlab/data #備份位置也會在這
mkdir -p /docker/gitlab/logs

2 . 安裝Gitlab

docker run -d -e "TZ=Asia/Taipei" -h gitlab 
-p 2222:22 \ #2222(外部監聽Port):22(Docker 內部對應Port) SSH用
-p 8888:80 \ #8888(外部監聽Port):80(Docker 內部對應Port) HTTP用
-p 8443:443 \ #8443(外部監聽Port):443(Docker 內部對應Port) HTTPS用
-v /docker/gitlab/config:/etc/gitlab \  mount  資料夾
-v /docker/gitlab/logs:/var/log/gitlab \
-v /docker/gitlab/data:/var/opt/gitlab \
--restart always  \
--name gitlab gitlab/gitlab-ce:latest

3.登入gitlab
gitlab1.png

gitlab2.png

這樣就完成了

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

【gibo】.gitignoreのテンプレがすぐにできる。(けど一箇所躓いた)

はじめに

giboで.gitignoreを作る際に一瞬だけ躓いたところがあったので、メモしておく。

検証環境

$ sw_vers
ProductName:    Mac OS X
ProductVersion: 10.15.3
BuildVersion:   19D76
$ ruby -v
ruby 2.5.1p57 (2018-03-29 revision 63029) [x86_64-darwin19]
$ rails -v
Rails 5.2.4.2

brewでインストール

$ brew install gibo

インストールできているか確認

$ gibo -v
もしくは
$ gibo --version

gibo 2.2.4 by Simon Whitaker <sw@netcetera.org>
https://github.com/simonwhitaker/gibo

Fetches gitignore boilerplates from https://github.com/github/gitignore

Usage:
    gibo [command]

Example:
    gibo dump Swift Xcode >> .gitignore

Commands:
    dump BOILERPLATE...   Write boilerplate(s) to STDOUT
    help                  Display this help text
    list                  List available boilerplates
    root                  Show the directory where gibo stores its boilerplates
    search STR            Search for boilerplates with STR in the name
    update                Update list of available boilerplates
    version               Display current script version

.gitignoreを作成しテンプレを入れる

ここで、自分は

$ gibo rails >> .gitignore

としたのですが、そうすると.gitignore

gibo 2.2.4 by Simon Whitaker <sw@netcetera.org>
https://github.com/simonwhitaker/gibo

となり、
なにこれ?となります。

 Example:
gibo dump Swift Xcode >> .gitignore

ちゃんとExampleの所に書いてあったのに気づきませんでした。

$ gibo dump rails >> .gitignore

これで、.gitignoreが新規作成され、gitのソース管理から除外されるリストが入ります。

### https://raw.github.com/github/gitignore/07b3cd7a90de3fb5e88303a23d619ebd4cdd807a/Rails.gitignore

*.rbc
capybara-*.html
.rspec
/db/*.sqlite3
/db/*.sqlite3-journal
/db/*.sqlite3-[0-9]*
/public/system
/coverage/
/spec/tmp
*.orig
rerun.txt
pickle-email-*.html

# Ignore all logfiles and tempfiles.
/log/*
/tmp/*
!/log/.keep
!/tmp/.keep

# TODO Comment out this rule if you are OK with secrets being uploaded to the repo
config/initializers/secret_token.rb
config/master.key

# Only include if you have production secrets in this file, which is no longer a Rails default
# config/secrets.yml

# dotenv, dotenv-rails
# TODO Comment out these rules if environment variables can be committed
.env
.env.*

## Environment normalization:
/.bundle
/vendor/bundle

# these should all be checked in to normalize the environment:
# Gemfile.lock, .ruby-version, .ruby-gemset

# unless supporting rvm < 1.11.0 or doing something fancy, ignore this:
.rvmrc

# if using bower-rails ignore default bower_components path bower.json files
/vendor/assets/bower_components
*.bowerrc
bower.json

# Ignore pow environment settings
.powenv

# Ignore Byebug command history file.
.byebug_history

# Ignore node_modules
node_modules/

# Ignore precompiled javascript packs
/public/packs
/public/packs-test
/public/assets

# Ignore yarn files
/yarn-error.log
yarn-debug.log*
.yarn-integrity

# Ignore uploaded files in development
/storage/*
!/storage/.keep
/public/uploads

終わりに。

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

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

git あれこれ

事前知識

よく使うやつ

- git add
- git commit
- git commit --amend # コミットを修正
- git log
- git show ハッシュ値
- git blame ファイルパス # そのファイルを編集した人を確認できる
- git reset --soft HEAD~ # コミットしてしまったモノをインデックスに戻す
- git branch -a # リモートブランチの一覧確認
- git rebase
  - conflictになった場合
    - >>> でソース検索して、コンフリクト個所を修正
    - git add . # 修正をインデックスに入れる
    - git rebase --continue # この繰り返し
- gitの設定ファイル
 - ~/.gitconfig  # ここを編集すると passwordを求められrない

手を動かしながら学習できるやつ

http://gitimmersion.com/

commit周り

  • commit までしてしまった変更内容を確認する
 git log -p -1
  • commitをしてしまったのを戻す
git reset --soft HEAD~1

リモートブランチ削除

# リモートブランチ確認
git brach -a

# 対象のブランチ削除
git push origin :hoge 
※closeになっている

# 手順
1.prの内容をコピーしてオク
2.ローカルのブランチ名変更
3.リモートブランチを削除する
4.再度 push

検索色々

https://help.github.com/ja/articles/searching-commits

git squash

  • commitをまとめるモノ

https://backlog.com/ja/git-tutorial/stepup/34/

git 設定

git config
https://qiita.com/shionit/items/fb4a1a30538f8d335b35

git 設定ファイル場所

~/.gitconfig

ブランチ名変更

https://qiita.com/suin/items/96c110b218d919168d64

git branch -m <古いブランチ名> <新しいブランチ名>

リモートブランチ削除

git push --delete origin branch_name

特定のコミットまで戻る

$ git reset --hard ハッシュ値

git blame

git blame  パス → ハッシュ値取得

git show ハッシュ値 → PR検索可能

ファイルの行毎に履歴を確認する

git log --grep=検索文字列

https://qiita.com/scalewallet/items/5bce39e92a6a8722aa54

initail commot

git commit --allow-empty -m "first commit"

amend

git commit --amend
:wq
修正漏れでコミットできていない時

add取り消し

git reset HEAD spec/models/product_spec.rb

git commit indexに戻す

git reset --soft HEAD~

conflictを解除する

git add .
git rebase --continue

cherry-pick修正内容だけ持ってくる

git cherry-pick 24838567ab060b430194fa6123a59ffa2f3589f2

  • フロー
branchA ←コピーしたいブランチのハッシュ値を調べる git logで

branchA-2を作成する

gc branchA-2

git cherry-pick ハッシュ値 of 24838567ab060b430194fa6123a59ffa2f3589f2

git branch  -D branchA

git branch -m branchA-2 branchA

解決法

$ rm -f .git/index.lock

git 特定のコミットまでもどしたい

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

超簡単2ステップ!WSL2+GitKraken+VsCodeで開発する設定

目的

wsl2でコードを管理する際,Vscodeのgit拡張機能を利用していたが,GitKrakenのGUIで管理したくなった.
(ブランチがうねうねなるの楽しい)
サーバーで計算回す用のシェルスクリプトなどもテストしたいので,実行環境はUbuntuが望ましい.
あまりにも簡単なので需要あるか怪しいが初投稿なので練習も兼ねて...

方針

方法は2通りある.
1. XcXsrvを使ってWSL2のGUIがWindows側から見れるようにし(参考記事),WSL2のUbuntuにGitKrakenを入れる.
2. VsCodeのデフォルトターミナルをwslとし,Windows領域でプロジェクトを管理する.

2の方が圧倒的に簡単に設定でき,GitKraken起動時にコマンドを打つ必要もないのでこちらで進める.

やり方

  1. VsCodeのターミナルを開く
  2. 赤枠をクリック->既定シェルの選択 -> wsl tempsnip.png
  3. これでターミナルを開くとmnt/c/で開かれる.シェルスクリプトも普通に動くし,Windows領域なのでWindowsに入っているGitKrakenで簡単に管理できる.
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む