'전체 글'에 해당되는 글 203건

  1. 2015.06.30 자바 스레드의 이해
  2. 2015.06.30 자바 메모리 구조 >>> 2
  3. 2015.06.30 자바 메모리 구조>>1
  4. 2015.06.30 GC - Garbage Collection 이란?
  5. 2015.06.18 Git에 대한 이해

자바 스레드의 이해

JAVA 2015. 6. 30. 15:44

앞써 설명한 자바의 메모리 구조에서 


T메모리 구조(스태틱영역, 스택영역, 힙영역으로 구성되는 것을 그냥 T메모리 구조라고 부름)에 대해서 설명했다.





스레드란 무엇인가?

스레드는 스택영역을 스레드의 개수만큼 분할하는 것이다.

또한 각각의 스레드는 다시 스태틱영역, 스택영역, 힙영역을 가지게 된다.

스택영역이 분할되므로 스레드 간의 스택영역을 침범 할 수는 없지만 

큰 측면에서 봤을 때 결국 자바 메모리의 스태틱영역과 힙영역은 공유 할 수 있다!


멀티프로세스 vs 멀티스레드


멀티 프로세스(Multi Process)

하나의 프로세스가 다른 프로세스의 T메모리 영역을 절대 침범 할 수 없는 메모리로써 안전한 구조이지만, 그만큼 메모리 사용량을 크다!


멀티 스레드(Multi Thread)

스택영역이 분할되어 하나의 스레드에서 다른 스레드로 접근 할 수는 없지만 스태틱 영역과 힙 영역은 공유해서 사용 할 수 있다. 따라서 멀티 프로세스 대비 메모리를 적게 사용 할 수 있는 구조이다.


서버 프로그래밍에서 Servlet은 요청 당 스레드를 생성한다고 들어봤다

** Servlet 과 CGI??

요청 당 스레드를 생성 => Servlet

요청 당 프로세스 생성 => CGI


OS시간에도 배웠지만 

스레드가 Critical Section을 접근하는 것에 대한 문제를 해결해야 한다.

다음과 같은 문제가 있다.

 스레드1

 스레드2

 

 전역변수 A에 10 할당

 

 전역변수 A는 10을 저장

 

 전역 변수 A에 20할당

 전역변수 A는 20을 저장

 전역변수 A의 값 출력

 

 전역변수 A는 20을 출력


스레드1이 A에 분명 10을 할당했는데, 후에 바로 스레드2가 20을 할당해버리므로

예상치 못한 결과를 얻어낸다.


이러한 공유 자원을 관리하는 자바만의 방법이 있는지 알아보고 후에 글을 적겠다.

'JAVA' 카테고리의 다른 글

자바가 확장한 객체지향  (0) 2015.06.30
자바와 객체지향  (0) 2015.06.30
자바 메모리 구조 >>> 2  (0) 2015.06.30
자바 메모리 구조>>1  (0) 2015.06.30
GC - Garbage Collection 이란?  (0) 2015.06.30
Posted by slender ankles
,

자바 메모리 구조 >>> 2

JAVA 2015. 6. 30. 15:44

자바 프로그램의 구동 환경에 대해서 다시 한 번 정리하고자 한다.

자바개발도구 JDK , 자바실행환경 JRE, 자바가상기계 JVM 으로 이루어져 있다.




간단히 말해서 자바 개발 도구로 개발된 프로그램이

자바실행환경에서 해석되어 자바가상기계 위에서 동작하는 것이다.

당연 플랫폼에 종속적이지 않는 장점을 가지게 된다.

(윈도우, 리눅스 등 OS에 영향 없이 한 개의 코드로 모두 실행 가능하다)


이를 그림으로 나타내면 다음과 같다.




보통의 프로그램들에서의 메모리 구조는


코드실행영역과 데이터 저장 영역으로 나뉜다.


자바와 같은 객체 지향 프로그램에서는 다음과 같이 데이터 저장 영역이


1) 스태틱 영역(클래스들의 놀이터)

2) 스택 영역(메서드들의 놀이터)

3) 힙 영역(객체들의 놀이터)


으로 나뉜다.








** "Hello World"라는 것을 출력하는 프로그램을 통해 JVM이 어떻게 프로그램을 구동시키는 지에 대해서 알아보겠다.




1) 자바 프로그램이 시작하여 먼저 main()함수가 있는지를 확인 한 후에

전처리 과정을 실시한다. 전처리 과정이라함은 자바에 반드시 포함되는 java.lang클래스를 스태틱영역에 올리는 것이다.그리고 개발자가 만든  클래스들과 import한 클래스들을 스태틱영역에 올린다.





2) 스택영역에 main함수가 할당된다.

3) 스택영역에 main함수의 인자인 args가 할당된다.






4) println과 같은 메소드는 메모리 구조에 큰 변화가 일어나지 않지만 GPU를 통해 화면에 출력하는 동작을 하게 된다.





5) } 이라는 main()메소드의 끝과 함께 스택영역에 할당된 스택프레임이 소멸된다.




* Main()메서드가 스택영역에 올라가면서 주요 로직이 동작하게 된다.



와 같은 코드에서도 순서대로 


1) i라는 변수가 스택에 할당(현재 쓰레기값)

2) i에 20이 할당

3) j 라는 변수가 스택에 할당

4) j라는 변수에 30이 할당

5) i 에 i의 값과 j의 값이 합해짐

main()메서드 종료되면서 없어짐


과 같이 동작하게 된다.


static 변수 즉 전역 변수는 static영역에 할당된다.

'JAVA' 카테고리의 다른 글

자바가 확장한 객체지향  (0) 2015.06.30
자바와 객체지향  (0) 2015.06.30
자바 스레드의 이해  (0) 2015.06.30
자바 메모리 구조>>1  (0) 2015.06.30
GC - Garbage Collection 이란?  (0) 2015.06.30
Posted by slender ankles
,

자바 메모리 구조>>1

JAVA 2015. 6. 30. 15:43

자바를 시작하기에 앞서 자바의 메모리의 구조에 대해서 알아야한다.

자바의 메모리 구조를 통해서 자바만이 가지고 있는 identity(아이덴티티)에 대해서 알아본다면 

자바를 탄탄하게 시작 할 수 있을 것이라 생각한다.



1. 자바 버츄얼 머신(Java Virtual Machine, JVM)이란 무엇이며, 그 특징이 무엇인지에 대해서 알아본다.

JVM하면 떠오르는 것은 플랫폼 종속적이지 않은 자바의 특징을 보여주는 것...정도로만 알고 있었다. 

JVM은 자바로 만들어진 모든 프로그램(일반 어플리케이션, Web Application Server(WAS) 등)을 실행하는 역할을 한다. 구별하지 않고 모든 자바 프로그램들은 JVM을 거쳐야 한다는 것이다. 

JVM이 왜 자바의 핵심인지가 설명 할 수 있는 대목


JVM이 가지고 있는 특징은 

1) 스택기반 가상머신이란?

대표적인 컴퓨터 아키텍처인 인텔 x86 아키텍처나 ARM 아키텍처와 같은 하드웨어가 레지스터 기반으로 동작하는 데 비해 JVM은 스택 기반으로 동작한다.

2) 심볼릭 레퍼런스

기본 자료형(primitive data type)을 제외한 모든 타입(클래스와 인터페이스)을 명시적인 메모리 주소 기반의 레퍼런스가 아니라 심볼릭 레퍼런스를 통해 참조한다.

3) 가비지 컬렉션(Garbage Collection)

클래스 인스턴스는 사용자 코드에 의해 명시적으로 생성되고 가비지 컬렉션에 의해 자동으로 파괴된다.

4) 기본 자료형을 명확하게 정의하여 플랫폼 독립성 보장

C/C++ 등의 전통적인 언어는 플랫폼에 따라 int 형의 크기가 변한다. JVM은 기본 자료형을 명확하게 정의하여 호환성을 유지하고 플랫폼 독립성을 보장한다.

5) 네트워크 바이트 오더(Network Byte Order)

자바 클래스 파일은 네트워크 바이트 오더를 사용한다. 인텔 x86 아키텍처가 사용하는 리틀 엔디안이나, RISC 계열 아키텍처가 주로 사용하는 빅 엔디안 사이에서 플랫폼 독립성을 유지하려면 고정된 바이트 오더를 유지해야 하므로 네트워크 전송 시에 사용하는 바이트 오더인 네트워크 바이트 오더를 사용한다. 네트워크 바이트 오더는 빅 엔디안이다.



자바의 환경!







2. JVM에 의해 자바 메모리 구조가 어떻게 작동되는지에 대해서 알아야 한다.

JVM이 어떤식의 구조로 되어 있고, 이를 통해 Java GC가 어떻게 일어나는지에 대해서 이해할 수 있게 될 것이다.



[자바 프로그램]

Java에서 프로그램을 실행한다는 것은 Class 파일을 JVM으로 로딩하고 ByteCode를 해석(Interpret)하는 작업은 물론,

메모리 등의 리소스를 할당하고 관리하며 정보를 처리하는 일련의 작업들을 포괄한다. 

이 때 JVM은 스레드 관리 및 Garbage Collection과 같은 메모리 재생 작업도 수행한다. 



[JVM의 기본적인 수행과정]

1. Class Loader System을 통해 Class 파일들을 JVM으로 로딩한다.

2. 로딩된 Class 파일들을 Execution Engine을 통해 해석한다. 

3. 해석된 프로그램은 Runtime Data Areas에 배치되어 실질적인 수행이 이루어지게 된다. 이러한 실행 과정 속에서 JVM 은 필요에 따라 Thread Synchronization과 Garbage Collection(GC)와 같은 관리작업을 수행하게 된다. 



클래스 로더(Class Loader)가 컴파일된 자바 바이트코드를 런타임 데이터 영역(Runtime Data Areas)에 로드하고, 실행 엔진(Execution Engine)이 자바 바이트코드를 실행한다.


클래스 로더

자바는 동적 로드, 즉 컴파일타임이 아니라 런타임에 클래스를 처음으로 참조할 때 해당 클래스를 로드하고 링크하는 특징이 있다. 이 동적 로드를 담당하는 부분이 JVM의 클래스 로더이다. 

런타임 데이터 영역

런타임 데이터 영역은 JVM이라는 프로그램이 운영체제 위에서 실행되면서 할당받는 메모리 영역이다. 런타임 데이터 영역은 6개의 영역으로 나눌 수 있다. 이중 PC 레지스터(PC Register), JVM 스택(JVM Stack), 네이티브 메서드 스택(Native Method Stack)은 스레드마다 하나씩 생성되며 힙(Heap), 메서드 영역(Method Area), 런타임 상수 풀(Runtime Constant Pool)은 모든 스레드가 공유해서 사용한다.


  • PC 레지스터: PC(Program Counter) 레지스터는 각 스레드마다 하나씩 존재하며 스레드가 시작될 때 생성된다. PC 레지스터는 현재 수행 중인 JVM 명령의 주소를 갖는다.
  • JVM 스택: JVM 스택은 각 스레드마다 하나씩 존재하며 스레드가 시작될 때 생성된다. 스택 프레임(Stack Frame)이라는 구조체를 저장하는 스택으로, JVM은 오직 JVM 스택에 스택 프레임을 추가하고(push) 제거하는(pop) 동작만 수행한다. 예외 발생 시 printStackTrace() 등의 메서드로 보여주는 Stack Trace의 각 라인은 하나의 스택 프레임을 표현한다.
  • 스택 프레임: JVM 내에서 메서드가 수행될 때마다 하나의 스택 프레임이 생성되어 해당 스레드의 JVM 스택에 추가되고 메서드가 종료되면 스택 프레임이 제거된다. 각 스택 프레임은 지역 변수 배열(Local Variable Array), 피연산자 스택(Operand Stack), 현재 실행 중인 메서드가 속한 클래스의 런타임 상수 풀에 대한 레퍼런스를 갖는다. 지역 변수 배열, 피연산자 스택의 크기는 컴파일 시에 결정되기 때문에 스택 프레임의 크기도 메서드에 따라 크기가 고정된다.
  • 지역 변수 배열: 0부터 시작하는 인덱스를 가진 배열이다. 0은 메서드가 속한 클래스 인스턴스의 this 레퍼런스이고, 1부터는 메서드에 전달된 파라미터들이 저장되며, 메서드 파라미터 이후에는 메서드의 지역 변수들이 저장된다.
  • 피연산자 스택: 메서드의 실제 작업 공간이다. 각 메서드는 피연산자 스택과 지역 변수 배열 사이에서 데이터를 교환하고, 다른 메서드 호출 결과를 추가하거나(push) 꺼낸다(pop). 피연산자 스택 공간이 얼마나 필요한지는 컴파일할 때 결정할 수 있으므로, 피연산자 스택의 크기도 컴파일 시에 결정된다.

  • 네이티브 메서드 스택: 자바 외의 언어로 작성된 네이티브 코드를 위한 스택이다. 즉, JNI(Java Native Interface)를 통해 호출하는 C/C++ 등의 코드를 수행하기 위한 스택으로, 언어에 맞게 C 스택이나 C++ 스택이 생성된다.

  • 메서드 영역: 메서드 영역은 모든 스레드가 공유하는 영역으로 JVM이 시작될 때 생성된다. JVM이 읽어 들인 각각의 클래스와 인터페이스에 대한 런타임 상수 풀, 필드와 메서드 정보, Static 변수, 메서드의 바이트코드 등을 보관한다. 메서드 영역은 JVM 벤더마다 다양한 형태로 구현할 수 있으며, 오라클 핫스팟 JVM(HotSpot JVM)에서는 흔히 Permanent Area, 혹은 Permanent Generation(PermGen)이라고 불린다. 메서드 영역에 대한 가비지 컬렉션은 JVM 벤더의 선택 사항이다.
  • 런타임 상수 풀: 클래스 파일 포맷에서 constant_pool 테이블에 해당하는 영역이다. 메서드 영역에 포함되는 영역이긴 하지만, JVM 동작에서 가장 핵심적인 역할을 수행하는 곳이기 때문에 JVM 명세에서도 따로 중요하게 기술한다. 각 클래스와 인터페이스의 상수뿐만 아니라, 메서드와 필드에 대한 모든 레퍼런스까지 담고 있는 테이블이다. 즉, 어떤 메서드나 필드를 참조할 때 JVM은 런타임 상수 풀을 통해 해당 메서드나 필드의 실제 메모리상 주소를 찾아서 참조한다.
  • 힙: 인스턴스 또는 객체를 저장하는 공간으로 가비지 컬렉션 대상이다. JVM 성능 등의 이슈에서 가장 많이 언급되는 공간이다. 힙 구성 방식이나 가비지 컬렉션 방법 등은 JVM 벤더의 재량이다.

실행 엔진

클래스 로더를 통해 JVM 내의 런타임 데이터 영역에 배치된 바이트코드는 실행 엔진에 의해 실행된다. 실행 엔진은 자바 바이트코드를 명령어 단위로 읽어서 실행한다. CPU가 기계 명령어을 하나씩 실행하는 것과 비슷하다. 바이트코드의 각 명령어는 1바이트짜리 OpCode와 추가 피연산자로 이루어져 있으며, 실행 엔진은 하나의 OpCode를 가져와서 피연산자와 함께 작업을 수행한 다음, 다음 OpCode를 수행하는 식으로 동작한다.

그런데 자바 바이트코드는 기계가 바로 수행할 수 있는 언어보다는 비교적 인간이 보기 편한 형태로 기술된 것이다. 그래서 실행 엔진은 이와 같은 바이트코드를 실제로 JVM 내부에서 기계가 실행할 수 있는 형태로 변경하며, 그 방식은 다음 두 가지가 있다.

  • 인터프리터: 바이트코드 명령어를 하나씩 읽어서 해석하고 실행한다. 하나씩 해석하고 실행하기 때문에 바이트코드 하나하나의 해석은 빠른 대신 인터프리팅 결과의 실행은 느리다는 단점을 가지고 있다. 흔히 얘기하는 인터프리터 언어의 단점을 그대로 가지는 것이다. 즉, 바이트코드라는 '언어'는 기본적으로 인터프리터 방식으로 동작한다.
  • JIT(Just-In-Time) 컴파일러: 인터프리터의 단점을 보완하기 위해 도입된 것이 JIT 컴파일러이다. 인터프리터 방식으로 실행하다가 적절한 시점에 바이트코드 전체를 컴파일하여 네이티브 코드로 변경하고, 이후에는 해당 메서드를 더 이상 인터프리팅하지 않고 네이티브 코드로 직접 실행하는 방식이다. 네이티브 코드를 실행하는 것이 하나씩 인터프리팅하는 것보다 빠르고, 네이티브 코드는 캐시에 보관하기 때문에 한 번 컴파일된 코드는 계속 빠르게 수행되게 된다.

JIT 컴파일러가 컴파일하는 과정은 바이트코드를 하나씩 인터프리팅하는 것보다 훨씬 오래 걸리므로, 만약 한 번만 실행되는 코드라면 컴파일하지 않고 인터프리팅하는 것이 훨씬 유리하다. 따라서, JIT 컴파일러를 사용하는 JVM들은 내부적으로 해당 메서드가 얼마나 자주 수행되는지 체크하고, 일정 정도를 넘을 때에만 컴파일을 수행한다.


자바가 느리다고 하는 이유?





'JAVA' 카테고리의 다른 글

자바가 확장한 객체지향  (0) 2015.06.30
자바와 객체지향  (0) 2015.06.30
자바 스레드의 이해  (0) 2015.06.30
자바 메모리 구조 >>> 2  (0) 2015.06.30
GC - Garbage Collection 이란?  (0) 2015.06.30
Posted by slender ankles
,

<참조 - 네이버 개발자 센터 - http://helloworld.naver.com/helloworld/1329>


gc(garbage collection)이란?

gc에 대해 알기 위해서는 stop-the-world 라는 것에 대해서 알아야한다.

stop-the-world란 gc를 실행하기 위해서 jvm애플리케이션이 실행을 멈추는 것이다

gc를 실행하는 스레드를 제외한 모든 스레드는 정지한다. 

결국 gc 튜닝이란 stop-the-world의 시간을 최소로 하는 것을 말한다고 할 수 있다. 


자바 프로그램에서는 메모리를 명시적으로 지정하여 해제 할 수 없다. 

해당 객체를 null로 지정하거나 (이 것은 큰 문제는 안됨)

system.gc()와 같은 함수를 사용하는 방법은 있으나 사용하면 안 된다. 

성능에 지대한 영향을 끼치기 때문이다.


자바코드에서는 메모리를 명시적으로 해제하지 않기때문에 가비지컬렉터가 더 이상 필요 없는 객체를 지우는 것이다.


가비지 컬렉터(Garbage Collector)는 두 가지 가설에 의해서 만들어졌다. 

이 가설을 "Weak generational hypothesis"라고 하는데

 * 대부분의 객체는 금방 접근 불가능한 상태가 된다. 

 * 오래된 객체에서 젊은 객체로의 참조는 아주 적게 존재한다.


이러한 가설의 장점을 최대한 살리기 위해서 Hospot VM에서는 크게 2개의 물리적 공간으로 나누었다. 


Young영역과 Old영역


Young영역은 무엇인가?

새롭게 생성한 객체의 대부분이 여기에 위치한다. 

대부분의 객체가 금방 접근 불가능한 상태가 되기 때문에 많은 객체가 Young영역에 생성되었다가 사라진다.

이 영역에서 객체가 사라질 때 minor GC라고 한다.


Old영역은 무엇인가?

접근 불가능한 상태로 되지 않아 Young영역에서 살아남은 객체들이 이 곳으로 복사된다. 

대부분 Young영역보다 크게 할당하며, 크게 할당된만큼 Young영역보다는 GC가 적게 일어난다.

이 영역에서 객체가 사라질 때 major GC(혹은 Full GC)가 발생한다고 한다.



 

Permanent Generation 영역은 무엇인가?

영원한 영역이라는 말은 아니다. 

객체나 억류된(intern)된 문자열 정보를 저장하는 곳이며, 여기서 GC가 일어나도 

major GC가 일어났다고 한다.





Old 영역에서 Young 영역으로 참조하고 있는경우에는 어떻게 처리하나?

=> 그래서 old영역에는 카드테이블(card table)이 존재한다. 

카드테이블은 Old영역에서 Young영역으로 참조하고 있는 정보를 담고 있으므로

모든 old영역의 참조를 뒤져본 후에 GC가 일어나는것이 아니라 카드테이블정보만 

보고 GC가 일어나게 되는 것이다. 



young 영역은 어떻게 구성되는가?

Eden영역과 survivor영역 2개로 구성된다. 총 3개의 영역으로 구성된다.


새로 생성된 객체는 Eden영역에 위치한다

Eden영역에서 GC가 한번 일어난 후에 살아남은 객체는 Survivor영역 중에 하나로 이동한다.

Eden영역에서 GC가 발생할 때마다 Survivor영역에는 살아남은 객체가 쌓이게 된다.

하나의 survivor영역이 가득차게 되면 모든 객체가 다른 survivor영역으로 이동하게 된다. 원래있던 survivor영역은 비어있는 상태가 된다.

- 이 과정을 반복하다가 계속해서 살아남아 있는 개체는 Old영역으로 이동하게 된다. 



이 메커니즘에 대해서 이해 하게 되면 

두 survivor영역에 모두 객체가 있거나, 두 영역 모두 사용량이 0이라면 시스템은 정상적이지 않다는 것을 판단 할 수 있게 된다. 


그렇다면 Old영역에서의 GC는 어떤 과정으로 처리되나?

기본적으로 Old영역이 가득차게 되면 GC가 일어난다. 

Old영역에서의 GC는 JDK 7 기준으로 5가지가 지원된다.

- serial GC

- parallel GC

- parallel Old GC

- Concurrent Mark & Sweep GC(이하 CMS)

- G1(Garbage First) GC


이 중에서 반드시 알아야 할 것은 운영서버에서는 serial GC를 절대 사용하면 안된다는 것이다. 


Serial GC는 어떤 방식으로 이루어지나?

Young영역에 대한 GC는 앞에 설명한 바와 같이 이루어진다. 

Old영역에서의 GC는 기본적으로 mark-sweep-compact라는 알고리즘을 사용한다. 


이 알고리즘의 첫 단계는 Old 영역에 살아 있는 객체를 식별(Mark)하는 것이다. 

그 다음에는 힙(heap)의 앞 부분부터 확인하여 살아 있는 것만 남긴다(Sweep)

마지막 단계에서는 각 객체들이 연속되게 쌓이도록 힙의 가장 앞 부분부터 채워서 객체가 존재하는 부분과 객체가 없는 부분으로 나눈다(Compaction).


Serial GC는 적은 메모리와 CPU 코어 개수가 적을 때 적합한 방식이다.


Parallel GC

Parallel GC는 Serial GC와 기본적인 알고리즘이 동일하다. 

그러나 Serial GC는 스레드가 한 개인것에 비해 Parallel GC에 쓰이는 스레드는 여러개다.

그래서 시리얼GC보다 더 빠르게 처리가 가능한 것이다. 


- parallel Old GC란?


- Concurrent Mark & Sweep GC 란?


- G1(Garbage first) GC 란?



****정리****

고급 개발자라는 것은 GC에 대한 명확한 이해와 함께 GC를 튜닝하는 관심과 능력을 가지고 있어야 된다고 한다. 

(네이버 개발자 센터에서 이 글의 원본을 쓰신 분이 한 말)

결국 대용량이나 거대한 프로젝트를 접해보신 분이 이러한 GC 튜닝을 해봐야겠다는 마음도 생겼기 때문이다. 

앞서 JDK에서 여러가지 GC를 제공하는 이유인 즉슨 가장 좋은 GC는 없다는 것이다. 그 서버의 상황과 하드웨어에 따라서

그에 맞는 GC를 제공해야 된다는 것이다. 

앞으로 고급 자바 개발자가 되야되겠다...

'JAVA' 카테고리의 다른 글

자바가 확장한 객체지향  (0) 2015.06.30
자바와 객체지향  (0) 2015.06.30
자바 스레드의 이해  (0) 2015.06.30
자바 메모리 구조 >>> 2  (0) 2015.06.30
자바 메모리 구조>>1  (0) 2015.06.30
Posted by slender ankles
,

Git에 대한 이해

Git 2015. 6. 18. 21:14

Git이 무엇인지는 알고 있었다. 

형상관리툴~?

그렇다면 Git과 SVN의 차이는 무엇일까?

Git은 Local Repository와 Remote Repository가 있다는  차이가 있단다. 

SVN은 원격지에 갱신만 한다는 의미인데.. 자세한 메커니즘과 구조에 대해서는 조금 더 알 필요가 있겠다.


Git에 대해서 간단히 정리해보겠다. 

참조 : http://www.slideshare.net/ibare/dvcs-git

버전관리를 들어본적 없는 사람들을 위한 DVCS - Git
git Learn DVCS For beginner Distributed Version Control System
www.slideshare.net

본문으로


텍스트 파일이 하나 있고 이 것을 그때그때 수정한 내용을 기록해두고 싶다. 

그렇다면 이 것을 수정할 때마다 새파일로 저장할 것인가? 

그렇다면 여러명이 참여하는 프로젝트에서 변동사항을 그때그때 저장할것인가?

=> 너무 파일들이 많아질 것이다. 나중에는 감당히 안 될 것이다. 


그래서 Git이 필요한 것이다. (물론 SVN, Bazaar, mercurial 등등의 많은 소프트웨어가 있다.)


Git의 


규칙 1

저장을 얼마에 한 번씩 해야 되는 것이냐?

SW개발자가 정해야 한다. 이 것이 Commit이다.

Commit => 이 파일의 의미있는 수준의 수정 작업이 끝났음


커밋 할때마다 커밋 메시지를 통해 기록해놓을 수 있다. 보통 어떤 부분이 수정되었는지를 기록할 것이다.


규칙 2

하나의 커밋(Commit)은 여러개의 파일이 포함 될 수 있다. 

커밋은 여러 파일에 동시에 영향을 가하는 것이다.

Commit1 => 월요일.txt, 화요일.txt [월요일 화요일 학습일정 추가]

Commit2 => 수요일.txt [수요일 학습일정추가]

Commit3 => 수요일.txt 목요일.txt, 금요일.txt [수요일 자율학습계획표, 목요일 금요일 학습일정 추가]


규칙3

파일을 수정하지 않고 새로운 실험을 해 볼 순 없을까?

월, 화, 수, 목, 금 시간표 파일이 있는데 이 파일들을 변경하지 않고 새로운 월, 화, 수, 목, 금 일정을 만들어보고 싶다. 가능할까?

상태를 저장하는 공간을 만들 수 있다. 

Branch

상태란 모든 것이다. 파일, 파일의 내용, 커밋 정보 등 git 이 관리하는 모든 것을 의미한다. 



Git의 시작

지정한 폴더의 변경 내용을 추적하기 위한 준비


init

선택된 폴더의 변경 내 용을 추적하기 위해 git저장소를 만든다. 저장소가 만들어지면 git은 지정한 폴더를 포함하여 하위 폴더의

모든 변경 내용을 커밋 단위로 추적한다. 

master

init명령으로 저장소가 만들어질 때 git은 master라는 이름의 브랜치를 기본으로 생성하고 이 후 커밋 내용을 브랜치 기준으로 저장한다.


완전히 독립된 브랜치 lab1

새로 만든 브랜치 lab1은 master와 완전히 동일한 상태를 가진 공간. lab1 브랜치에서 수정을 한 후 커밋하면 그 변경사항은 lab1에만 기록되며 master 브랜치에는 어떤 영향도 주지 않음


원하는 만큼 브랜치 생성 가능

git은 매우 빠르게 새로운 독립공간의 브랜치를 원하는 만큼 만들 수 있다. 브랜치 이름은 이름 정의 규칙내에서 사용자가 원하는 형태로 작명 할 수 있다.


실험 중 다른 브랜치로 돌아가야한다면?

checkout master

원한다면 언제든 다른 브랜치(작업공간)로 이동할 수 있다.

브랜치는 마지막 커밋 상태를 유지한다. 

작업 중인 위치를 가르키는 가상의 커서가 존재하는데 이를 git에서는 HEAD라 한다. 


브랜치를 이동하는 이유는 뭘까?

...시나리오...

새로운 실험을 하기 위해 lab1을 만들고 열심히 작업하고 있다. 그런데 master 브랜치에 내용을 변경할 일이 발생했다. 

어떻게 해야 할까?


정답 => master 브랜치로 이동하여 변경 작업을 처리한 후 커밋. 다시 lab1 브랜치로 돌아와 하던 실험을 계속한다.


실험종료.선택의 순간

실험 실패

lab1에서 진행했던 실험이 예상과 달리 필요없는 작업이 되었다. 어떻게 하면 될까?

정답

=> master로 이동 후 lab1 브랜치를 삭제한다. lab1의 모든 기록이 제거된다. 기록보관 차원에서 삭제하지 않아도 문제 없다.

실험 성공

lab1에서 진행했던 실험이 성공적으로 끝났다. 실험의 결과를 master브랜치에 옮기려한다. 어떻게 하면 될까?

=> lab1 브랜치의 내용을 마스터 브랜치와 병합(merge)한다.


브랜치와 브랜치의 병합(Merge)

merge lab1

병합결과

master브랜치에 lab1 브랜치를 병합하면 git은 lab1 브랜치의 내용과 master브랜치의 가장 최신 commit을 포함하여 두 브랜치를

병합한다.

변경 내용에 따라 파일 내용이 변경되고 때론 파일이 삭제될 수 있으며 추가될 수도 있다.


정리

commit => 수정 내역을 사용자 기준의 의미로 기록한다.

branch => 완전히 독립된 작업 공간을 만들 수 있다. 

checkout => 독립된 작업 공간인 브랜치를 자유롭게 이동할 수 있다. 

merge => 브랜치와 브랜치간 내용을 병합 할 수 있다. 


동료와 함께 작업하려면?

복사한다? usb에 받아서 복사한다. 

복사는 단방향이다. 한번 주고 동료가 작업한 경과를 돌려받기 위해선 너무나 많은 어려움이 예상된다.


git은 "리모트 저장소"를 지원한다.

리모트 저장소가 있다면?

리모트 저장소 또한 원본 git저장소와 동일한 저장소이다. 리모트 저장소를 경유하여 함께 작업할 동료도 완전히 동일한 저장소를 다운로드 받을 수 있으며, 동일한 방식으로 작업할 수 있다. 


리모트 저장소에서 저장소 다운로드

리모트 저장소에서 처음으로 git저장소를 다운로드 받는 것을 복사본을 만든다는 의미로 clone이라 한다.


clone remote.com/projectA


리모트 저장소의 변경 내용 업데이트

리모트 저장소의 변경된 내용을 로컬(내 컴퓨터) 저장소에 적용하는 작업을 Pull이라 한다. 이 때 브랜치 병합과 같은 병합이 발생한다.

pull origin


내 저장소(로컬저장소)의 변경 내용 리모트로 전송하기

로컬(내 컴퓨터) 저장소에서 작업한 내용을 리모트 저장소로 보내는 작업을 Push라 한다. 함께 작업하는 동료에서 변경상항을 전송하기 위해선 리모트 저장소를 경유해야 한다는 것을 알 수 있다. 

push origin

Posted by slender ankles
,