Branch 란 ?

Branch 란 우리말로 나뭇가지, 분기된 흐름 등의 뜻을 가진 단어이죠. 깃에서는 특정 커밋을 가리키는 '포인터'를 의미합니다. Branch는 최신 커밋을 가리키는 흐름이며, 하나의 프로젝트에서 특정 목적으로 서로 다른 개발 흐름을 병렬적으로 가져가기 위해 사용합니다. 이러한 브랜치를 통해 여러 개발자 혹은 여러 개발팀이 한 프로젝트의 세부 과제를 병렬적 진행하며, 각 목적에 맞는 개발 흐름을 관리할 수 있습니다.

위의 그림처럼, master branch(기본으로 셋팅되는 main branch) 에서 개발 분야를 feature-A 와 feature-B로 나눠 각각의 팀이 개발을 진행하기로 했을 때, branch 를 나누어 관리할 수 있는 것이죠. branch는 나누거나 합치기가 가능합니다.

 git log를 입력할 때, HEAD -> master 라는 문구를 보셨을겁니다. master 란, 앞서 말했듯이 Master branch 의 master 이고, 현재 3번째 커밋을 가리키고 있는 것을 알 수 있습니다. HEAD 는 branch를 통해 특정 커밋을 가리킵니다. 즉, 여기서 master branch를 통해 3번째 커밋을 가리키는 것 입니다. 

지금 깃 랩 서버에 연동시키지 않은 상태라 보이지는 않지만, 깃 랩 서버(이름 : origin)에 연동하게 되면 origin/master 라는 붉은 단어가 뜨는데요, 이것은 깃 랩 서버에 존재하는 master 브랜치를 의미합니다. 만약, HEAD -> master, origin/master 라고 되어있디면 지금 컴퓨터의 master branch 와 gitlab 서버의 master 브랜치가 모두 3번째 커밋을 가리키고 있다는 의미이죠.

Branch 만들어보기

1. 한 갈래로 나누기

git branch {branch_name} 입력

git branch develop 를 입력해 develop branch를 생성해주도록 하겠습니다.

기존에 있던 master branch 에 더해, develop branch 가 생겼네요. branch 를 생성할 때는 나누기를 원하는 기점(커밋)으로 이동해 HEAD를 옮겨주고 생성해주면 됩니다. 

보통 master branch 에는 배포할 정도로 완성된 커밋들만 넣고, develop branch 에는 개발하는 중에 사용할 커밋들만 넣습니다.

커밋 간 HEAD를 옮기는 법은 살펴봤는데, 브랜치 간 HEAD를 옮기려면 어떻게 해야 할까요?

git checkout {branch_name} 을 입력해주면 됩니다.

git checkout develop 를 입력해주면,

HEAD 가 develop branch 를 가리키는 상태로 바뀐 것을 확인할 수 있지요. 이 상태에서 commit 하면 이제 새 커밋들을 develop 브랜치가 가리키게 됩니다.

지금까지 순서를 정리해보면, 분기점이 될 커밋으로 이동해 Branch 생성(git branch), 해당 Branch로 HEAD 이동(git checkout), Branch 에서 commit(git add, git commit) 로 정리할 수 있겠습니다. 위의 코드를 보면 분기점이던 세번째 커밋을 포함한 이전은 master branch 에, 이후의 커밋은 develop branch 에 속해있는 것을 볼 수 있죠. 나무의 기둥에서 뻗어나온 나뭇가지 같습니다. 이렇게, 병렬적으로 나눠서 개발할 필요가 있을때 각 작업에 별도의 브랜치를 할당해줌으로써 수행이 가능해집니다.

지금까지는 master branch 에서 다른 한 갈래로 뻗어나가는 branch를 다뤄봤는데요, master branch 에서 두 갈래로 나뉘어 버전관리를 하는 것도 실습해볼까요?

2. 두 갈래로 나누기

우리가 지금까지 만든 코드에, attack method 와 defend method 를 추가 개발할 것이라 해봅시다. 그리고 각 method 는 다른 팀이 하나씩 맡아 개발하여 관리할 것입니다. 

그러면 분기점이 될 가장 최신 커밋으로 HEAD를 이동하고, feature-attack branch 와 feature-defend branch를 생성해주면 되겠지요. 그리고 attack method를 담당하는 팀은 HEAD를 feature-attack branch 에 이동시켜 attack method 소스코드를 커밋해 버전을 관리하고, defend method 를 담당하는 팀은 HEAD를 feature-defend branch 에 이동해서 defend method 소스코드를 커밋해 버전을 관리하면 될 것입니다. 

3. 모든 branch 확인하기

이 때, attack method를 맡아 작성하는 팀은 HEAD가 attack branch에 가있을때 defend branch 의 내용이 보이지 않습니다. defend method를 맡아 작성하는 팀도, HEAD가 defend branch에 가있을때 attack branch 의 내용이 보이질 않죠. (master branch의 내용을 보입니다.)

위의 코드를 보면, HEAD가 feature-defend 로 가있을때 master branch와 defend branch의 commit log는 보이지만, feature-attack branch가 보이지 않는 것을 확인할 수 있습니다. (현재 attack method 가 커밋된 상태입니다)

만약, 현재 내가 있는 branch 가 아닌 모든 branch를 보고싶다면 기존의 git log 에 다른 옵션을 추가해 명령해주어야 합니다.

git log --all --graph 입력

--all 은 HEAD 가 가리키는 branch 뿐 아니라 모든 branch를 보겠다는 명령어입니다.

--graph 은 브랜치와 커밋간의 관계를 그래프 형식으로 보여달라는 명령어 입니다.

해당 명령어를 입력해보니 왼편에 나무와 비슷하게 생긴 graph가 생긴 것을 볼 수 있습니다. develop branch 에서 두 갈래로 갈라져 있는 것을 확인할 수 있고, 모든 branch 가 보이지요.

개발 실무에서는 여러 작업을 분담해 처리하기 위해 보통 develop branch 에서 여러 개의 하부 branch 를 생성할때가 많습니다. 그리고 하나의 branch 위에서 팀이 버전을 관리하며 작업해가는 형식이지요.

4. branch 의 병합

이제 각 branch 의 개발이 끝나고, 각각의 feature 브랜치에서 했던 작업을 병합하고 싶습니다. (즉, develop branch에 작업의 결과를 모두 반영하고 싶다는 것입니다) 그러면 어떻게 병합해야 할까요?

먼저 develop branch(결과를 반영하고싶은 branch) 로 이동합니다.

git merge {합쳐주고싶은 branch이름} 입력

git merge feature-attack 을 입력합니다. 이 명렁어의 의미는, HEAD 가 가리키고 있는 브랜치(현재 develop)에 feature-attack 에서 했던 작업을 병합해달라는 것입니다. 보다 상세하게는, 1. 현재 HEAD 가 브랜치를 통해 가리키고 있는 커밋 과, 2. merge 뒤에 쓴 브랜치가 가리키고 있는 커밋을 합쳐달라는 것입니다.

HEAD 가 가리키던 develop branch 와 feature-attack bracnh 가 병합된 걸 알 수 있습니다. 특히 develop branch 의 위치가, six commit 에서 Add attach method 의 위치로 이동해온 것을 볼 수 있는데요, 이 경우를 Fast-Foward Merge 라고 합니다. 

Merge 로 branch 가 병합되는 경우에는, 두 가지의 경우가 있습니다. 

- 기존의 branch(develop)가 merge를 당하는 branch까지 쭉 당겨져 오는 경우

- 두 branch를 병합한 새로운 커밋이 생성되는 경우

이 중 전자의 경우를 Fast-Foward Merge 라고 하는 것이지요.

Comfilict 발생시 대처

feature-attack branch의 병합을 완료했으니, 이제 feature-defend branch 도 병합해줍니다.

그런데, 이런! 병합 중에, 오류가 발생했습니다.

Auto-merging myfile.txt CONFLICT (content): Merge conflict in myfile.txt Automatic merge failed; fix conflicts and then commit the result.

이러한 오류 문구가 발생한 이유는, merge 중 충돌이 발생했기 때문입니다.

그림을 보면, feature-attack branch 와 feature-defend branch 의 일부 소스코드(attack 와 defend) 가 같은 라인에 위치해있다는 것을 볼 수 있지요. 여기서 문제가 발생합니다. 파이썬이 같은 라인에 다른 코드를 병합하려다보니, 어떤 라인을 선택해야 할 지 모르겠다는 것입니다. 이게 conflict 오류 발생의 원인이 됩니다. 이 경우에 파이썬은 각 파일에 표시를 남겨줍니다. 

해결법은 간단한데요, 파일에 파이썬이 남겨준 오류 코드를 확인하고, 이 파일이 가졌으면 하는 최종 코드를 남겨두면 되는 것입니다. 예시의 경우처럼 둘 다 남기고 싶다면, 필요없는 부분을 지우고 원하는 코드의 모습으로 고쳐주면 됩니다. (괄호 수정)

코드의 수정이 완료되었다면, git add . 와 git commit 명령어를 사용해 커밋하면 되는 것이지요.

 이제 각 branch 들이 develop branch로 합쳐지면서 새로운 커밋이 만들어진 것을 볼 수 있습니다. merge를 할 때, 새로운 커밋이 만들어지느냐 Fast-Forward merge가 발생하느냐는 대개 "흐름의 분기"의 차이에서 발생합니다. 가령, 기존 branch 와 병합하고픈 최신 branch 의 로그가 직선 모양으로 앞뒤로 위치한다면 merge를 할 때 최신 커밋을 가리키는 쪽으로 이동합니다.(Fast-Forward) 그러나 흐름이 중간에 갈라진 branch 끼리를 merge하면 새로운 commit 이 하나 더 생기는 것입니다.

point

저번에 branch 관련 내용이라며 넘어간 코드를 한번 살펴보죠.

git push -u origin master

이 명령어를 기억 하시나요? gitlab 서버에 프로젝트를 올리라며 push 해주는 명렁어라고 했었지요.

사실 이 명령어를 더 자세히 설명하자면, master branch 를 origin 이 의미하는 gitlab 서버 프로젝트에 올리라는 뜻입니다. push 나 pull 은 "branch 단위"로 작업이 이루어집니다. 즉, push 나 pull 뒤에는 branch 의 이름이 적혀집니다.

가령 git push -u origin develop 하면 gitlab origin 서버에 develop 브랜치가 올라갑니다.

-u 는 "--set-upstream" 의 약자로, 내 컴퓨터의 master branch가 항상 gitlab서버의 master 브랜치를 바라보게 하라는 의미입니다. 그래서 처음에 저렇게 적어주면, 이후 push를 할 때 git push 라는 간단한 명령어만 사용하면 되는 것이죠.

오늘 살펴본 branch 는 깃 전체를 관통하는 내용입니다.

branch가 무엇일까? 왜 필요할까? 어떻게 병합할까? 어떻게 외부 저장소에 올릴까?  등을 잘 알고 있어야 합니다.

생각보다 글이 조금 길어져서 원래 쓰려고 한 다른 내용을 못 썼네요.. 글이 너무 길면 읽기 부담스러우니..^^;

다음 글에서는 프로젝트의 전반적인 과정에서 git과 gitlab 을 어떻게 쓰는지, Fork/Clone, MergeRequest하는 법 등 실전편을 가져오도록 하겠습니다.

저번 시간에 우리는 작업에 대한 이력을 내 컴퓨터에 남길 수 있는 commit 하기를 알아봤습니다.

우리가 commit 하는 이유는 뭘까요? 작업 이력을 남겨두고, 원하는 시점으로 자유롭게 돌아다니기 위해서라고 할 수 있죠.

이번에는 저장한 commit 간 이동하는 방법에 대해 알아보려 합니다.

그리고 외부 저장소에 push/pull 해보는 것까지 다뤄보도록 하죠!

Git history 관리 방법

저번에 git log 를 통해 본 커밋 이력에서, HEAD 란 문자를 본 적이 있으실 겁니다.

HEAD 는 현재 내가 위치해있는 커밋을 가리키는 식별자 입니다. 보통 가장 최신의 커밋을 가리키고 있죠.

커밋과 커밋을 이동할때는 git reset 을 사용해줍니다.

1. 커밋 간 이동하기 

git reset --{option} {commit_id} 입력

예시로, git reset --hard 8564 를 입력해주면, 워킹 디렉토리의 모습이 HEAD 가 가리키는 commit 의 모습으로 변하는 것을 확인할 수 있습니다.

git reset 명령어를 이용해, 우리는 언제든지 원하는 커밋으로 돌아갈 수 있는 것입니다.

명령어 중 --hard 의 부분은 옵션인데요, 옵션에 따라 working directory, Staging Area, Repository의 지정 커밋이 바뀝니다. 가령 위의 예시에서 워킹 디렉토리가 함께 바뀌는 이유는 hard 를 옵션으로 설정해주었기 때문입니다.

조금 헷갈리시나요? 옵션 별 차이를 간단하게 정리해보겠습니다.

2. 옵션 별 차이 

- 공통 : Repository 에서 Head 가 특정 commit을 가르킴.

- Hard : Staging Area 와 워킹 디렉토리가 특정 commit 으로 바뀜.

- Mixed : Staging Area 가 특정 commit 으로 바뀌나, 워킹 디렉토리는 바뀌지 않음 (가장 최근 커밋으로 유지)

- Soft : Staging Area와 워킹 디렉토리가 바뀌지 않음 (가장 최근 commit 으로 유지)

그렇다면 soft, mixed 옵션은 언제 사용하면 유용할까요?

예를 들어, 팀원A가 커밋1~6 을 만들었습니다. 그리고 지금은 워킹 디렉토리에서 커밋 6 에 대해 많은 작업을 했습니다.

작업을 하고나니 커밋 1~3은 괜찮지만, 4~6 은 너무 조금씩만 고쳐서 굳이 업로드 하지 않아도 될 것 같습니다.

이런 경우에, mixed/soft 옵션을 사용해서, 현재 작업한 워킹 디렉토리의 내용을 남기고 커밋3으로 이동합니다.

이 상태에서 커밋을 새로 하게 되면, HEAD 가 가리키는 커밋3 위에 새로운 커밋6이 쌓이기 때문에 불필요한 커밋을 없애고 필요한 커밋만을 보여주는 것이 가능합니다.

위의 그림을 보면, mixed/soft 옵션을 사용해 HEAD 만을 변경하고 커밋해 커밋7을 올리는 과정을 알 수 있지요.

git reset 의 옵션 중, hard 옵션을 사용할때는 특히 주의해야 합니다.

hard 옵션은 워킹 디렉토리를 다른 커밋의 버전으로 바꿔주기 때문에, 자칫하면 워킹 디렉토리에서 새롭게 작업하던 내용이 다 날라갈 수 있기 때문입니다.

3. 추가적인 명령어

- git status 

git status 는 파일 상태를 알아볼 수 있는 명령어 입니다. 아래의 코드를 볼까요?

캡쳐에 포함되지 않아서 보이지 않지만, 제 디렉토리의 커밋1(이름 : 8564) 에는 BasicCar1 파일이 있고, 커밋2(이름 : aa08) 에는 현재 BasicCar1 파일과 BasicCar2파일이 있습니다.

코드를 보면 가장 처음에 hard 옵션을 이용해 커밋2의 워킹 디렉토리와 스테이징 공간을 불러왔습니다. 그리고 mixed 옵션을 이용해 커밋2의 워킹 디렉토리를 그대로 둔 채 커밋1의 스테이징 공간만을 불러왔죠. 이 때, git status를 입력해 파일의 상태를 알아보면, 빨간색으로 BasicCar2.js 파일의 이름이 나타나며, 커밋되지는 않았지만 워킹디렉토리에 있다. 커밋할거면 get add 명령어로 커밋해라고 말해줍니다. 즉, 워킹디렉토리에는 이 파일이 있는데 스테이징 공간에 없다는 것입니다. 당연하겠죠? 왜냐면 커밋1의 스테이징 공간에는 BasicCar2.js 파일이 없으니까요! 

다음으로 다시 hard 옵션을 사용해 커밋2의 워킹 디렉토리와 스테이징 공간을 불러옵니다. 그 후 soft 옵션을 이용해 다른것을 그대로 둔 채 HEAD 가 커밋1을 가리키도록 하였죠. 이 때 git status 를 입력해 파일의 상태를 알아보면, 초록색으로 BasicCar2.js 파일의 이름이 나타납니다. 워킹 디렉토리에도 있고, 스테이징 아리아에도 있으니 이렇게 나타나는 거지요.

이제 각 옵션들의 차이, 그리고 git status 의 기능이 조금 이해가 되시나요?

- git reflog

일전에 알아본 git log 는 사실, HEAD 가 가리키는 커밋을 기준으로 그 이전에 커밋한 이력만을 보여줍니다.

그러면 문제가 있죠. 만약 내 디렉토리에 커밋1, 2, 3 이 있는데, git reset 명령어를 이용해 커밋1 로 갔습니다. 그리고 이제 커밋3으로 다시 돌아가고 싶어요. 그러면 커밋3의 이름을 어떻게 알죠? git log 명령어를 이용해도, 지금 나는 커밋1을 보고있기 때문에 커밋3의 이름을 확인할 수 없습니다.

이 때 사용할 수 있는게 바로 git reflog (reference log) 입니다. get reflog 는 이때까지 HEAD 가 가리켰던 commit 들을 순서대로 보여줍니다. HEAD@{n}  의 숫자가 작을수록 최근의 기록입니다. 각 커밋의 이름 대신에 head@{n} 을 사용해 지정할 수 있습니다.

지금까지는 Git 으로 버전 관리를 하며, 내 컴퓨터에만 저장을 했죠. 하지만 협업을 위해서, 그리고 프로젝트의 복구를 위해서 외부의 저장소에 우리의 파일을 업로드 할 필요가 있습니다.

외부 저장 서비스는 Github, GitLab, Bitbucket 등 다양하고, 서비스마다 각각의 특성과 장단점이 있지만 하나만 능숙히 사용할 수 있으면 다른 것들도 쉽게 사용이 가능합니다. 저희는 Gitlab 을 위주로 다뤄보겠습니다.

외부 저장소로 Push하기

1. 외부 저장소와 연결

git remote add origin {프로젝트의 gitlab url} 입력

git remote 명령어는 내 컴퓨터에서 내 컴퓨터에서 외부 저장소에 관한 작업을 할 때 사용하는 명령어입니다. 뒤에 다양한 종류의 명령어를 추가로 붙여서 다양한 명령을 수행 가능 합니다. 코드의 의미는 " url 이 가리키는 외부 서버의 프로젝트를 원격 저장소로 추가하는데, 이름을 origin 으로 하겠다."는 것입니다. (매번 긴 url을 쓸 수 없으니, origin 이라는 이름을 등록해주는 것.)

2. 디렉토리 내용 업로드

git push -u origin master 입력

git push 명령어는 "현재 내 프로젝트 디렉토리의 내용(.git 디렉토리 내부에서 관리되던 Repository 영역을 업데이트 한 것) 을 전부 origin 에 업로드 해라." 라는 것입니다. (-u , master 는 브런치 관련 내용으로, 추후 다뤄보겠습니다)

입력하면 아이디와 패스워드를 등록하라는게 나오는데, 프로젝트가 등록되어있는 자신의 gitlab 의 계정을 등록해주면 됩니다. url 만 입력해서 수정할 수 있었다면 url을 아는 팀원이 아닌 다른 사람이 함부로 수정할 수 있으니 꼭 필요한 부분이겠죠.

이렇게 외부 저장소와 연결하고, push 해준 후 gitlab 페이지에 가서 확인해보면, 지금까지 내가 한 commit 들이 시간순으로 다 보이는 것을 확인할 수 있습니다.

그리고, 처음에 이렇게 한번 push 를 해주면, 이후 명령시 디렉토리가 처음부터 origin 의 해당 프로젝트를 바라보고 있기 때문에 git push 만 입력해주면 됩니다.

.

외부 저장소에서 Pull 하기

그렇다면 반대로 Gitlab의 프로젝트에서 새로운 커밋이 Push 됐을 때 내 컴퓨터로 가져오려면 어떻게 해야할까요? 

혹은 새롭게 팀에 합류하게 되어 기존에 팀이 만들던 프로젝트를 가져오려면 어떻게 해야 할까요?

1. 처음 가져올 때

git clone {가져올 프로젝트의 url} 입력

이 명령어를 입력해주면, 페이지에 올라가 있던 커밋들을 하나의 디렉토리 형태로 그대로 복사해 가져옵니다.

주의할점은 우리가 clone 한 프로젝트 폴더는 지금 있는 폴더가 아니라 가져온 폴더이기 때문에,

리눅스 명령어 cd 를 이용해 clone 한 프로젝트 디렉토리로 이동한 뒤 git 명령어를 실행해야 한다는 점입니다. 

앞서 잠깐 언급한 적이 있었죠?

이후, #1 문서에서 다뤘던

git config user.name , git add , git commit -m "{commit설명} 을 써주고

git push 를 이용해 push 해주면 됩니다.^^ 

( 이때는 원격 저장소에 있던 프로젝트를 clone 한 것이기 때문에 별도로 git remote 를 쓰지 않아도 됩니다.)

2. 새로운 커밋을 가져올 때

 git pull 입력

이 간단한 명령어를 통해 현재 디렉토리가 바라보고 있는 gitlab 서버의 최신 커밋을 가져올 수 있습니다.

쉽게 버전을 관리하며 협업이 가능하겠죠?

포인트

1. 이름으로 origin 을 사용하자

git을 사용할 때, 관습적으로 외부 프로젝트 저장소의 이름을 origin 으로 합니다. 앞서 봤던 git remote add origin {url} 에서 봤듯이 말이에요. 그리고, 보통 여러 개발자가 함께 개발할때 새롭게 참여한 팀원은 다른 팀원에게 소스코드를 넘겨받는것이 아니라, git clone {url} 을 통해 가져옵니다. 내부 저장소에서 가져오는 것이 항상 가장 최신의 커밋을 가져온다는 보장을 하기 때문이죠. 이처럼 항상 기준이 되고, 근원이 되는 것은 gitlab에 있는 파일이기 때문에 origin 이라는 이름을 붙입니다.

2. Push 이전에 Pull 이 있다.

새로운 작업의 시작 전에는, 항상 내 컴퓨터에 있는 프로젝트가 gitlab 서버에 있는 최신 프로젝트를 포함하는지 확인하고 작업해야 합니다. 예를 들어 gitlab 의 최신 프로젝트에는 commit1, 2, 3, 4 가 있는데 내 컴퓨터에 commit 1, 2, 3 이 있어서, 이를 작업해 commit 1, 2, 3, 5 를 만들어 Push 하면 안되겠죠. 이렇게 되면 commit 끼리 충돌하며 Fail 할 수도 있습니다. 내 프로젝트로 gitlab 의 프로젝트를 덮어 씌우는 것은 보통 허용되지 않습니다. 포인트는 새 작업을 하기 전에는 무조건 git pull 로 최신 버전을 가져오자는 것입니다. Push 이전에는 Pull 이 있습니다.

오늘로 Git 과 Gitlab 에 대한 기본적인 내용이 마무리된 것 같습니다..

다음 글에서는 중요한 주제인 Git branch 만드는 법, Merge하는 법, Comflict해결 등을 알아보도록 하겠습니다. 

총총..

안녕하세요. 오늘은 소프트웨어에 관심있는 사람이라면 누구든 한번쯤 들어봤을 " Git " 에 대해 알아보는 시간을 갖도록하겠습니다 :> 

Git 을 처음 시작하는 분들을 위한 글로, 기초적인 부분만 다룬다고 생각하시면 되겠습니다^.^

#1 부터 #6 까지 업로드 될 예정이니 차근차근 같이 알아가보아요!

먼저 Git 이란 무엇일까요?

Git은 프로젝트의 개발단계에서, 팀원 모두와 함께 하나의 프로젝트에서 수월하게 코딩할 수 있도록 도와주는 도구입니다. 여러 사람이 하나의 프로젝트를 코딩한다면 여러 문제가 발생할 수 있는데, 그 문제를 쉽게 해결해줄 수 있는 마법같은 도구인것이죠. 오늘날 개발 실무에서는 Git과 GitHub/GitLab 등을 함께 사용함으로써 1. 프로젝트의 버전 관리와 2. 협업을 체계적으로 수행합니다.

하나씩 살펴볼까요?

1. 프로젝트의 버전관리

보통 여러분이 작업을 할 때, 한번에 완성되지는 않지요.

• 1차 작업물 -> 2차 작업물 -> 최종본 -> 최종최종본.... 

의 과정을 거쳐 한 프로젝트가 완성 될 것입니다.

하나의 파일에 계속 업데이트 하지 않고, 이렇게 따로 버전을 나눠 저장해두면 히스토리가 남아 언제든지 이전 버전을 활용할 수 있고, 프로젝트가 어떤 모습을 거쳐 현재의 모습이 되었는지 파악할 수 있다는 장점이 있지요. 이는 협업을 할 때도, 중간에 들어온 다른 개발자가 해당 프로젝트의 히스토리를 아는데 도움을 줄 것입니다.

이렇게 한 프로젝트를 여러 작업물로 나눠 관리하는 것을 버전 관리라고 합니다. 업데이트를 통해 기능을 추가한다던지, 버그를 수정한다던지 등 버전 관리는 소프트웨어 개발자에게 중요하며, 많은 개발자가 깃으로 협업 중입니다.

2. 원활한 협업

Git 은 원활한 협업을 지원합니다. 가령 팀원A가 프로젝트 버전1, 2, 3 을 만들고 외부 서버에 올리면, 다른 팀원B가 버전을 확인하고 버전 3를 다운받아 버전 4, 5 를 만들어 다시 서버에 올리는 것이 가능합니다. 추후 또 다른 팀원C가 버전 6, 7 을 만들겠지요. 이런식으로 깃은 다른 사람이 만든 코드를 받아, 업그레이드 하는 것이 수월합니다.

이 때, 프로젝트의 각 버전을 올릴 '서버'가 필요하겠죠? 이 Git 기반의 저장소 서비스가 바로 Github, GitLab 인 것입니다. Git 과 Github, Gitlab 은 다른 것이라 할 수 있죠.

Git 이용해보기

그렇다면 깃을 어떻게 이용할 수 있을까요? (윈도우)

먼저 아래의 링크에서 깃을 설치합니다.

https://git-scm.com/

설치를 하면 아래와 같이 Git bash 프로그램이 생긴것을 확인할 수 있습니다. 

Git-bash를 여니 터미널창이 보이네요

이렇게 Git을 다운받아주면, Git-bash 터미널창을 열지 않아도, VScode 등 프로그램의 내장 터미널에서 깃을 다룰 수 있게 됩니다.

파일 Commit 해보기

VScode를 실행하고, 깃에 올라갈 폴더와 파일을 만들어봅시다. 저는 예시로 BasicCar 파일과, README 파일을 만들었습니다.

파일을 커밋(commit) 한다는 것은 "특정 버전을 저장"하는 것을 말합니다.

커밋은 크게 3 가지영역을 바탕으로 작동합니다.

- Working Directory : 실제로 다루고 있는 프로젝트 디렉토리 폴더 자체 (우리의 경우 Racing Ground)

- Staging Area : 특정 버전으로 관리하고싶은 버전들을 모아둔 폴더

- Repository : 특정 시점의 Staging Area의 모습을 커밋으로 남기면, 커밋들이 저장되는 영역

우리는 Working Directory 에 파일을 생성하고, Staging Area에 업로드 하여, Commit 명령어를 통해 Repository 에 하나의 commit 으로 저장하여 버전 관리를 할 수 있습니다.

여기서 하나의 의문이 들 수 있는데요, Working Directory 에서 바로 Repository 로 올리면 되지, 왜 Staging Area를 거쳐 올리냐는 겁니다.

그 대답은 지금 당장 commit 하고싶지 않은 파일이 있을 수 있기 때문입니다. 즉, commit 하기 애매한 파일이 있으면, 제대로 수정한 파일만 Staging Area 에 업로드 하여 업로드된 파일에 대해서만 commit 을 하는 것입니다.

이제 파일을 직접 commit 해볼까요? 앞서 언급했듯이, 우리는 git 을 다운로드했기 때문에 VScode의 내장 터미널에서 commit 이 가능합니다. 

1. 준비

VScode 터미널에 git init 입력 (주의 : commit 하길 원하는 working Directory 폴더에서 해야합니다.)

2. commit 한 사람에 대한 정보 입력

git config user.name "{yourname}"

git config user.email "{youremail}" 

3. Staging Area 에 업로드

VScode 터미널에 git add {BasicCar.js} {README.md} 입력 (파일 이름)

파일 이름을 하나하나 넣기 번거롭다면, git add . 을 통해 모든 파일을 add 할 수 있습니다.

4. Repository 에 업로드

VScode 터미널에 git commit -m "{원하는 메모}" 입력

-m 은 메세지를 의미합니다. 메세지는 이전 파일과 비교해 어떤 내용이 변경되었는지, 어느 부분이 변경 되었는지 등 자세하고 친절하게 적습니다.

5. commit 이력 확인하기

VScode 터미널에 git log 입력

git log 를 입력하면, 지금까지 커밋한 이력을 확인할 수 있습니다. 이 이력은 커밋한 사람의 이름과 이메일 주소, 해당 커밋에 할당된 이름, 커밋한 시간 등의 내용을 포함합니다.

6. commit 파일 비교하기 

VScode 터미널에 git diff {커밋이름1} {커밋이름2} 입력

해당 코드를 입력함으로써 commit 한 파일간의 다른 점을 확인할 수 있습니다. 가령 어떤 파일이 추가되었고, 어떤 코드가 바뀌었는지를 친절하게 알려줍니다. 복잡하고 긴 커밋 이름을 모두 적을 필요는 없습니다. 파이썬이 알아볼 수 있도록 커밋 이름의 앞의 4 자리만 입력해도 알아서 찾아줍니다.

오늘의 Git알아보기는 여기서 마무리하도록 하겠습니다! 다음은 Commit 관리 및 Gitlab 에 대해서 간단히 다뤄보도록 하겠습니다.

리눅스.. 리눅스를 사용하며 한 학기를 보내보라는 조언을 처음 들었을때는 불안감이 앞섰습니다. 가상 머신이라는 것도 처음 들어봤고, 리눅스도 언뜻 들어본 것 같을 뿐이지 알 지 못하는 것이었기 때문입니다. 리눅스에 프로그램을 다운 받는 것이 윈도우에서의 다운 받는것과 다르다는 얘기를 들었을때는 상상이 안가기도 했습니다. 클릭하고, 다운받고.. 이게 어떻게 바뀔 수 있다는 것인지. 리눅스가 제 삶에 들어왔을 때 검색을 많이 해보았습니다. 대체 리눅스는 어떻게 프로그램을 다운로드 받는 것인가! 윈도우를 두고 리눅스를 쓰는 또 다른 이유는 무엇이 있을까.

다양한 이유들이 있었습니다. 말하자면 오픈 소스이기 때문에 완전한 무료이고, 이는 곧 개발 작업은 물론 홈 레코딩이나 그래픽 디자인 등에 최적화된 강력한 워크 스테이션 환경을 완전히 무료로 구축할 수 있다는 점, 리눅스를 돌리는 많은 서버는 리눅스 말고는 대안이 딱히 없다는 점, 등이 있겠지요. 개발에, 특히 서버에 리눅스가 좋다는 얘길 많이 들었습니다. 정보를 찾다보면 서버 개발자 분들이 리눅스를 매우 좋아하시더라구요. 저에게는 운영체제를 공부하고 명령어를 배울 수 있다는 큰 장점이 있었습니다. 과거 한번 라즈베리파이를 다뤄보며 운영체제를 조금 알게되어 터미널창에 작성해본 것이 처음이라 흥미로웠었는데, 이번에 리눅스를 하며 명령어들에 더 친숙해지고, 터미널 창과 더 대화를 나눠봐야지, 했었습니다.

그렇게 저는 총 10 가지의 프로그램을 다운받았습니다. 다운받은 프로그램의 기준은 이 프로그램을 리눅스에 다운 받음으로써, 리눅스가 나에게 더 매력적이게 되고, 늘 리눅스를 사용하지는 못하더라도 리눅스를 사용하는 것에 큰 불편함을 느끼지 않게끔 하는 것이었습니다. 먼저 개발 코드를 푸시, 풀 하기위한 깃과, 리눅스의 화면을 캡쳐하고 사진을 편집해줄 툴, 자바 개발환경을 위한 JDK와 이클립스, 간간히 즐길 미니게임 같은 SuperTuxKart, 보다 편리하게 웹 서핑을 할 수 있게 해줄 크롬, 우분투를 더 예쁘게 꾸며주고 편의성을 높여줄 Unity Teak Tool, 시스템 내의 프로그램과 환경을 관리해줄 Stacer, 노래를 들을 수 있는 Amaroc, 영상 편집이 필요하여 다운받은 shoutcut, 그리고 사람과 연결되는 공간인 Kakao talk 까지. 프로그램을 다운 받는데에 예기치못한 에러도 많이 뜨고, 가상머신 자체의 에러도 있어 한번은 다 지우고 다시 시작했지만, 이렇게 12주를 알차게 채우니 기분이 좋습니다.

아무래도 어릴 적부터 쓰던 운영 체제를 바꾸는 것이다 보니, 리눅스는 제게 어려웠습니다. 하나 하나 세부적인 모든 것들이 다 달라서 초반에 적응이 안되어 더 어렵게 느껴졌던 것 같습니다. 사실 어렵다기 보단 불편했다고 해야 할까요. 그러나 초기에 불편함을 느끼는 것은 당연한 과정이라는 생각이 듭니다. 리눅스에 프로그램을 다운 받으며, 쉬우면 알아가는 재미가 없다는생각으로 구글링하며 공부하였더니 이제는 리눅스에게 조금 거리낌이 없어진 것 같습니다. 간간히 리눅스를 다루다보니 운영체제를 다루는, 명령어를 입력하는 것에 친숙해졌고, 다른 운영체제에 대한 막연함이 사라졌습니다. 이제는 다른 운영체제에도 한번 (간단히) 써보겠다고 스스로 도전할 수 있을 것 같습니다.

---> 지금은 Lab에서 지원해주는 리눅스 기반 연구용 서버가 있어서, MovaXterm 이용해서 리눅스 잘 쓰고 있습니다.!! 

-      Kakao Talk 이란?

카카오톡은 주식회사 카카오가 2010년 서비스를 시작한 글로벌 모바일 인스턴스 메신저이다.

스마트폰 사용자들을 대상으로 프리웨어로 제공되며, 안드로이드, 애플, 블랙베리, 노키아, 오비스토어, 윈도우 폰 등의 다양한 운영체제에서 사용이 가능하다.

국내 대화 메신저 중에서는 단연 카카오톡이 가장 널리 쓰이고 유명하기에, 이번 리눅스에서도 카카오톡을 다운받아놓고, 필요시에 연락을 확인하기 위함으로 이번에 다운을 받아야 겠다고 생각을 하게 되었다.

다만… 리눅스에서 다른 프로그램에서처럼 카카오톡을 쉽게 받을 수 있는게 아니었다. 따라서 조금은 복잡한 과정을 거쳐 카카오톡을 다운 받게 되었다.

프로그램 설치(간략하게만 작성하였다.)

1.     Sudo dpkg –add-architecture i396

Sudo apt install wine playonlinux -y 를 입력하여 32 비트를 활성화하고 와인을 다운 받아준다. 카카오톡은 리눅스에서 안되기 때문에 와인을 통해 다운받아야 한다고 한다.

2.     playOnlinux 를 실행하여 Wine 버전 관리를 확인한다. 만약 최신 버전이 없다면 버전을 찾아 설치해준다..

wine mono 설치창이 나오면 설치한다.

윈도우 10을 선택하고, gdiplus, gecko, mono28을 선택한다.

3.     실행할 파일을 선택하라는 창이 나오면, 미리 다운로드 해둔 카카오 설치파일을 선택하여 카카오톡을 다운로드 한다. 마침을 누르고, 카카오톡의 바로가기를 만들어둔다.

-      후기

카카오톡을 어찌저찌 다운로드 받기는 했는데,… 로그인 시에 오류가 발생했다.  

구글링을 했더니 동일한 증상을 가졌던 사람이 해결한 문서가 있어, 터미널에 winetricks 의 설치와 관련된 코드와 ufw 에 관련된 코드를 입력해주었다. 그 이후 한 번 재부팅을 해줬다.

다행히 다른 것을 건들일 필요 없이  로그인에 성공했다..    (그래도 안된다는 사람도 있던데.. 다행이다) 바탕화면에 바로가기를 저장하는 방법은, PlayOnLinux 에서 Create a shortcut 바로가기를 만들면 된다고 한다.

이번주를 마지막으로, 약 12주에 걸친 리눅스 사용기가 끝이난다. 학기 초만해도 리눅스에 대해 아는 것이 없었는데…, 다양한 프로그램들을 다운 받으며 막연한 불안감만 가지고 있던 다른 운영체제와 많이 가까워진 기분이다.

마지막 12주차, 최종 후기 글에서는 리눅스를 데스크톱 OS로 사용했을때의 (내가 느낀) 장단점 등을 얘기해 볼 생각이다.

-      Shotcut 이란?

Shotcut은 오픈소스로 공개된 MLT framework 기반의 영상 평집 프로그램이다. 샷컷의 경우 템플릿 파일이 XML 기반으로 저장되어 편집이 간단하고, 멀티플랫폼에서 모두 실행되며, GUI, CLI 툴 또한 모두 지원되고 있다.

이번에 간단한 영상 편집을 할 일이 생겨서 영상편집 소프트웨어를 찾다 발견했다. 내가 원했던 사항인 다음의 1~ 4번을 모두 만족 시키는 소프트 웨어이다.

-1. 시간에 따른 멀티 편집 기능

2. 손쉬운 템플릿 조작 (편집 툴이 있어야 함)

3. 제작된 파일을 읽어들인 후, 경로 설정 값등을 프로그램 등으로 자유롭게 변경할 수 있어야 한다.

4. 윈도우와 리눅스 모두에서 실행이 가능해야 한다.

-      프로그램 설치

1.     Sudo apt-get update 와, Sudo ape-get install 을 해 공유 라이브러리를 설치한다.

2.     Sudo snap install shotcut –classic 을 입력하여 어플리케이션을 설치한다.

3.     잘 실행되는 것을 확인할 수 있다.

샷컷은 윈도우에서 종종 쓰던 곰믹스 영상 편집기와 기능이 비슷하여 조금은 프로그램이 익숙하다. 원하는 이미지나 text 를 원하는 값으로 설정하여 영상을 만들거나, 아이템들(스티커들)을 추가할 수도 있었다. 이렇게 하나하나 쌓아간 파일을   인코딩하여, 최종적인 동영상을 생성할 수 있었다.

-      후기

앞서 언급한 영상편집 해야할 일 중 하나는 남자친구와의 1주년을 맞아 축하하는 영상을 만드는 것이었다.

직접 노래를 녹음하여 음성 파일로 넣고, 텍스트 파일을 넣고, 가사에 맞는 그동안의 우리의 사진으로 구성된 영상을 만들었다.

샷컷을 조금 만져 보다 곰 믹스를 만져보다 샷컷을 조금 만져보다 하며 두 소프트웨어의 사용을 익혔다. 샷컷으로도 어느정도 만들었으나 역시 곰 믹스에 있는 폰트가 예뻐서 최종 완성본은 곰 믹스로 만들어두었다.

(오른편의 사진은 최종 영상 완성본의 5초 정도쯤이다.)

이번에 사용법을 꽤 익혔으니, 다음번엔 오로지 샷컷으로만 영상을 만들어볼 셈이다.

리눅스 명령어에 점점 익숙해지는 것 같은 요즘이다.

-      Amaroc 이란?

Amaroc 은 리눅스 우분투 사용자들이 애용하는 무료 음악 플레이어 중 하나이다. KDE 의 기본 플레이어이며, 재생 목록을 관리할 수 있고, 사용자가 듣는 앨범 커버를 보여주고, 노래 가사와 탭, 기타 연주법 등 다양한 서비스를 제공한다. Amaroc은 설치 또한 쉽다고 하여 리눅스를 사용하면서 노래를 듣기에 괜찮은 소프트웨어 인 것 같아 다운을 받기로 하였다.

-      프로그램 설치

Amaroc 은 우분투 터미널을 통해 쉽게 다운받을 수 있다.

Sudo apt-get install amaroc 을 입력해 설치를 진행한다.

잘 설치된 것을 확인할 수 있다.

 Amaroc 을 실행해 보았다. 설명대로 플레이 리스트 저장, 파일 열기, 인터넷 연결, 팟캐스트, 가사 보기 등의 기본적인 작동이 가능한 것을 볼 수 있다.

-      후기

가상머신을 처음 써보는 중인데, 가상 머신에서 처음으로 노래가 흘러나오는 것을 들었을 때 꽤 놀랐다. 노래가 흘러나오긴 할까..? 하는 반신반의한 마음을 갖고 있었기 때문이다.

정말 간단히 amaroc을 다운로드 받았지만, 더 최신 버전으로의 업데이트와 더 많은 기능을 위해선 mySQL을 설치하고 유니코드 환경으로 만들어주어야 한다고 한다.

Amaroc은 음악 정보를 저장하고 검색하는 데이터 베이스로서 SQLite, MySQl, 등을 사용하기 때문이다. 실제로 지금 내가 다운받은 기능만으로는 음악을 듣기에 충분하지 않을 것 같았다.

또, Amaroc은 실시간 가사를 이용할 수 있지만 우리나라 음악에 대해서는 이를 지원하지 않아,

한 개발자가 만든 실시간 가사 플러그인을 따로 다운로드 받아야 한다고 한다.

조만간 mySQL을 다운 받아,

최신 버전의 amaroc을 다운받아봐야 겠다.

오늘도 내 리눅스는 사용하고 싶어지는 중이다!

-      Stacer 이란?

Stacer 는 컴퓨터의 상태를 체크해주는 프로그램이다. CPU 와 HDD 의 상용량의 확인이 가능하며, 시작 프로그램 설정, 프로그램 삭제, 시스템 캐시 삭제, 시스템 진단 기능을 제공한다.

주로 쓰는 윈도우에서도 프로그램과 컴퓨터를 관리해주는 프로그램을 사용하며 종종 관리중인데, 리눅스도 관리 프로그램을 하나 다운받아 놓는게 좋을 것 같아 설치를 진행했다.

-      프로그램 설치

Stacer는 Ubuntu 저장소에서 사용할 수 없다고 한다. 따라서 sourceforge 에서 다운로드 하였다.

Sudo dpkg -i stacer_1.0.9_amd64.deb

를 입력해 설치하면, 정상적으로 다운로드 된 것을 확인할 수 있다.

현재 CPU 사용량이 15%, MEMORY가 556.9 mib, DISK 가 6.1 gib 가 사용중이다.

불필요한 파일들을 선택해서

Clean-up 할 수 있고, start-status, running-status 를 온 오프 할 수 있다. 그 외에도 시스템에 다운로드 되어져있는 패키지들을 확인한다거나,

CPU 의 현황, 과거 이력 등을 확인할 수 있다. Unity Settings, Appearance 등도 별도의 설정이 가능하다.

-      후기

점점 리눅스가 사용하기 용이해 지는 것 같다.

운영체제 꾸미기 툴, 사진 캡쳐 및  편집 툴, 시스템 내 프로그램 관리 툴, 개발 언어와 환경 다운로드, 짠 코드를 오픈소스에 푸시, 풀 할 수 있는  깃, 쉴 때 할만한 간단한 게임, 웹 개발에 도움이 되며 평소 서칭하기도 좋은 웹 브라우저 까지..

다음에는 내 리눅스에 또 어떤 프로그램을 다운 받을까. 사용하기 좋은 환경을 만들어서, 나 스스로가 리눅스에 거리낌 없이 자주 들락날락 거리게 되었으면 좋겠다.

-      Unity Tick Tool 이란?

유니티 트윅은 윈도우로 치자면 제어판과 유사한 역할을 하는 프로그램이다. 이 프로그램을 설치하면 리눅스 화면을 내 취향에 맞게 설정할 수 있다고 한다. 가령 테마나 폰트 변경, 아이콘 변경, 프로그램 메뉴의 크기 조정, 바로가기 및 런처 설정 등을 할 수 있다고 한다. 이왕 우분투 데스크탑을 설치한 김에 나도 테마 같은 걸 바꿔보고 싶어 설치하게 되었다.

-      프로그램 설치

sudo apt-get install gnome-tweak-tool 을 입력하여 설치를 진행한다.

정상적으로 다운로드 된 것을 확인할 수 있다. 이 프로그램과는 별개로 다른 테마들을 다운받아주면 더 확장적인 꾸미기가 가능하다. 

Gnome shell Extension 등의 테마를 설치에 전체적인 테마를 바꿔보았다.

마우스바와 상단바의 아이콘들도 보다 심플한 디자인으로 바꿨다.

디자인 외에도 불필요한 옵션은 끄고 날짜를 표시되도록 설정하고,

윈도우와 관련된 설정들도 기분적인 것들만 활성화해두었다.

APP 도 사용하지 않을 것 같아 일단 설정을 꺼두었다.

-      후기

리눅스에도 기본적인 제어판과 같은 프로그램이 있다고 한다. 그런데 이 프로그램을 다운받으면 확장판과 같은 기능을 한다고 한다. 윈도우에는 사용자 지정으로 할 수 있는 요소들이 다양한데 리눅스는 별도로 프로그램을 설치해야 다양한 꾸미기를 할 수 있다는 점이 아쉬웠다.

Unity Tweak tool 또한, 이것 하나만 다운로드 받는다고 다 되는 것이 아니라 링크에 접속해서 그놈 셀 확장 기능을 추가하고 유저 테마에 가서, 온으로 설정을 바꿔주고 패키지를 또 설치해서 아이콘 테마를 바꿔주고 Dafh to dock 을 또 설치하고 dock 테마를 바꿔줘야 하는 등..

꾸미는데 꽤 많은 노력이 필요하다는 생각이 들었다. 

-      Chrome 이란?

나는 PC로 인터넷 서핑을 가장 많이 하는 편이다. 나에게 사실 가장 필요한건 웹 브라우저인데, 우분투에도 기본적인 웹 브라우저가 있지만 쓰다보니 불편한 감이 있어, 사용이 더 용이한 크롬 브라우저를 설치하려 한다. 크롬 브라우저는 웹 개발자를 위한 최고의 브라우저 이기도 하다. 나 또한 크롤링을 연습할 때, 크롬 드라이버를 다운받아 용이하게 사용하고 있다.

-      프로그램 설치

1.   wget -q -O - https://dl-ssl.google.com/linux/linux_signing_key.pub | sudo apt-key add –를 입력하여 크롬 브라우저 설치용 인증키를 다운 받는다.

2.     Wget 을 사용하여 wget https://dl.google.com/linux/direct/google-chrome-stable_current_amd64.deb 을 입력해, 크롬 패키지를 다운로드 해주었다.

3.     sudo dpkg -i google-chrome-stable_current_amd64.deb를 입력해 다운로드한 크롬 패키지를 설치하였다.

크롬 설치과정에서 에러가 나, sudo apt-get install -f 를 입력해 에러를 수정했다.

4.     Google-chrome 을 입력해 크롬을 실행한다. 크롬이 실행된 것을 확인할 수 있다. 나는 기본 브라우저로 크롬을 지정해주었다.

-      후기

리눅스는 개발자들이 개발을 위해 쓰는 운영체제라는 느낌이 강했는데, 크롬을 설치하고 유투브를 보니 그런 느낌이 많이 사라졌다. 언젠가 리눅스가 윈도우까지 점령할거라더니 정말 그럴 수 있을 것 같다.

다만 역시 내 PC의 문제인지, 유투브 영상이 매끄럽지는 않았다. 소리는 끊기지 않아서 음악을 듣기에 유용할 것 같다.