직장인 일기장

gbsb.tistory.com/9?category=622870

Git을 이용하려면 두가지 방법이 있다.

• SourceTree라는 Git GUI 툴을 이용한 Git
• Git Bash를 이용한 Git

SourceTree를 이용하면 GUI 툴이기에 접근하기에는 편하지만, 리눅스는 지원이 안되고 좀 더 디테일한 명령어를 다룰 수 없다. 따라서 보기엔 불편하지만 Git Bash를 이용하는 것이 낫다고 생각한다. (그리고 얘가 좀 더 간지난다)

지금부터 첫번째 방법에 대해서 알아보자.

1. Git & SourceTree 설치

• Git 설치 : https://git-scm.com/
• SourceTree 설치 : https://www.sourcetreeapp.com/

2. 테스트할 저장공간 만들기

Git과 SourceTree를 연동하여 소스를 관리하려면, 테스트할 저장공간이 필요하다. 내 경우는 C:\gbsb\project1 폴더에 index.html이라는 파일을 만들었다. 

[index.html]

3. 새 저장소 만들기(init 명령어)

이제 SourceTree을 열어보자. 지금부터 SourceTree에서 Git에게 추적당할 로컬 저장소를 만들 것이다.

아래는 저장소가 만들어진 모습이다.

노란색으로 표시한 부분은 Git과 이것저것 연동하는 부분이고, 빨간색으로 표시한 부분은 C:\gbsb\project1 저장소의 안에 있는 파일들을 보여준다.

Staging Area는 Git에게 추적되는 공간이고, Working Directory는 Git에게 추적되지 않는 공간이다. 현재 워킹 디렉토리에는 아직 추적되지 않은 index.html 이 보인다.

이 아이콘은 새로운 파일이 등록되었을 경우다. (아직 Git이 추적하기 전)

이 아이콘은 새로운 파일은 최초로 커밋하면 Git이 추적을 시작한다. (즉 저장소에 저장된다)

아직까지 Git은 이 디렉토리 안의 파일의 내용이 변경되었는지 추적하지 않는다.

4. 버전 만들기(commit 명령어)

처음으로 커밋을 시도한다면, 계정을 입력하라는 알림이 뜰 것이다. [Tools] > [Options] > Dafault user infomation에서 계정을 추가한 뒤, 아래의 단계를 실행하여 커밋해보자.

이제 커밋이 완료되었다. 왼쪽엔 master브랜치가 생성되었고, 오른쪽엔 커밋할 때 작성한 이력, 날짜 등이 보여진다.

이번에는 소스파일을 변경한 후 커밋해보자. 나는 index.html 파일에 한 줄을 추가하고 저장하였다.

[index.html]

그 다음에 소스트리 목록을 보면 'Uncommitted changes', 즉 커밋되지 않은 변화가 추가되었다. (안보일 경우 F5 새로고침) 이번에도 아까와 같은 방식으로 커밋을 하면 된다.

커밋을 하니, 저장소로 등록한 C:\gbsb\project1 내의 파일들이 Git에게 추적되어 보여지고 있다.

5. 되돌리기(discard, reset, revert 명령어)

작성한 파일을 다시 되돌릴 수 있는 3개의 방법이 있다. (파일을 되돌려보기 위해 index.html 파일에 이것저것 내용을 변경하려고 한다.)

1) Discard (커밋하기 전, 되돌리기)

Staging Area 목록에서 되돌릴 파일을 선택한 뒤 [Discard] 버튼을 클릭하면 창이 뜬다. [Discard Changes] 버튼을 클릭하면 최종 커밋된 버전으로 돌아간다.

2) Reset (커밋해버린 후, 버전을 제거하고 되돌리기)

목록에서 되돌아가고 싶은 버전을 선택하고 마우스 우클릭한 뒤, 'Reset current branch to this commit'을 선택하면 아래의 창이 뜬다.

• Soft 모드
• Mixed 모드 : 선택한 버전 이후의 모든 버전이 사라지지만 Working Directory에 남겨진다. 또한 작업중이던 Working Directory의 상태는 유지된다. (소스에 중요한 정보가 들어가 있을 때 사용)
• Hard 모드 : 선택한 버전 이후의 모든 버전이 삭제된다. Working Directory와 Staging Area 공간에 있는 파일도 모두 삭제된다.

3) Revert (커밋해버린 후, 버전을 제거하지 않고 되돌리기)

버전을 제거하지 않고, 새로운 커밋을 생성하여 이전 상태로 되돌린다. 목록에서 되돌아가고 싶은 버전을 선택하고 마우스 우클릭한 뒤 'Reverse Commit'을 선택한다. 주의할 점은 위에서부터 아래로, 즉 역순으로 차례대로 하나씩 Reverse Commit 해야 충돌이 발생하지 않는다.

6. 브랜치(branch 명령어)

브랜치는 보통 원본과 실험용 프로젝트를 분리해서 만들고자 할 때 사용한다. (예를 들어, 신규기능이나 불확실한 코드를 실험용에서 개발하고자 할 때)

1) 브랜치 만들기

소스트리에서 [Branch] 버튼을 클릭한 뒤 아래의 단계를 실행한다.

이제 브랜치는 총 2개가 존재하게 된다. (master 브랜치, 실험용 브랜치) 지금부터 브랜치 별로 따로 코드를 짜는 것이 가능하다.

2) 브랜치 합치기(merge 명령어)

신규기능 테스트가 끝났다고 가정했을 때, 실험용 브랜치를 master 브랜치로 합쳐보자. 실험용 브랜치를 우클릭한 뒤 'Merge 실험용 into current branch'를 클릭한다. 이를 'master브랜치로 체크아웃 했다'고 말할 수 있다. 브랜치가 잘 합쳐졌는지 확인해보고 싶다면, master브랜치의 소스에 실험용에서 만든 코드가 보이는지 찾아보면 된다.

3) 브랜치간 충돌 해결하기

두개의 브랜치에서 서로 같은 위치의 코드를 변경하고 커밋했을 때 충돌이 발생한다. 아래가 충돌이 난 예시이다. master 브랜치 내의 파일의 3번째 줄을 커밋하고, 실험용 브랜치 내의 파일의 3번째 줄을 커밋한 뒤 master 브랜치로 병합(merge)하자 충돌이 발생한 모습이다.

해결방법은 일단 충돌이 난 부분을 지운뒤, 해당 파일을 우클릭한 뒤 'Resolve Conflicts' > 'Mark Resolved'를 선택한다.
충돌이 해결되었으면 다시 커밋을 하면 된다.

충돌을 줄이기 위해서는, 브랜치를 주기적으로 master의 내용과 동기화하자.

7. GitHub 원격저장소에 연결하기

로컬저장소(C:\gbsb\project1)와 원격저장소를 연결해서 원격저장소에 백업할 수도 있다. 대표적인 원격저장소는 GitHub나 Bitbucket 등이 있다.

1) 원격저장소 만들기

GitHub 페이지에서 'New repository'하여 원격저장소를 만든다.

2) 로컬저장소와 원격저장소를 서로 연결하기

소스트리 메뉴에서 [Repository] > [Add Remote] 를 클릭하면 창이 뜬다. 거기서 [Add]를 클릭하면 아래의 창이 뜬다. 

URL / Path 입력란에 GitHub에 명시된 원격저장소 주소를 붙여넣고 [Ok] 버튼을 누르자. 이제 로컬저장소와 원격저장소가 연결되었다. 하지만 아직 동기화 되지 않은 상태다. 소스트리에서 [Push]를 클릭하고 아래의 단계를 실행한다.

3) 원격저장소로 업로드 하기

방금전 실행한 [Push] 기능이 로컬저장소에서 원격저장소로 업로드하는 방법이다.

8. 협업하기

Git과 GitHub를 통해 사람들끼리 협업해야 할 때가 있다. (예를 들어, 새로 입사한 신입이 원격저장소에서 로컬컴퓨터로 프로젝트를 가져와야할 경우) 

소스트리의 [File] 메뉴에서 [Clone/New]를 선택한다. 아래와 같은 순서로 실행하면 원격 저장소가 복제된다.

하나의 원격저장소를 두고 각자 작업을 진행해야 할 경우가 있다. 작업 시작하기 전에 Pull을 먼저 실행해야 한다. 작업 순서는 pull -> work -> commit -> pull -> push 순으로 진행하자.

gbsb.tistory.com/10

Git을 이용하려면 두가지 방법이 있다.

• SourceTree라는 Git GUI 툴을 이용한 Git
• Git Bash를 이용한 Git

SourceTree를 이용하면 GUI 툴이기에 접근하기에는 편하지만, 리눅스는 지원이 안되고 좀 더 디테일한 명령어를 다룰 수 없다. 따라서 보기엔 불편하지만 Git Bash를 이용하는 것이 낫다고 생각한다. (그리고 얘가 좀 더 간지난다)

지금부터 두번째 방법에 대해서 알아보자.

기본적인 명령어

• 화면 초기화 : Ctrl + L
• 한 행의 처음과 끝 : Ctrl + A, Ctrl + E
• 목록 보기 : ls 또는 dir
• 파일의 내용 보기 : cat
• 특정 문자를 검색 : grep
• 디렉터리로 이동 : cd
• 디렉터리 생성 : mkdir
• 파일 삭제 : rm
• 파일 생성 : touch

git config (최초 1회 실행)

git init

현재 디렉토리를 로컬저장소로 설정한다.

git status

로컬저장소의 현재 상태를 보여준다.

git add

파일을 준비영역(Staging Area)으로 옮긴다. (GitHub와 연동하려면 git remote로 원격 저장소와 연결해야 함)

git commit

준비영역(Staging Area)의 파일을 로컬저장소에 저장한다.

git log

로컬저장소의 커밋 이력을 조회한다.

git remote

로컬저장소와 원격저장소를 연결한다.

git push

원격저장소에 저장한다.

아래부터는 좀 더 심화된 내용이다.

git diff

워킹 디렉터리와 다른 커밋을 비교한다.

1) 현재 브랜치의 마지막 커밋과의 차이점 비교
$git diff

2) 특정 커밋과의 차이점 비교
$git diff [Commit ID]

3) 특정 커밋과 특정 파일의 차이점 비교
$git diff [Commit ID] -- [파일 경로]

git branch

브랜치를 생성, 수정, 삭제 등을 한다.

1) 브랜치 보기
$git branch

2) 브랜치 생성
$git branch [브랜치명]

3) 브랜치 수정
$git branch -m [브랜치명] [바꿀이름]

4) 브랜치 삭제
$git branch -d [브랜치명]

git checkout

워킹 디렉터리의 소스를 특정 커밋 또는 특정 브랜치로 변경한다.

1) 특정 브랜치로 워킹 디렉터리 변경
$git checkout [브랜치명]

2) 특정 커밋으로 워킹 디렉터리 변경
$git checkout [Commit ID]

3) 특정 파일을 해당 브랜치 또는 커밋 상태로 변경 (원복)
$git checkout [돌아갈 Commit ID] -- [파일 경로]
*충돌 방지를 위해 브랜치명을 확인하고, 파일 추가 및 수정한 뒤 커밋해야 한다.

4) 브랜치 생성 및 체크아웃을 같이 할 경우
$git checkout -b develop

git merge

다른 두개의 브랜치 소스를 병합한다.

$git checkout master
$git merge develop
*같은 파일의 같은 위치의 내용이 변경된 경우 충돌이 발생한다.

#Merge란

로컬저장소에 패치로 받아온 커밋기록(변경된 소스코드)과 자신의 소스코드를 합치는 작업

fast-forward : 변경내용이 있는 브랜치(작업단위)가 더 최신 내용을 담고 있고,

                  병합하려는 브랜치의 내용을 전부 포함하고 있는 경우

ff란 fast-forward의 약자이다

$ git merge 브랜치명 : 일반적인 병합

$ git merge --no-ff 브랜치명 : 현재 브랜치와 병합대상의 관계가 Fast-forward던 아니던 무조건 병합

$ git merge --ff-only 브랜치명 : 현재 브랜치와 병합대상의 관계가 무조건 Fast-forward일 때만 병합

$ git merge --squash 브랜치명 : 현재 브랜치의 병합대상과 차이나는 커밋을 하나로 병합

#이클립스에서의 Merge

Merge옵션

• Commit : 병합 커밋(리모트로 부터 패치를 해서 변경사항이 있을 경우 내용을 하나로 통합함)
• No Commit : 병합 커밋을 준비하지만 커밋은 하지 않음
• Squash : Merge할 브랜치의 커밋을 하나로 합친뒤 타겟 브랜치에 커밋하는 방식

Fast forward option

• If a fast-forward, only update the branch pointer : fast-forward일 경우 브랜치 포인터 업데이트
• If a fast-forward, create a merge commit : fast-forward일 경우 병합 커밋을 생성
• If not a fast-forward, fail : fast-forward가 아닐경우 병합하지 않음

fast-forward : 변경내용이 있는 브랜치(작업단위)가 더 최신 내용을 담고 있고,

                  병합하려는 브랜치의 내용을 전부 포함하고 있는 경우

깃허브에서는 소스코드를 합칠때 2가지 방식이 존재하는데

Marge와 Rebase이다

둘다 소스코드를 병합한다는 점은 동일하나

Marge는 각각의 개발자들의 브랜치(작업단위)별 커밋 기록을 유지하면서 병합

Rebase는 각각의 개발자들의 브랜치(작업단위를)별 커밋 기록은 하나로 병합

Merge의 장점

• 브랜치(작업단위)별 커밋기록을 유지함(장점이자 단점)
• 경합같은 소스코드 충돌이 일어났을때 복구가 간단함
• 크게 신경 쓸필요 없음

Merge의 단점

• 개발자가 많아지면 커밋기록이 중구난방해서 히스토리 관리가 어지러움

Rebase의 장점

• 커밋기록을 하나로 합치기 때문에 히스토리 관리가 간편함

Rebase의 단점

• 코드 충돌이나 경합이 일어 났을  때 복잡해짐 

현업에서는 기본적으로 Merge를 사용한다

경합이나 소스코드 충돌났을때는 작업한 소스코드를 대피시키고 리모트에서 소스코드를 최신으로 갱신해서

대피시킨 코드를 중복이 있나 비교해서추가 하는방법도 있다

backlog.com/git-tutorial/kr/intro/intro1_1.html

#개념

깃의 구조는 

작업환경-준비영역-로컬저장소(로컬 리포지토리)-리모트 저장소(리모트 리포지토리, Origin)

이렇게 4단계로 구분된다

작업환경 : 현재 작성중인 코드(준비영역으로 이동 전)

준비영역 : Add를 한 파일(로컬 저장소로 이동 전)

로컬저장소 : Commit을 한 파일(리모트 저장소로 이동 전)

리모트저장소 : Push한 파일(메인 서버)

Git은 준비영역부터 파일을 인식한다

이렇게 단계로 구분되는 이유는 여러사람과의 작업간에 소스코드 충돌을 막기 위함이다

또한 여러사람이 동시에 네트워크에 액세스 할경우 속도가 느려지지만

깃의 경우 리모트 저장소에 푸시 할 경우 외엔 네트워크를 쓸일이 없기때문에 작업속도가 빠르다

#용어 설명

Branch(브랜치) : 개인 작업 단위

Origin(오리진) : 리모트 저장소 이름(주소), 리모트 리포지토리(Repository) 라고도 부른다

Master(마스터) : 브랜치(작업단위) 중 가장 중심이 되는 브랜치

Head(헤드) :  자신이 현재 작업중인 브런치

Commit(커밋) : 생성, 수정,삭제 된 소스코드를 준비영역에서 로컬 저장소에 보냄
Push(푸시) : 커밋기록(커밋으로 로컬 저장소에 보낸 소스코드)을 로컬 저장소에서 리모트로 보냄
Fetch(패치) : 리모트 저장소에서 최신의 커밋기록(다른 브랜체에서 작성, 수정한 소스코드)를 로컬 저장소로 반영

PULL(풀) : 푸시 + 패치를 동시에 진행
Merge(병합) : 로컬 저장소에서 패치로 갱신한 커밋기록(소스코드)을 자신의 브랜치와 합침,

                   브랜치(작업단위)별 커밋 기록은 합쳐지지 않음

Reset(리셋) : 마지막으로 Merge(병합) 했던 시점으로 복원한다, 시점을 지정해서 복원할 수도 있다

Rebase(리베이스) : 로컬 저장소에서 패치로 갱신한 브랜치를 자신의 브랜치와 합침

                         브랜치(작업단위)별 커밋 기록도 합쳐짐

#사용법

이클립스에서 작성한 소스코드가 존재하는 곳이 #작업환경이며

Add를 하고 #준비영역에 추가

Commit을 하면 새롭게 작성,수정한 코드를 묶어서 #로컬 저장소로 전송된다

첫번째 커밋은 커밋1

두번째 커밋을 커밋2

이렇게  로컬 저장소에 보관되며

그리고 푸시를 하면 커밋 기록(작성, 수정한 소스코드)이 #리모트 저장소로 전송된다

풀을 하면 커밋+푸시 작업이 동시에 진행된다

자신이 작성한 코드의 커밋은 작성자 본인의 이름으로 보내진다

패치는 자신의 브랜치버전을 리모트 저장소와 비교해 가장 최근 커밋된 수정,반영된 커밋 기록(소스코드)을

나의 로컬저장소로 가져오는 작업이며

Merge를 하면 내 작업환경에 있는 자신의 브랜치(자신이 작업하던 소스코드)와 병합되어 작업환경에 저장된다

이때 같은 경로에 같은 파일이 존재하게 되면 병합이 실패한다

SI에서 작업과정은

작업표에서 자신이 개발할 설계도를 선택하고 

패치를 해서 리모트 저장소에서 최신의 소스코드를 갱신해 자신이 작업할 클래스와 메서드가 

중복되는지 확인하고 없다면 Merge(병합)을 해서 자신의 브랜치(소스코드)를 합친다

그후 작업을 진행

작업이 완료되면 다시한번 패치를 해서 나와 중복되는 작업이 있는지 확인한다

(패치를 했는데 실패하거나 같은 메서드가 보이면 충돌이 일어나게 된다, 이것을 경합(충돌)이라고 함)

이럴 경우 프로젝트 매니저에서 문의해 둘중 하나를 지운다

#경합(충돌)이 나면 깃 사용에 문제가 생기는데

마지막으로 자신이 작업한 로컬 저장소 기록으로  리셋을 하면 복구된다

문제가 없다면 커밋+푸시 or Pull을 해서  로컬 저장소로 소스코드를 보내는 것으로 

작업은 종료된다