[Git]gitコマンド

1.Gitデフォルトコマンド

[1] git init

$ git init

現在のディレクトリでgitバージョンを管理することを宣言します.gitディレクトリが作成されます.

[2] git config

$ git config --global user.name 'testGlobal'
$ git config --gloval user.email '[email protected]'
$ git config --local user.name 'testLocal'

gitユーザー名と電子メールを設定します.gitコミット時にログインしていない場合、エラーが発生します.

[3] git status

$ git status

各ファイルのステータスを決定します.これは、コミットするファイルの設定が正しいことを意味します.modified, track, untrack etc

[4] git log

$ git log
$ git log --graph

現在のブランチのコミット履歴を確認します.これを視覚的に理解したい場合は、「--図」を使用することもできます.GinkrakenとSource Treeを使用することをお勧めします.

[5] git add

$ git add test.java
$ git add .

addコマンドは、ファイルを追跡することを示しますが、追跡したファイルはstaging領域にアップロードされます.ここでstaging areaは、コミットするファイルを含む一時リポジトリです.すなわち、コミット時にstaging領域の上にあるファイルが新しいスナップショットとインクリメンタルを作成し、このstaging領域にファイルをアップロードする動作はgit addコマンドである.

git add取り消しコマンド

$ git reset HEAD [file] # staging area에 올라온 특정 파일을 unstaged 상태로 바꿉니다.
$ git reset . # staging area에 올라온 파일들을 모두 modified 상태로 바꿉니다.

[6] git commit

$ git commit #이후 vim editor에서 commit 메시지 작성
$ git commit -m "message"
$ git commit am "message" #add명령어 없이 바로 커밋 가능
$ git commit --amend # 최근 커밋한 메시지를 수정하고 싶을 때 사용

staging領域のファイルをスナップショットとインクリメンタルに変換し、ローカルリポジトリに追加するコマンド.commitを実行する場合.Git/objectsディレクトリはgitオブジェクトを作成します.また、commit idを使用してコミットを区別し、後で履歴を表示できるように、タスク(エラー修復、追加機能など)に応じてそれぞれコミットすることをお勧めします.

checkoutを使用してコミットを移動

HEADから複数目または対応するコミットIDに移動することができる.仮分岐(?)コミットされたソースファイルを再コミットする場合は、いくつかの操作を実行するだけで、対応するコミットが表示されます.通常、チェックアウトする前にstaging領域のファイルを「$git reset」に変更する必要があります.コマンドを使用します.

$ git checkout HEAD~3 # 현 브랜치의 HEAD에서 세 단계 과거 커밋으로 이동합니다.
$ git checkout eb92kdn # 해당 commitId로 checkout합니다.

Example.
$ git checkout eb93kd
$ git checkout -b testBranch
~~~ 작업
$ git checkout master
$ git merge testBranch

[7]gitコミットメッセージのキャンセル

git reset

特定のコミットに戻ることができますが、バージョンを復元した後のコミットは履歴から削除されます.つまり、今のように履歴を残すことはありません.

$ git reset --soft commmitId # commit 이후 파일들을 staged 상태의 working 디렉토리에 모두 보존합니다.
$ git reset --mixed commitId # commit 이후 파일들을 unstaged 상태의 working 디렉토리에 모두 보존합니다.
$ git reset --hard commitId # commit 이후 파일들을 모두 삭제합니다.

# default는 mixed 명령어입니다.

git reset > git push --force

個別のプロジェクトの場合はgit push--forceでリモート・リポジトリに接続できます.ローカルとリモートのコミット履歴が一致しない場合でも.

$ git push --force origin dev

git revert

特定のバージョンに戻ることができますが、返されたバージョン以降も履歴は保持されます.すなわち、削除するコミットは、以前の履歴を保持し、新しいコミットの作成時に過去に戻ります.

$ git revert commitId

だから何を書きますか?

resetは、コミット履歴をきれいに維持し、一人で作業している間に簡単に戻ることができます.しかし、チームメンバーと同じブランチで作業する場合、コミットが混在する可能性があります.これは危険な欠点です.そのため、チームプロジェクトはできるだけrevertを使用することをお勧めします.
revertを使用すると、途中で何が起こったのか、なぜ戻ってきたのかを記録できます.また、他の人と同じブランチで作業している場合は、コードの競合を最小限に抑えることができます.

インシデント)中間コミット>git rebaseを削除する方法

$ git rebase --interative

1) $ git rebase -i HEAD~3
2) # 터미널에서 HEAD ~ 3개까지의 커밋을 보여줌
3) [명령어] [커밋 해시] [커밋 메시지] 순서로 구성되고, 터미널에서 원하는 명령어 수행
4) 이후 rebase --continue 실행

[8] git cherry-pick

他のブランチのコミットを私のブランチに選択的に適用できます.rebase、reset機能も実現できるが、以下の場合、cherry-pickの利点が最大化される.

が誤って別のブランチにコミットし、その後コミットが見つかった場合、特定のコミットに対してcherry-pick操作が行われるのはコミットのみであり、誤ったブランチはreset or revert or rebase-i操作が実行されます.

この機能は、

コードの依存性のため、別のブランチの部分コミットをインポートする必要がある場合に便利です.

この機能は、

を変更して2つのブランチに同時にコミットする必要がある場合に便利です.1つのブランチにコミットした後、別のブランチでcherry-pickを実行します.

Example
下図では、cherry-pickがない場合とcherry-pickを使用する場合を比較し、fを主ブランチに選択的にインポートしたい場合のみを示します.

git rebase、resetを使用して他のブランチコミットを適用

$ git checkout Feature
$ git rebase Master
$ git checkout Master
$ git merge Feature

$ git reset --hard f # master g commit 삭제
$ git reset --soft e # master f commit 해제 및 코드 변화 가져오기. f는 stash 상태
$ git stash # f 코드 변화 stash 저장

$ git reset --hard d # master e commit 삭제

$ git stash pop # master f 코드 변화 불러오기
$ git commit f

git cherry-pick

$ git checkout master
$ git cherry-pick f-CommitId

2. Branch & Merge & Rebase

[1] Git Branch

$ git branch # 작업중인 working 디렉토리의 브랜치들을 보여줍니다.
$ git branch branchName # 새로운 브랜치를 생성합니다.
$ git branch -D branchName # 해당 브랜치를 삭제합니다. (d)와 구별
$ git checkout branchName # 작업할 브랜치로 이동합니다. 이때 staging area와 working 디렉토리의 파일들이 변경된 브랜치를 기준으로 변경됩니다.

必要に応じてメイン支柱から分岐することができます.プライマリブランチを処理するときにブランチに沿って操作すると、プライマリブランチが滞留するまで影響はありません.すべてのタスクが完了すると、プライマリブランチにとどまります.これにより、変更がプライマリブランチに適用されます.
2つの異なるブランチをマージする方法は「merge」と「rebase」です.

使用例

は、正常なプロジェクトの実行に影響を与えることなく、新しい機能の追加、テスト、修復に役立ちます.たとえば、プライマリ・ブランチで他の機能を実装するたびに、ブランチが作成され、操作が完了するとプライマリ・ブランチに残ります.代表的なのはgithub flowとgit flowです.

は、チームプロジェクトでそれぞれの機能を実行し、途中滞在中に「コラボレーション」を行うことが非常に有用であると結論した.

[2] Git Merge

2つの異なるブランチをマージする操作.2つのブランチを使用して、複雑で時間順のコミットを決定できます.一方、rebaseにはブランチが1つしかないため、プロセスは簡単ですが、時間単位でコミットされるわけではありませんので、履歴を記録するのに適していません.mergeには「fast forward merge」と「3ウェイmerge」があります.

$ git merge targetBranch
$ git merge targetBranch --no--ff # fast-forward임에도 merge commit을 남길 수 있
습니다.
$ git merge --squash myBranch

注意事項
どのブランチに存在するかを決定し、そのブランチでチェックアウトする必要があります.これは、コードを反映するブランチ(主にプライマリ、dev)にコードをチェックアウトし、マージを実行する必要があることを意味します.
別のブランチにチェックアウトする場合は、ブランチ内のすべての変更を追加し、コミットしてからチェックアウトすることをお勧めします.これにより、作業ディレクトリのファイルが失われる可能性があります.

fast forward merge

現在のブランチのヘッダ(下図はmaster)が変更されたブランチ(下図はfunction)basecommitと同じである場合、現在のブランチ(下図はmaster)のheadを変更されたブランチのheadに引き上げます.すなわち,関数ブランチは,主ブランチのすべての履歴を持つため,主ブランチの頭を高くするだけでよい.

3 way merge

次の図に示すように、新しいブランチに既存のブランチのすべての履歴が含まれていない場合(赤のコミットのため)、すばやく前にマージすることはできません.これは、主磁気ヘッドを簡単に移動するだけでは問題を解決することが困難であることを意味する.したがって、merge commitと呼ばれる新しいコミットメカニズムを作成する必要があります.問題を解決する.ただし、fast forward mergeよりもグラフィックが複雑な場合があるためgit rebaseを使用する可能性があります.
squash and merge
サブブランチの履歴は記録されず、コミット終了項目には親コミットがあります.

[3] git rebase

これは、現在のブランチのbase commitを再設定することを意味します.すなわち,現在のブランチの基本コミットをbaseBranchのheadに移動する.
実際、3 way mergeは実行結果と同じですが、以下の違いがあります.

rebaseは、コミット履歴の管理に役立ちます.

ログ履歴は変更される可能性があるため、時間系列の履歴を特定するのは難しい.

適切に使用しないと、コミットが歪む可能性があります.

$ git checkout user
$ git rebase dev
$ git checkout dev
$ git merge user # fast forward merge 진행

※ Automatic merge failed; fix conflicts and then commit the result.
異なるブランチで同じファイルを変更したときに表示されるログ.これは手動で修復されたものです.

[4]連結ブランチの概要

merge

サブブランチのすべての履歴を記録し、2つの親がコミットします.すべての履歴を表示できますが、複雑なプロセスになります.

$ git merge user

squash and merge

サブブランチの履歴は記録されませんが、コミットマージンには親コミットがあります.履歴はいくつか表示できますが、プロセスは明確です.

$ git merge --squash user

rebase and merge

サブブランチのすべての履歴を記録します.各コミットには親コミットがあります.ただし,コミットごとに時間順の履歴を特定することは困難である.

Reference)
https://velog.io/@kwonh/Git-Rebase%EB%9E%80
https://devye.tistory.com/27
https://www.git-scm.com/