KOMAS

Git 기본 사용법 및 명령어

git을 다운로드하여 프로그램을 설치한 후 $git --version 명령어로 git이 제대로 데스크톱에 설치되었나 확인한다.

git을 이용할 폴더에 들어가서 폴더 배경에서 오른쪽 클릭 - git bash here을 누르면 git이 사용 가능하다.

$git init하게 되면서 (.git)폴더가 생성된다.

Git의 특징

분산 버전관리 시스템

중앙 저장소뿐만 아니라 로컬 저장소에서도 history를 갖고 있다.

Git의 원리

변경이 일어날 때 마다 기존 파일들은 실제로 복사해서 갖고 있는 것이 아니라 기존 내역들을 참조하고 있다. , 해시코드 값을 참조

git init: 작업 영역 생성

git add: [새로 생성된 파일]을 등록한다. 기존 내역은 [기존 파일 참조(해시값)]

git commit: [새로 생성된 파일] + [기존 파일 참조] = 해시 코드 생성

기본 명령어

git 명령어 --help 도움말 보기

git log -> q 나가기

touch sample.txt 테스트할 때 빈 파일 만들기

$git config --global user.email 사용하는 이메일 commit 시 작성자로 등록됨

$git config --global user.name 사용하는 이름

github사이트에서 이용하는 이메일과 이름 [내 정보]를 등록하는 명령어이다.

$git init git 저장소 생성, 현재 폴더를 버전관리하겠다고 선언

$git status 폴더 안 파일들의 상태를 확인 [새로 만든 파일(untracked), 변경된 파일(modified)] 

$git add commit을 수행할 파일을 staging area에 추가한다. [새로 만든 파일(untracked), 변경된 파일(modified)]  둘다 add를 해줘야한다.

이전에 add로 추적을 시켰다 하더라도, 수정시에 새로 add를 해줘야한다.

add는 단순히 추적이 아닌 staging area에 올리는 것이다.

2가지 기능이 있다고 생각

(1) 새로운 파일을 staging area에 올린다.

(2) 변경된 파일을 staging area에 올린다.

$git commit -m "설명" 커밋할 때 구체적인 설명을 같이 입력한다. commit 명령어는 기록을 남긴다.

$git commit -am "설명" 모든 file을 자동으로 add하며 커밋도 진행한다. (단, untracked file은 커밋하지 않는다.)

staging area 에 올라온 file들을 기록시킨다.

$git log 커밋 기록을 보는 명령어이다.

$git diff 커밋번호..커밋번호 커밋간의 차이를 본다.

log화면에서 q를 누르면 나간다.

$git reset 커밋번호 커밋번호에 해당되는 버전으로 돌린다.

로컬 저장소일때만 사용 추천

gitignore 

gitignore 파일안에 git이 추적하지 않을 파일명을 등록하여 추적되지않게 할 수 있다.

"git add ." 해도 staging area에 등록되지 않는다.

$vim .gitignore gitignore 을 만든다.

*.파일형식 파일 유형 전체를 추적하지 않을경우 

주의점. 한번 추적된 파일은 gitignore에 등록해도 추적을 피할 수 없다. 

$git rm --cached 파일명 해당 명령어로 git cash를 지워주면 gitignore가 정상적으로 가능하다.

Git Branch

브랜치를 만드는 경우

• 테스트 기능을 만들어야하고, 결과적으로 원격저장소에는 올리지 않는 경우
• 기능이 사용될 가능성이 적은 경우
• 메인 프로젝트는 유지하며 커스텀 프로젝트를 만들 경우

이전 시점으로 돌아가서 브랜치를 만들지 않고  commit진행하고, 다른 브랜치로 이동하려고하면 불가능하다.

작업한 커밋에 대한 브랜치를 만들어줘야 다른 브랜치로 이동할 수 있다.

$git branch 현재 branch정보들을 볼 수 있다. (현재 check인 branch는 * 표시)

$git branch 브랜치 새로운 branch를 만든다.

$git branch -d 브랜치 branch를 삭제한다.

$git branch -D 브랜치 branch를 강제 삭제한다.

$git checkout 브랜치 현재 사용중인 branch를 checkout하고, 브랜치명 branch로 시점을 이동한다.

$git checkout -b 브랜치 브랜치를 만들면서 체크아웃도 진행

$git checkout 커밋 해시값 N자리

checkout 명령어는 HEAD 이동 명령어다. 커밋 번호가 존재하며 커밋번호 앞 N자리를 이용하여 시점을 이동한다.

$git log --branches --decorate --graph log들을 시각적으로 표현해서 보여준다.

$git diff 브랜치1..브랜치2 branch들 간의 차이를 본다. (윗 라인이 브랜치1, 아랫 라인이 브랜치2 / 브랜치2가 기준)

$git merge 브랜치2

현재 시점이 브랜치1인 상태라 가정한다.

merge하면 브랜치1로 브랜치2의 커밋들을 가져온다.

충돌이 없었다면 브랜치2의 커밋 내용이 브랜치1에 전부 merge되어 브랜치2는 삭제가 가능하다.

* 브랜치를 합치는게 아니라 해당 브랜치가 갖고 있는 커밋들을 합치는 것이다.

fast-forward

새로운 브랜치로 nb에서 commit을 진행하고 master에서 nb 커밋들을 이용하고자 할 때

(master는 commit진행을 하지않은 상황)

$git checkout master 

$git merge nb

master로 시점을 옮기고, nb를 merge하면 fast-forward가 진행된다.

3way-merge

[1 라인] 수정이 일어나지 않았으면 그대로 반영 (A A A) -> A

[2, 3 라인] 변경부분은 변경부분으로 반영 (H B B) -> H

[4 라인] 같은부분의 변경은 충돌을 직접 해결해줘야함 (H D T) -> 충돌 해결 필요

$git checkout master 

$git merge nb

master로 nb 커밋을 가져와서 merge완료함.

merge 충돌 해결

충돌이 일어나면 (브랜치|MERGING) 로 바뀐다

충돌이 일어난 파일을 수정해주고 commit을 해주면 된다.

$git stash 임시 저장을 만든다.

$git stash apply 임시 저장을 다시 불러와 적용한다.

원격 저장소 생성, fork, clone

로컬저장소 생성 후 원격 저장소(github) 생성

원격저장소 생성 - readme.md없이 만들어야 원격저장소 브랜치가 생성되지 않음

$git remote add origin 원격저장소주소 원격 저장소와 연결하며, origin이라는 명칭으로 사용하겠다.

$git push origin 브랜치명 브랜치 push

원격 저장소를 clone하여 가져오기

HTTPS 주소로 clone

$git clone HTTPS주소 [폴더명]

폴더명이 없다면 해당 폴더에, 있다면 추가로 폴더를 생성하고 그안에

원격 저장소에 대한 권한이 있다면 로컬 저장소 내역을 원격 저장소에 즉시 반영가능

브랜치 보호설정을 해놨다면 관리자의 PR허가필요

clone하면 기본적으로 master만 연동되고, 다른 원격 브랜치는 갖고 있기만 한다.

master가 아닌 브랜치는 따로 로컬에서 생성해 연결해주어야 한다.

원격 저장소를 fork하여 가져오기

fork 하게 되면 내 원격저장소에 프로젝트가 생성된다.

fork이후 clone을 통해 사용하면 된다.

fork한 프로젝트는 PR를 통해 기여할 수 있다.

Pull Request - 협력자가 원본 저장소의 관리자에게 merge를 요청하는 과정으로 협력자가 관리자에게 승인을 허가하도록 요청하는 것이다.

최종 merge는 원본 저장소의 관리자가 요청을 승인해야 merge 된다.

PR 방법

base: fork한 기존 프로젝트 / branch   <-----  head: fork한 내 저장소 프로젝트 / branch

브랜치를 새로 생성 후 commit 정리하고 PR요청

PR요청 전에  rebase dev 까지 해서 정리하고 PR. 바로 merge되도록.

요청하는쪽에서 정리하는 것이 바람직

PR이 허가되면 Main 브랜치에 merge된다.

원격 저장소 push & pull

$git ls-remote, git branch -r

원격저장소 branch를 보여준다.

Download

$git fetch --all
원격 저장소 모든 branch 다운로드

새로운 원격 branch가 있다면 알려준다.

$git fetch origin {원격브랜치}

원격 저장소 브랜치 하나만 다운로드

fetch한 branch로 checkout하고, 내용을 확인할 수 있다.

$ git merge {origin/원격브랜치}

다운로드한 브랜치와 merge한다.

$git pull origin {원격브랜치}

하나의 원격브랜치만 다운로드 & merge 하고자 할 때 사용한다.

기존 브랜치와 동기화를 해놨다면 merge된다.

* 주의: HEAD branch와 merge되므로 원하는 branch로 checkout한 후 진행해야 한다.

$git checkout {로컬브랜치} {origin/원격브랜치}

최초 동기화로 로컬 브랜치를 생성해서 원격 브랜치를 동기화

== git switch 원격브랜치

원격 저장소에 새로운 브랜치가 있을 때 로컬에도 새로운 브랜치를 만들어 동기화하여 사용하는 것이 정석

Upload

$git push origin {로컬브랜치 }

로컬 브랜치를 원격 저장소에 브랜치로 업로드

원격 저장소에 브랜치가 있다면 반영, 없다면 생성

$git push origin {로컬브랜치:원격브랜치}

브랜치이름이 다를 경우

$git push --all 

모든 브랜치를 원격 저장소에 올린다.

$git push origin --delete {원격브랜치}

원격 브랜치를 삭제한다.

$git push -f origin {브랜치}

로컬 브랜치에 맞게 원격 브랜치를 강제 수정할 때

리눅스 명령어

https://dora-guide.com/linux-commands/

[Git] Sourcetree rebase 재배치

rebase - 말 그대로 분기의 베이스(시작 위치)를 바꾸겠다는 말이다.

rebase와 merge는 브랜치를 합치는 역할이다.

merge를 쓰겠다면 굳이 쓰지 않아도 된다.

하지만 rebase만의 장점이 있다.

rebase가 merge보다 commit log가 깔끔해진다는 장점이 있다.

주의: 이미 공유된 커밋(main)은 리베이스하면 안된다. (커밋 해시 값이 변경됨)

main, newFunc 두 개의 브랜치가 있다.

base는 initial commit 이다.

브랜치 1, 브랜치 2가 각자 커밋이 진행하면

두 브랜치는 initial commit기점으로 하여 갈라지는 형태가 된다.

이 상태에서 rebase를 실행하려고 한다.

rebase를 하면 발생 문제 상황

 (1) 충돌이 나지 않는 경우

(2) 충돌이 나는 경우

(1) 충돌이 나지 않는 경우

rebase를 할 때는

현재 HEAD로 어떤 브랜치를 하고 있는지,

어떤 브랜치를 rebase로 사용할 것인지가 중요하다.

해당 사진은 브랜치 newFunc가 브랜치 main을 rebase 한 결과다.

newFunc(HEAD) -> rebase main

newFunc을 기준으로 main의 모든 커밋 내용들을 rebase됐다.

main에서는 newFunc까지 fast-forward 가능한 한줄기가 된다.

결과는 main commit내역이 밑으로 깔리고,

그 위로 newFunc가 이어서 작업한 것과 같은 형태가 된다.

rebase main

main의 마지막 commit을 새로운 base로 사용하겠다는 의미

main은 보통 공유하므로 rebase main을 하면 안된다.

rebase newFunc

newFunc의 마지막 commit을 새로운 base로 사용하겠다는 의미

rebase 대상을 HEAD branch 밑에 둔다

(2) 충돌이 나는 경우

충돌을 내기 위해 브랜치 newFunc와 브랜치 main이 같은 파일을 변경하고 커밋을 진행

이 상황에서 rebase를 하면 같은 파일을 변경했으므로 충돌이 일어난다.

newFunc(HEAD) -> rebase main

주의할 점은 newFunc(HEAD)에서 main을 rebase 했는데, 

병합 결과는 main(HEAD)로

HEAD가 바뀌어 나온다는 것이다.

이유는 rebase를 실행하면 HEAD가 main브랜치의 커밋 m1으로 이동한다.

그 후 지정하려는 main의 마지막 commit 부터 newFunc 브랜치의 커밋들을 위로 순차적으로 병합하게 된다.

현재 시점이 (m1)을 가르킨 상태에서 (1)을 병합하므로

HEAD(시점)은 (m1)이고 충돌은 (1)이 잡히는 것이다.

마찬가지로 (1)과의 병합을 마쳤다면 (2)를 병합을 해야한다.

cli 명령어

git rebase --continue

충돌이 발생하면 시점(HEAD)을 rebase로 하려는 브랜치로 옮기고 해당 위치부터

위로 순차적으로 기존 HEAD였던 브랜치의 커밋들을 병합하는 것이다. 

commit 로그 축약하기

interactive rebase

git rebase -i HEAD~3

커밋 3개 관리

명령어를 입력하면 나오는 화면

가장 최신 커밋 내용은 유지한채 최신 커밋을 줄인다. s (squash)

(pick)으로 3개의 커밋들을 병합

가장 아래가 최신 커밋 (내용은 유지하고, 커밋만 없앤다.)

https://meetup.toast.com/posts/39

[Git] Sourcetree stash 스태시 사용법

브랜치1에서 작업도중 브랜치2로 급하게 이동하여 작업해야할때 

브랜치1의 작업내용을 커밋하지 않으면 브랜치2로 이동이 불가능하다.

현재 브랜치1에서의 작업 내용을 커밋하여 남기고 싶지 않을 때

임시 저장으로 stash를 이용하면 브랜치를 이동할 수 있다.

현재 newBranch에서 작업중이고, newBranch useless 파일을 임시저장 하고싶을 때

newBranch useless 파일을 stage에 올린 후 스태시를 클릭한다.

임시로 저장하게 되면 main 브랜치로 이동가능하다.

이동 후 작업을 마쳤다면 다시 작업하던 브랜치로 돌아와

스태시에 해당 임시 저장 내용을 눌러 다시 불러 사용하면 된다.

CLI 명령어

git stash

git stash pop

git stash list

git stash apply stash@{N}

Github를 이용하여 웹 호스팅하기

Github web hosting service를 하기 이전에 알고 있어야 할 개념

-github는 정적 웹사이트 호스팅만 지원한다.

동적 웹사이트와 정적 웹사이트의 차이점

정적 웹사이트 (HTML, CSS, JS)

 - 클라이언트가 요청한 자원을 그대로 반납해준다.

동적 웹사이트 - (PHP, JSP, ASP, MySQL)

 - 클라이언트가 요청한 자원에 데이터를 가공 후 응답해준다.

 - 동적 자원은 WAS(web application service)에서 관리한다.

간단하게 말하면 동적 웹사이트란 데이터베이스를 이용하는 웹사이트이다. github에서는 동적 웹사이트를 무료 호스팅 해주지 않는다. github에서 동적 웹사이트를 호스팅 하기 위해서는 유료 호스팅 서비스를 신청해야만 웹사이트에서 데이터베이스까지 이용가능하게 된다.

GITHUB를 이용하여 웹 호스팅 하는방법

먼저 GITHUB를 가입하여 이메일인증을 한 후 이용해야 합니다.

New버튼을 클릭하여 새로운 저장소를 생성한다.

Repository name에 원하는 저장소 이름을 입력한다.

Initialize this repsitory with a README를 체크해줘야 웹 호스팅 서비스가 가능하다.

위 과정을 다 마쳤다면 Create repository를 클릭하여 저장소를 생성한다.

만들어진 해당 저장소에서 Settings 메뉴란을 클릭

쭉 내리다 보면 GitHub Pages에서 Source를 master로 설정하면 호스팅 된 주소를 받을 수 있다.

[Git] SourceTree, cli Git 커밋 되돌리기

커밋을 되돌리는 방법 3가지

1. reset

2. 브랜치 생성

3. revert

1. reset을 이용하여 되돌리는 법

reset은 기본적으로 커밋 기록을 전부 없앤다.

파일의 변경 사항 유지는 사용자가 선택할 수 있다.

commit 2 로 돌아가기 위해 "이 커밋까지 현재 브랜치를 초기화"를 선택한다.

원하는 option을 선택

reset option 3가지

soft - 커밋 없애고, 파일 변경 사항은 유지 (add 이후 상태)

mixed - 커밋 없애고, 파일 변경 사항은 유지 (add 이전 상태)

hard - 커밋 없애고, 파일 변경 사항도 전부 없앤다.

1 - 2. 원격 저장소 브랜치가 있을 경우

원격 저장소 브랜치는 commit 4에 있으므로 commit 2의 내용으로 다시 push 해야한다.

Sourcetree가 강제push를 지원하지 않으므로 터미널에서 git push --force를 입력한다.

원격 저장소까지 commit 2 로 성공적으로 되돌아갔다.

reset --hard는 이후 커밋들이 전부 지워지므로 그다지 추천하는 방법은 아니지만 혼자 작업한다면 유용하다.

cli 명령어

$git reset --hard 커밋해시값

$git push -f  [원격저장소명칭]  [원격브랜치]

hard로 인해 지워진 commit을 되돌리는 방법

$git reflog 를 입력하면 이전까지 모든 내역들이 나온다.

해시값을 선택해서 

$git reset --hard [되돌릴 해시값]

reset --hard를 진행했어도 되돌릴 수 있다.

2. 브랜치를 생성하여 되돌리는 법

commit 2에 해당되는 곳의 내용으로 되돌아 가려고 한다.

commit 2에 새로운 브랜치를 생성하고, 파일 내용을 변경하여 commit을 수행한다.

commit2의 commit 완료하고, main 브랜치와 병합하려고 하면 충돌이 발생한다.

원하는 파일내용으로 충돌을 해결해 준 후 commit을 한다.

commit 2의 내용으로 성공적으로 병합을 완료하였다.

newBranch에서 main을 병합했지만,

main에서 newBranch를 병합하는 작업도 HEAD만 옮겨주면 같은 방식으로 할 수 있다.

cli 명령어

$git checkout -b [생성할브랜치명] [커밋해시값]

$git merge main

3. revert를 이용하여 되돌리는 법

revert는 되돌릴 때마다 새로운 커밋을 생성한다.

커밋을 없애는 것보다 생성하는 것이 안전하기 때문에 협업시 사용한다.

3-1. 순차적으로 되돌리기

commit3을 사용하기 위해 "커밋 되돌리기"를 선택한다.

새로운 커밋이 생성되며 commit3의 내용으로 돌아갔다.

이번엔 commit3 을 커밋 되돌리기하여 commit2의 내용을 사용하려한다.

커서를 이전과는 다르게 자신의 위치에서 커밋 되돌리기를 수행하지 않고 그 아래 커밋에서 커밋 되돌리기를 선택한다.

commit2의 내용으로 변경되어 커밋되었다.revert를 수행하면 커밋이 되고,

이전 커밋내역이 지워진다.

순서는 위에서부터 순차적으로 되돌리길 원하는 커밋내역까지 되돌려줄 수 있다.

3-2. 커밋 내역을 골라서 취소하고 싶을 때

commit 2를 취소하고 싶은 경우 commit2 를 revert(커밋 되돌리기) 하여 충돌을 해결하고 커밋해주면 된다.

중간 부분 내역만 사라지고 그 이후는 유지된다.

cli 명령어

$git revert [취소할커밋값]

$git revert head~N  (N번째가 취소되는 커밋)

restore

add 실수 시 unstaging file 만들기

git restore --staged 파일명

수정 사항 원본으로 되돌리기

git restore 파일명

일부 파일만 이전 커밋으로 되돌리기

git restore --source head~N 파일명