반응형

1. 왜 GIT을 써야하는가

2. GIT의 구조 및 명령어

3. GIT 사용의 예시

4. GIT 실습

 

3. GIT 사용의 예시

GIT을 어떻게 쓸까?

우리는 형상관리를 위해 많은 개발자들이 하나의 저장소를 사용한다. 많은 개발자가 있으니 이를 효과적으로 사용하기 위한 방법에 대한 약속을 정한다. 약속은 대부분 브랜치를 사용하는(따는) 방법이며, 이를 GIT의 브랜치 전략이라고 한다.

 

우리는 브랜치를 어떻게 약속하여 사용하는지에 대해 배울것이고, GIT Flow와 GIT hub Flow 전략을 설명할 것이다.

 

GIT Flow 전략

Master : 라이브 서버에 제품으로 출시되는 브랜치로, 배포 가능한 상태의 버전만을 관리한다.

Develop : 다음 출시 버전을 대비하여 개발하기 위한 주요 브랜치다.

Feature : 기능을 완성 할 때까지 유지되는 브랜치로, 보통 개발자 저장소에만 있고 원격 저장소에는 push하지 않는다.

               Develop 브랜치에서 가져와서 Develop 브랜치로 merge한다.

Release : 다음 버전을 출시하기 위한 브랜치로 Develop브랜치에서 가져와서 Q/A, 테스트 진행 후 문제가 없으면 Master브랜치와 Develop브랜치로 merge한다.

Hotfix : Mater브랜치에서 오류가 발생하면 Mater브랜치에서 가져와서 급하게 수정하여 Master브랜치와 Develop브랜치로 merge 한다.

※ Mater브랜치와 Develop 브랜치는 항상 유지하는 기본으로 두고 나머지 브랜치를 보조브랜치로 사용한다. 

 

 

상황에 따른 브랜치 전략 예시

※ 신규 기능 개발 시 브랜치 전략(Feature 브랜치)

Develop 브랜치로부터 신규 개발할 기능을 위해 Feature 브랜치를 생성한다.

Featrue 브랜치에서 기능을 완성 하면 Develop 브랜치로 merge한다.

 

※ 라이브 서버로 배포하는 브랜치 전략(Release 브랜치)

 Feature 브랜치가 Develop 브랜치로 모두 merge 되었다면, QA와 테스트를 위해 Release 브랜치를 생성한다.

Release 브랜치를 통해 오류가 확인이 되면 Release 브랜치 내에서 수정을 한다.

QA와 테스트가 모두 통과 되면 배포를 위해 Master 브랜치로 merge 한다.

만일 Release 브랜치에서 오류 수정을 했을 경우 동기화를 위해 Develop 브랜치에도 merge 한다.

 

GIT hub Flow 전략 

※ 브랜치 생성 

- 기능 개발, 버그 수정 등 어떤 이유에서든 새로운 브랜치를 생성하되 브랜치 명으로 의도를 명확히 표현해야 한다.

- 새로운 브랜치는 항상 Master 브랜치에서 생성하고 Master 브랜치로 merge 한다.

- Master 브랜치는 항상 최신상태이다.

 

※ 개발 / 커밋 / 푸쉬

- 개발을 진행하며 최대한 상세히 커밋 메세지를 작성하고 수시로 push를 진행한다.

 

※ PR (Pull Request) 생성

- 피드백이나 도움이 필요할때나 merge 준비가 완료 되었을때 PR을 생성하여 pull해달라고 요청한다.

피드백이나 도움이 필요할때 : pull받아서 피드백 좀 해주세요

merge 준비가 완료되었을때 : 최종 merge 하게 pull 받아서 확인 후 push 해주세요.

 

 

반응형
반응형

1. 왜 GIT을 써야하는가

2. GIT의 구조 및 명령어

3. GIT 사용의 예시

4. GIT 실습

 

 

2. GIT의 구조 및 명령어

GIT은 앞서 말한것 처럼 여러 단계에 거쳐 다른 개발자들과 공유한다고 했다.

각 단계별 영역과 상태 등의 구조를 익혀두고 실습을 해보고 다시 이 구조를 본다면 훨씬 이해하기 쉬울것이다.

 

GIT 구조

위의 구조는 영역과 상태, 명령어로 되어있는 모식도이다. 하나하나 설명해보겠다.

 

 

영역
ⓐ Local : 개발자 PC의 영역이다. Local안에서도 여러 가지 영역들이 존재한다. 
ⓑ Working Directory : 실제 개발 하는 파일들이 있는 영역이다.  (Working Tree, Working Copy라고도 부름) 
ⓒ Staging Area : 버전을 만들 파일들을 모아두는 영역이다. working directory에서 여러 파일을 수정했지만, 특정 파일을 현재 버전에 포함하지 않아도 되면 그 파일을 Staging Area에 올리지 않고(제외하고) 버전을 만들수 있다. 즉, 버전을 만들 파일을 선별적으로 묶어 두기 위한 영역이다.(Index, Cache라고도 부름)
ⓓ .git Directory : 버전이 만들어져 관리되는 영역이다. Staging Area에서 묶어둔 파일을 실제로 버저닝이 되어 관리되는 영역이다. (Repository, History, Tree라고도 부름)
ⓔ Remote : 개발자들이 함께 공유하는 서버 영역이며, 원격저장소라 불리운다
ⓕ .git Directory : Remote 서버에서 버전을 관리하는 영역이다.

 

상태

① Untracked : git에서 추적하고 있지 않은 새로운 파일이 생성된 상태이다.

② Tracked : git에서 추적하고 있는 기존에 파일의 상태이며 하위로 2가지 상태를 가진다.

③ Unmodified : git에서 추적하고 있는 기존에 파일을 수정하지 않은 상태이다.

④ Modified : git에서 추적하고 있는 기존에 파일을 수정한 상태이다.

⑤ Staged : 버전을 만들 Stage Area에 파일이 있는 상태이다.

⑥ Version : 버전을 만든 후 .git Directory에 파일이 있는 상태이나, 버전이 만들어진 후 파일은 Tracked > Unmodified 상태로 바뀐다.

 

명령어

git add : 신규 생성된 파일이나, 기존에 git에서 관리하던 파일 중 수정한 파일을 Stage Area에 올릴 경우 사용하는 명령어이다. (Untracked 상태 → Staged 상태 , Modified 상태 → Staged 상태로 바꿈)

git commit : 버전을 관리할 Stage Area에 모인 파일들을 버저닝하는 명령어 이다. (Staged 상태 → Unmodified 상태로 바꿈)

git push : 버저닝한 파일들을 원격 저장소에 업로드하는 명령어이다.

git pull : 버저닝한 파일들을 원격저장소에서 다운로드 하는 명령어이다. 이렇게 다운로드 된 파일은 Tracked > Unmodified 상태로 다운로드 된다.

 

 

 

반응형
반응형

1. 왜 GIT을 써야하는가

2. GIT의 구조 및 명령어

3. GIT 사용의 예시

4. GIT 실습

 

1. 왜 GIT을 써야하는가

세상에 거의 모든 현업 개발자들은 혼자 개발하지 않으며, 소스들은 개발자들의 손을 통해 지속적으로 바뀐다.

이러한 특성으로 인해 소스코드들을 체계적으로 관리해주는 것 필요했고 이러한 일을 형상관리라고 한다.

우리도 일상적으로 형상관리를 해본일이 있다.

 

발표자료를 팀원들에게 공유 하는 상황을 그려본다.

 

최종.pptx

진짜 최종.pptx (아이콘 수정)

진짜 진짜 최종.pptx (진짜 최종.pptx + 피드백 자료 합치기)

진짜 이게 찐 최종.pptx (오타 발견)

 

이런 파일 공유 많이 해봤을 거라 생각한다. 상황은 다음과 같다.

최종.pptx를 받은 팀원이 최종_피드백.pptx로 피드백을 했다.

아이콘 이미지를 바꾸기 위해 난 이미 진짜 최종.pptx를 저장해서 공유하려고 했다.

피드백을 받았으니 둘을 합쳐 진짜 이게 최종.pptx가 만들어진다.

근데 또 오타를 찾았다......

진짜 이게 찐 최종.pptx가 만들어진다.

 

위와 같은 상황을 잘 관리할 수 있게 도와주는 툴(프로그램)을 우린 형상관리 툴(프로그램)이라고 한다.

 

형상관리 툴은 다른 개발자와 같은 파일을 수정하거나 개발했던 것을 원복해야할 때 등 좋지 못한 상황이 발생했을 때도 큰 힘을 발휘한다.

 

이 형상관리 툴은 SVN과 GIT이 대표적이다. 다만, GIT은 혁신이라고 불리우는 대신 지옥에서 왔다는 별명을 가지고 있다.

 

둘의 특징은 다음과 같다.

SVN은 직관적이기 때문에 사용하기가 편하다.

SVN서버에 저장소를 만들고 거기에 모든 개발자들이 연결하여

중앙 집권식으로 소스를 업로드(commit), 다운로드(update)하게 된다.

이 말은 SVN서버와의 연결이 끊어지면, 업로드 다운로드가 안 될뿐아니라

소스를 수정했던 이력들을 볼수 없고, 서버가 수명을 다 한다면 수정 이력들을 날려버리게 된다.

내 로컬 PC에 소스는 남아있으니 SVN서버를 다시 파서 개발자들에게 이쪽으로 붙으라고 하면 되지만,

여기서 GIT이 좋은 이유를 찾을 수 있다.

 

GIT은 여러 단계를 거쳐 다른 개발자들과 소스를 공유하게 되는데,

단계가 많다보니 단계별로 발생 할 수 있는 경우의 수가 많다.

그럼에도 불구하고 GIT이 가진 장점으로 위와 같은 상황에서 힘을 발휘한다. 

 

GIT은 개발자들마다 독립적으로 저장소를 가지고 있고 관리가 가능하기 때문에

GIT 서버가 어떻게 되든 히스토리를 똑같이 복구 할수 있다.

심지어 GIT의 서버는 github.com 사이트에서 서버로 활용할 수 있어, 서버 구매 비용도 없고 서버가 잘못될 가능성도 현저히 적다.

 

히스토리가 왜 중요할까?

더보기

소스를 복원해야하는 경우가 생길 수 있다.

결정권자의 횡포로 아 이거 전에거가 더 나은대? 원래대로 돌리자 라거나,

심각하고 치명적인 오류를 뒤늦게 발견했지만, 고치려면 시간이 오래 걸린다면 이전 상태로 돌려야한다.

 

말그대로 소스의 역사를 통한 정보 습득이다.

누가 언제 어디서 무엇을 어떻게 소스를 작성했는지 알고 여러가지 일을 할 수 있게 된다.


 

다음으로 GIT은 개발자 자신만의 버전관리를 할 수 있다.

버전 관리라고 함은 어떠한 기능을 만들때 썼던 여러가지 소스들을 유의미한 단위로

묶어서 관리한다는 이야기이다.

만약, 로그인 기능을 만든다고 하면 로그인 기능을 업데이트한 버전을 묶어서 저장소에 저장을 한다.

이렇게 관리된 버전들은 명령어 하나로 아주 쉽게 이전 상태의 버전들로 돌아갈 수 있다.

 

세번째 GIT은 Branch와 merge 기능을 사용하기에 좋다.

갑자기 처음 보는 용어가 나와서 당황 했을 것이다. 한국말로 브랜치와 머지라고 하는데

위의 최종.pptx사태로 돌아가 보자. 

(개념적으로만 이해하고 넘어가자. 실습으로 이해하는게 더 빠르다.)

 

상황

최종.pptx를 팀원에게 공유하고 혹시 피드백이 올지 몰라

최종.pptx를 기반으로 따로 진짜 최종.pptx 파일로 작업한다.

아니나 다를까 최종_피드백.pptx가 피드백이 왔고

진짜 최종.pptx최종_피드백.pptx를 합쳐 진짜 진짜 최종.pptx를 만들었다.

 

해석

2번째 줄인 최종.pptx를 기반으로 따로 진짜 최종.pptx 파일로 작업한다.

는 말을 최종.pptx에 브랜치따서 작업 한다고 얘기한다.

 

4번째 줄에 최종_피드백.pptx진짜 최종.pptx를  합쳐 진짜 진짜 최종.pptx를 만들었다.는 얘기는

브랜치로 딴 진짜 최종.pptx와 원본 파일의 수정본인 최종_피드백.pptx를 머지 한다고 한다.

 

 

최종 정리

SVN

- 직관적이고 사용하기 편하다.

- 중앙 집권식으로 소스들을 다운로드 업로드 한다.

- 서버가 죽으면 히스토리를 살릴 수 없다.

 

 

GIT

- 독립적인 저장소를 관리한다.

- 버전 관리를 개발자가 직접 할 수 있으며, 버전별 소스 상태 변경이 용이하다 

- branch와 merge 기능을 사용하기 좋다.

반응형
반응형
이 글은 문과생에서 공학도로, 비전공자에서 개발자로서 8년만에 처음 작성하는 회고이다.
반면교사 삼아 나와 같은 상황을 겪지 않았으면 하는 바람으로 작성해본다.

 

고등학교 시절 수학이 싫어 문과를 선택했고,

문과생에서 좋아하는 과목을 따라 공학도의 길을 선택했다.

 

졸업 후 취업을 알아보던 중 우연한 계기로 웹 개발자 양성 학원을 다니게 되었고,

이 후 개발자의 삶이 시작 되었다.

 

그 당시 치열하게 고민했겠지만, 이 선택들이 가지는 무게감은 상당했었다.

문과생이 공학도의 길을 선택 했을 땐 공학계열 과목은 출석으로 C 학점을 채우기 급급했고,

졸업 후 개발자 양성학원에서는 타자 따라치기 급급했었다.

 

꾸준함과 노력이 무기라고 생각하여 이해가 안가고 무슨 말인지도 몰랐지만 무작정 앉아있었다.

다행히 졸업학점은 3점대를 넘겼고, 3개월 학원 수료 후 1개월 만에 첫 직장에 입사하였다

 

 

SI 2년

첫 직장은 전공과 관련된 공공기관 SI 웹 개발을 하는 회사였다.

학원에서 타자만 치기 바빴던 나는 Java도, 쿼리도 모르는 갓태어난 송아지였다.

제안서를 쓰고 문서작성하는게 오히려 회사에 쓸모있는 사람이라는 생각이 들었다.

 

하지만 어김없이 개발일은 들어왔고,

선임 개발자가 짰으면 더 빨랐을 일을 선임 개발자의 도움을 받으며

소스를 어디에 붙여넣어야 오류가 안날지 고민하는 개발을 했다.

 

처음 javascript로 별거 아닌 함수를 만들고 호출하며 세상 뿌듯해했던 기억이 있다.

정말 단순한 함수였는데 혼자 뭔가 만들었다는 사실이 좋았던것같다.

 

이렇게 제안서 2개와 프로젝트를 2개를 하면서 CRUD 경험을 하게 되었다.

이때 역시 나의 개발 실력은 코드를 어디에 붙여넣어야 오류가 안나는지 아는 정도.....

 

부족함은 알고있지만

어떤 공부를 해야할지, 어떻게 공부해야할지, 뭐가 얼마나 부족한지 전혀 몰랐다...

아니, 공부의 절실함도 사실 잘 몰랐던것 같다.

 

 

SM 6년

개발도 못하면서 월급은 더 받고 싶어 취업 제안을 뿌리치지 못해 SM으로 입사를 했다.

이때 연봉이 1.5배 이상 뛰었고,

소스 붙여넣기만 했던 3년차 개발자도 이런 대우를 받을 수 있구나

라는 오만함이 들었던것같다.

 

입사를 해보니 기획자 1명, 개발자는 3명, 퍼블리셔 1명이 있었다.

SM이지만 전문 IT 회사가 아니였고, 개발에 대해 아는 사람은 개발자 3명이 전부였다.

 

처음 1~2년은 정말 배울것이 많았다.

제로 베이스였으니 소스를 더 잘 붙여넣을 수 있게 되었으며,

게시판을 혼자 만들수 있게 되었고,  쿼리를 짤 수 있게 되었으며,

오류가 발생하면 뭐부터 해야하는지 알게 되었다.

 

하지만, 같은 일 반복이 되어 익숙해졌고, 야근은 없었으며, 월급은 하는일에 비해 많았다.

심각한 메너리즘에 빠져있다는 것, 발전을 하고 있지 않다는 것이 느껴져

입사 3년 후 블록체인 관련 개발 학원을 결석 한번 없이 수료하였다.

수료 후 입사를 제안한 곳도 있었지만, 자신도 없었고 이곳을 포기할 순 없었다...

 

학원 수료 이후에도 사이드로 프리 일을 하기도 하고, 개인 프로젝트를 하면서

나름 열심히 하고있다는 스스로 위로를 했다.

아니, 사실 좀 자신감도 생겼었다.

예전에는 꿈꾸지도 못했던 일을 해냈다.

혼자 개발하고 인터넷 검색해가며 서버도 띄우고 배포도 했다.

난 풀스텍 개발자라 생각했던 것이다...

 

이렇게 SM에서 6년이란 시간이 지났다.

회사 사정으로 이 사업이 철수가 된다.

 

현재 취업 시장에서 나는 9년차 개발자로서 경험이 부족한 물경력 시니어였다.

전 회사의 괴물 선임은 그 동안 뭐했냐며 진심으로 안타까워 했고,

면접에서는 3~4년차 주니어 정도 된다는 쓴소리도 들었다.

 

한 동안은 이런 생각을 했다.

내가 이 길을 계속 가는게 맞는건가.

안가면 내가 할 수있는게 무엇인가.

BackEnd로 갈것인가 FrontEnd로 갈것인가.

 

하지만 결론은 가야한다.

다른길이 없다.

현재 난 많이 부족하고, 공부 말곤 극복 할 수 있는 방법이 없다.

이런 자극, 절실함을 느낀지 1개월 정도 되었고 곧 실업자가 된다.

 

 

같은 실수는 반복하지 않는다.

이런 글을 작성한다는 것이 얼마나 창피한 일인지 모른다.

익명이라는 가면을 쓰고있긴 하지만 나의 치부를 이렇게 드러내본적이 없다.

그럼에도 이 글을 쓰는 이유는 더 발전하기 위해서이다.

서두에 반면교사 삼아 같은일을 겪지 않았으면 한다고 포장했지만,

더 큰 이유는 과거를 돌아보고 발전하기 위해서가 더 크다.

 

현재 난 절실함을 느끼면서 이렇게 하고있고 하려고 하고있다.

1. 면접용 질문 정리

면접용 공부는 따로 있다. 면접용 공부라고 하긴 하지만 면접에서만 쓰는건 아니라는 생각이 든다.

알고 있던 것을 정리하는게 아니라 정리하면서 알게 되니 더 그렇게 느끼는것 같다.

웹에서 긁어다가 내 블로그에 정리하는 것 말고, 수기로 쓰면서 공부하고 있다.

Java, Spring, web/network, 기타 섹터로 나눠서 연습장에 한번 정리 노트에 한번 쓰면서 공부하고있다.

 

 

2. 개발 관련 짤막한 유튜브 시청

여지껏 유튜브는 놀이의 수단이였다. 이제 유튜브의 히스토리는 개발 관련된 것으로만 채워지고있다.

생활코딩, 얄팍한코딩사전, 널널한개발자, 우아한테크, 박재성, 코딩애플을 구독하고 관심있는것 위주로 시청하고있다.

이 구독 목록은 다른 분들에 비해 쉽게 설명해주는 장점이 있어 개인적으로 개념 공부하기 너무좋다

더 딥하게 공부하려면 이것으로 부족하긴 하겠지만, 현재는 이게 최선이다.

 

 

3. 토이프로젝트

경험이 부족하니 채우는 수 밖에 없다. 현재 BackEnd 시장에서 가장 많이 쓰고 있는 기술인

spring boot, jpa, git을 경험해보지 못했다. 멤버를 찾지 못해 계속 서칭중이긴 하지만 혹시 못찾는다면,

혼자서라도 해볼 생각이다.

 

 

4. 기초 공부

개발 기본 : 운영체제, 컴퓨터 구조, 네트워크

BackEnd 기본 : Java, Spring, GIT, 디자인 패턴

9년차라면 : 도커, 쿠버네티스, cloud 서비스, 젠킨스 설정, 리눅스, 웹크롤링 등

 

부족한게 너무 많지만 BackEnd 기본 부터 공부 하려고 한다.

Spring은 김영한선생님의 인프런강의, GIT은 생활코딩, 자바는 남궁성님 유튜브강의, 디자인패턴은 헤드퍼스트를

참고할 예정이다.

 

 

5. 커뮤니티 활동

나의 현재 실수의 가장 큰 원인은 오만함과 메너리즘이였다.

이런 것을 주변사람들과 이야기를 나눴다면, 절대 있을 수 없는 일이라 생각이든다.

내가 사는곳은 경기도라 커뮤니티가 많이 없지만, 멀어도 최대한 참여해보려고 한다.

 

 

6. 개발 관련된 독서

개발 필독서가 있다고 한다. Java도 잘 모르는 내가 오브잭트라던가 클린코드라던가 리팩토링같은

공부를 할 엄두가 안난다. 그래서 자꾸 기초에 목매달고있는것 같지만 언젠간 깨부숴야할 것들이라

생각이 들어 하나한 공부할 예정이다.

현재 맨탈이 많이 깨져있는 상태라 프로그래머의 길 멘토에게 묻다라는 책을 구매했다.

 

 

내가 하고 있는 일이 사회적으로 얼마나 가치있는지를 판단해야한다.

사회적 공헌의 얘기가 아니라 얼마의 돈이 오가는지에 대한 얘기이다.

나에게 이런 돈을 쥐어 줄만한 일을 하고 있는지 끊임 없이 의심해야한다고 생각한다.

 

누군가 얘기했던것같다.

"언젠간 짤리고 회사는 망한다."

회사가 망하면 다른 곳에서 일 할 수있는 역량을 키우기 쉬운 직종이 개발자라 생각한다.

이 길을 선택했으니 이 길의 단점보단 장점을 보고 달려나갈 생각이다.

 

끊임없이 공부해야하는 직업.....

이제서야 몸소 깨닫는 중이다.

 

좋은 개발 문화를 가진 좋은 회사에 입사 후 좋은 내용으로

회고를 쓸날을 기약하며

긴글을 마친다.

 

 

- 맨탈적으로 힘들어하고 있을 모든 비전공 개발자들을 위해...

반응형
반응형

니가 대수롭지 않게 받아들이면

남들도 대수롭지 않게 생각해

 

니가 심각하게 받아들이면

남들도 심각하게 생각하고

 

니가 아무것도 아니라고 생각하면

아무일도 아니야

 

- 나의 아저씨

반응형
반응형

구두 끈이 풀린지도 모른채

앞만 보고 뛴다면 절대 1등 할 수 없다.

가끔은 아래를 보며

풀린 끈을 꽉 조여라


- 하워드 슐츠 - 

반응형
반응형

급하면 매력없


feat, 조급하면 저급하다.

반응형
반응형

오늘이 모여서 

내일을 빛나게 할거야!




반응형
반응형



행복의 비밀은 

자신이 좋아하는 일을 하는 것이 아니라,

자신이 하고 있는 일을 좋아하는 것이다.




반응형
반응형



행복한 사람은 가진 것을 사랑하고,

불행한 사람은 가지지 못한 것을 사랑한다.



반응형

+ Recent posts