[Git 사용하기] 기본적인 git 명령어와 작동원리

 

팀프로젝트 하면서 git을 어떻게 사용했고, 또 나아가 더 효율적으로 관리할 수 있는지 정리해보려고 한다.

---

git [명령어] [옵션]

 

git 은 명령어 단위로 이루어진 간단한 프로그램이다.

사용방법은 git 으로 시작하고 띄어쓰기로 구분되는 각각의 명령어와 옵션을 작성한다.

 

다양한 명령어들이 있고, 이는 공식 홈페이지의 Documentation의 Reference를 통해 확인할 수 있다.

혹은 git 실행환경(git 설치된 후)에서

git [명령어] --h 로 다양한 속성값을 살필 수 있다.(help)

 

기본적으로 git 을 설치해야하고, 설치한 후에는 초기화를 통해 사용할 수 있는 환경을 만들어준다

git 공식 홈페이지를 이용하여 자신의 운영체제에 맞게 다운로드를 하고나서

git init 을 통해 초기화 한다.

 

git을 삭제하고 싶다면

rm -rf .git

 

터미널에서 내 git 환경설정 확인하기

git config --list

 

터미널에서 사용자 정보 수정하기(edit)

git config --global -e

 

터미널에서 바로 수정하기보다 조금 익숙한 툴로 조작하고 싶다면?

vs코드가 편하니까 "code"로

git config --global core.editor "code"

 

"code --wait" 라는 명령어를 사용하면, 수정하는 동안 터미널이 말그대로 wait, 기다려준다.

저장하고 vs code를 종료해야 터미널도 다시 동작한다.

git config --global core.editor "code --wait"

 

나만의 alias(별칭) 설정

git config --global alias.st status

git st -> git status 와 같음

 

응용해서

git config --global alias.cm commit

git cm -> git commit 과 같음

---

Git workflow

 

git workflow에 대해서 간략하게 그려보았다.

 

내컴퓨터, vs코드, 이클립스, 인텔리제이든지 다양한 실행환경에서 내가 현재 작업하고 있는 곳을 working directory

git directory 혹은 repository에 저장하기 전 git add 명령어를 통해 옮겨놓는 staging area

작업물의 version history를 가지고 있는 .git directory(repository)

 

staging area가 중간 저장소로서 의미가 있을까 싶을 수 있지만,

commit을 통해 repository에 올라가면 history관리하기가 쉽지 않다.

물론 commit을 하고 push를 하지 않았다면 되돌릴 수 있지만, 이를 간편히(?) 가능하게 하는 것이 staging area다.

또, add 명령어를 이용하여 일부분만 commit하여 관리하고 싶을 때라던지 

전혀 불필요한 공간이 아니기 때문에 소홀히 해서는 안된다.

관련하여 잘 정리된 글이 있어서.. 

 

git rm --cached <file>

staging area에서 파일들을 untracked 상태로 만들 수 있다

 

gitignore를 직접 만들어보기

echo *.log > .gitignore

 

vs코드로 작업할 때 한 눈에 볼 수 있었던 open changing 

git diff

git diff --staging

 

---

commit 은 어떤 단위로 하면 좋을까?

 

commit 메시지에 강제적인 규칙이 있는 것은 아니지만,

많은 개발자들 사이에서 현재형 동사로 하는 것을 덕목(?)이라 여긴다고 한다. 

 

나 혼자 보고, 관리하는 repository라면 commit 메세지 스타일이 무슨 의미가 있겠냐 생각할 수 있겠지만

훗날 다시 repository를 살펴볼때라던지, 여럿이서 함께하는 프로젝트를 관리할 때는

commit 메세지가 단순히 commit 을 위한 수단이라기보다

서로의 소통을 위한, 진정한 history 관리를 위한 '메세지'로서 기능을 해야한다.

 

실제로 이번 팀프로젝트를 하기 전에도 머리를 맞대고 commit 메세지 규칙을 정했다.

 

그렇다면 commit 은 언제 어떤 작업단위로 하면 좋을까?

나 역시도 이 부분에 가장 반성을 많이.. 한다..

 

유뷰브 드림코딩 엘리 깃, 깃허브 제대로 배우기 중 

commit을 한다는 것은 즉 내가 어떤 의미있는 작업을 했는지에 대한 분할로 바라볼 수 있다.

너무 작은 단위로 나누어 하나하나 의미없는 commit을 하는 것도 좋지 않지만,

이번의 나처럼(...) commit 을 하지 않고 이 작업, 저 작업을 하다보면

Modify 부분에 Add와 Create 영역이 섞여 들어가며 이 것이 과연 hitory storage인가, pull을 위한 storage인가..

잘게 쪼아 나눈 의미없는 commit 만큼이나 의미없는 것이 되어버린다.

 

(반성한다는 의미)

---

프로젝트에 효과적인 Git 사용

 

이전에 했던 프로젝트에서는 단순히 팀원들간의 공유 공간으로 git을 할용했기 때문에

'push 하기전에 pull을 반드시 해야한다' 라는 규칙만 알고, 적용하면 됐었지만

 

이번 프로젝트에서는 기능별로 branch를 나누어 팀원들이 서로 다른 branch에서 작업하고

하나의 작업공간에 다시 합쳐지는 방식으로 작업했다.

 

하지만 여기서도 반성할 것이 하나 있다.

branch를 나누어 갖는다는 것은 기능별로 branch가 존재한다는 것인데,

나는 branch를 나누고, 다시 원본에서 branch를 뻗어나가지 않고

그냥 작업마친 branch에서 또다른 branch를 뻗어나갔다(...)

 

...기록으로 남겨두고 반성하라는 의미

 반면 우리 서버팀은 착실히 네트워크 관리를 하고있었다

삐져나간 친구들은 어쩔 수 없이 다시 돌아올 수 없는 아이들이었다...

이번 프로젝트에서 지향(하려)했던 룰은 다음과 같다.

 

1. 원본 repository는 팀장이 만든다.

2. 팀원들은 해당 repo를 fork한 후 feature 단위로 git에 이슈를 남기고 해당 이슈번호로 branch를 만들어 작업한다.

3. 원본 repository에 직접 push하지 않고, 해당 branch에 push

4. 팀원들과 작업한 feature에 대해 공유, 코드리뷰 한다.

5. 코드리뷰를 마친 뒤 해당 branch를 pull request를 통해 약속한 repo에 보낸다. (우리팀의 경우 dev branch)

6. pull 을 통해 팀원의 코드와 내 코드를 다시 원본 repo에 가져온다.

7. 2번으로 돌아가서 반복 작업한다.

 

나는 위의 과정 중에 4, 6, 7번 작업을 생략한 경우가 많았고,그래서 위의 네트워크가 저런 모양이 된 것이다..^^

 

---

첫 프로젝트를 반면교사삼아 git에 대한 명확한 이해와 사용을 할수 있게 된것 같다.

 

제대로 알고 제대로 사용하자!