- 投稿日:2020-05-15T23:39:42+09:00
シチュエーション別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 commitHEADから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
後プルリクしました。
- 投稿日:2020-05-15T22:27:12+09:00
【しくじりプログラミング】失敗事例から学ぶ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にプッシュできる内容は、現在コミットしてあるファイルだけです。そのため、そのままプッシュすると未コミットのファイルがプッシュされません。また、ブランチを作った場合はコミットしていないファイルはどこにも所属していない扱いになるので管理がややこしくなります。未コミットのファイルがコミット済みのファイルに結びついていた場合に面倒です。
イニシャルコミットでプロジェクト内の全てのファイルをコミットし、削除したファイルも含めて全ての変更をコミットすることを勧めます。プロジェクトの外のディレクトリにリポジトリを作る
リポジトリの中に更にプロジェクトが入っているような入れ子の構造だと、環境によってはうまく認識がされないことがあるので、プロジェクト自体をリポジトリにしてしまうことをお勧めします。管理も楽になります。
masterブランチで作業する
基本的にはmasterで作業してはいけません。個人で書いている場合に問題はあまりありませんが、複数人で開発している場合は深刻な問題が出てきます。ある開発者が途中まで作ったプログラムに自分で機能を追加したいとき、masterをそのまま書き換えたら作業中のものが混ざってしまい、他の開発者が使うときに混乱してしまいます。ですので、基本的には自分で作業するブランチはmasterから枝分かれさせてそこで作業します。バグの確認が済んでからマージし、プルリクエストを送りましょう。そうすることで常にmasterは開発の最新版を安定した状態で保つことができ、バグの混入などにより開発が停滞することを防ぐことができます。
Gitの管理手法の一つに「Git Flow」があります。この手法もmasterは最後までいじらず、developブランチで作業し、機能の実装やバグフィックスなどタスクごとにブランチを作成し作業を行います。作業が完了したらdevelopブランチにマージします。
おまけ
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
- 投稿日:2020-05-15T19:05:02+09:00
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のトップページ
にアクセスします。ここで、ユーザ名とメールアドレス、パスワードを入力して
アカウント登録を行います。無料で使える
Freeプラン
があります。
Free
を選んでからFinish sign up
ボタンをクリックします。GitHubでリポジトリを作成する
登録できたら
Sign in
からログインします。まずはリポジトリを作成します。
GitHubにログインした状態で
New
ボタンを押下します。次に表示される画面では
Repository name
の入力のあと
必要に応じてDescription
に説明書を入力します。リポジトリの種類を
Public
かPrivate
を選択しますが
Private
リポジトリは有料会員のみなのでPublic
を選びます。最後にリポジトリの中にあらかじめREADMEファイルを作成しておく場合は
Initialize this repository with a README
にチェックを入れます。
.gitignore
やlicense
については後で追加や変更ができますのでNone
を選択します。ここではリポジトリ名を
sample
としてpublic
リポジトリを作成します。入力が終わり
Create repository
をクリックするとリポジトリの作成は完了です。
sample
リポジトリが作成されました。リモートへプッシュを行う(push)
昨日までの操作ができていたら
ファイルをリモートへプッシュしてみましょう。ファイルを作ったディレクトリに移動してリモートリポジトリの情報を追加します。
この情報は、先ほどGitHub上に表示された、リモートリポジトリのアドレスです。自身のリポジトリの名前などに適宜変更しましょう。
git remote add origin https://github.com/username/projectname.git次に
push
コマンドです。
コマンドを打つとユーザー名とパスワードを求められますので
入力してエンターキーを押して進みます。git push origin masterUsername 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うまくいけば上記のようなログが表示されて終了します。
プッシュした後にリポジトリをみるとファイルが登録されているのが分かります。
リモートリポジトリをクローンする(clone)
手順としては先にリモートを作っておいた方が楽かもしれません。
先に空のリモートを作成しておいてそれをローカルに持ってきて
そこにファイルを追加する方法です。ここでは
clone
コマンドでリモートリポジトリを
ローカルリポジトリに複製します。ターミナルなどでどこかのディレクトリに移動しておき
下記のコマンドを実行します。git clone リモートリポジトリのURL実行が終わると今いるディレクトリに新しくリポジトリが作成されます。
そこにファイルを追加していき、コミット、プッシュという手順で
どんどん更新していきます。まとめ
リモートへのプッシュ方法
リモートからのリポジトリ複製方法を覚えておき
いつでもどこでも更新が行えるようになろう。君がエンジニアになるまであと44日
作者の情報
乙pyのHP:
http://www.otupy.net/Youtube:
https://www.youtube.com/channel/UCaT7xpeq8n1G_HcJKKSOXMwTwitter:
https://twitter.com/otupython
- 投稿日:2020-05-15T15:34:31+09:00
[Docker] [Gitlab] Gitlab基本安裝
目的
這是一次安裝經驗紀錄,當我們需要自己架設
版本控管
環境時,以前用過幾個不同環境,最早是都放在github之後到公司後好像許多公司都會自己做這段,之前是用GOGS但覺得沒那麼好用,後來無意間發現同事推薦這款發現功能真的挺齊全的就決定來使用看看
預先準備環境:Docker
安裝Gitlab
- 建立綁定資料夾
mkdir -p /docker/gitlab/config mkdir -p /docker/gitlab/data #備份位置也會在這 mkdir -p /docker/gitlab/logs2 . 安裝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這樣就完成了
- 投稿日:2020-05-15T13:40:49+09:00
【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.2brewでインストール
$ 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終わりに。
最後まで読んで頂きありがとうございます
転職の為、未経験の状態からRailsを学習しております。正しい知識を着実に身に着け、実力のあるエンジニアになりたいと考えています。継続して投稿していく中で、その為のインプットも必然的に増え、成長に繋がるかと考えています。
今現在、初心者だからといって言い訳はできないですが、投稿の内容に間違っているところや、付け加えるべきところが多々あるかと思いますので、ご指摘頂けると幸いです。この記事を読んで下さりありがとうございました。
- 投稿日:2020-05-15T11:06:50+09:00
git あれこれ
事前知識
- qiitaなどでgitについて一度調べる。gitとは何か?みたいな
- git と githubの違いを理解 連携記事(https://qiita.com/oo-shin/items/06963c7a1b3219347348)
よく使うやつ
- 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ない手を動かしながら学習できるやつ
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/fb4a1a30538f8d335b35git 設定ファイル場所
~/.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 --continuecherry-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
- 投稿日:2020-05-15T10:18:27+09:00
超簡単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起動時にコマンドを打つ必要もないのでこちらで進める.
やり方