github를 통한 협업 요약 (1)

programming을 할 때 유지 보수 (maintance) 과정이 필요하다.

 

대표적인 git tool에 대해 간략히 요약하겠다.

이거를 쓰면 file 복사본을 만들지 않아도 되고 깔끔한 버전 관리가 된다는 장점을 가지고 있다.

 

먼저, 해당 git tool을 사용하려면 설치가 되어있어야겠고 그 확인은

git --version

 

을 통해서 확인할 수 있다. ( 버전이 뜬다면 git tool 설치 성공 )

 

그 후

git config --global user.email "xxx@gmail.com"
git config --global user.name "xxx"

 

을 통해서 git tool을 현재 누가 쓰고 있는지 구분하기 위한 간단한 ID 등록을 한다.

 

 

---

 

 

이제 commit에 대해서 알아 볼건데

우리는 굵직하게 기록을 해두고 싶을 때 그 상황을 저장해서 file의 형태로 기록을 한다.

 

git program에서는 그것을 commit을 통해서 구현하는데 이를 통해 우리는 은행 프로그램을 만들 때

입금 기능을 만들고 commit 을 하고 출금기능을 만들고 commit을 시간순서대로 해놓는다면 입금 기능을 만들 당시로 돌아가고 싶다면 commit 해둔 시점을 찾아 쉽게 돌아갈 수 있다.

 

먼저 directory file에서 git을 사용하고 싶으면

해당 directory 에서 git init을 입력한다.

 

이것은 그 directory에서 일어나는 일들 (source file을 생성 혹은 삭제, code 변경 등)을 git이 추적을 시작한다.

 

vi orange.c

git add orange.c
git commit -m "create orange.c"

 

 

 

 

1. staging area는 commit을 하기 전에 commit할 file들을 모아놓는 곳이다.

git add 명령어로 staging area에 올려둘 수 있다.

잘 올라갔는지 확인하는 방법은 git status를 통해 확인할 수 있다.

 

2. repository는 commit된 file의 버전들을 모아놓는 곳이다.

repository의 실체를 구경하고 싶으면 ls -al을 통해 숨겨진 .git directory를 열어보면된다.

 

 

추가적으로 git status는 file의 변경 사항, staging된 file 같은 것을 쭉 알려준다.

 

git restore --staged file_name

 

staged file을 취소하고 싶을때 사용

 

git commit -m "원하는 메시지"

 

commit 할 때 -m 뒤에 메시지를 입력 가능한데, 메시지에는 보통 어떤 기능을 추가했는 지를 적는다.

 

git log --all --oneline
git log --all --oneline --graph

 

이 명령어들은 commit 기록을 한 눈에 파악하고 싶으면 git log 명령어 입력하면 된다.

--graph 옵션을 넣으면 graph로 그려준다. (다소 보잘것 없음)

 

 

---

 

 

 

만약 commit 하기 전에 이전의 commit 했을 때와 현재 코드의 차이를 알고 싶으면 

git diff
git difftool file_name

 

이 두 명령어를 사용하면 된다.

 

근데 git diff를 생으로 사용하는 거는 가시성이 조금 떨어지므로

두 번째 명령어인 git difftool file_name을 사용하는 것이 가시적으로 더 효과적이다.

 

그리고 나오고 싶을때는 linux나 mac에서 file을 나오듯이 :q 를 통해 나오면 된다.

 

 

---

 

 

이번엔 branch 에 대해 알아볼 것이다.

 

git은 협업에 용이한 program이다.

여기서의 시작은 branch라고 볼 수 있다.

 

만약 협업 툴없이 하나의 program code를 10명에서 동시에 수정하는 작업을 한다면 생각만 해도 어지럽다.

또한,

새로운 기능을 만드는 상황에서 원본 파일에 잘못된 코드를 commit함으로써 기존의 원본 코드가 망가지면 ?? 이것 또한 어지럽다.

 

branch는 간단하게 project의 복사본을 만들어서 거기에 먼저 개발해보기 위한 기능이라고 보면 된다.

이렇게 함으로써, 잘못될 걱정 없이 안전하게 새로운 기능을 추가한다.

 

 

 

commit 1을 했을때가 master branch (main branch) 이고 거기서 두번째 commit을 하고 나서 새로운 기능을 만들거나 혹은 협업을 할 시에 branch 생성을 한다.

그러면 branch 생성 후 생성된 branch에서 기능을 구현하고 나중에 merge하는 식으로 하나의 project를 여러명에서 협업할 수 있다.

 

사용법은,

# Syntax : git branch branch_name
git branch slave

 

이렇게 하면 slave라는 이름의 branch가 생성된다.

# Syntax : git swithch branch_name
git switch slave

 

현재 branch name이 master (main)라면 slave branch로 가기 위해서는 switch를 사용하면 된다.

 

이걸 사용하는 중에 어떤 branch에 와있는지 까먹었다면 git status로 확인 가능하다.

 

 

 

말했다 싶이 이렇게 branch를 통해서 작업하다가 괜찮으면 기능완성 후 merge

merge 를 하고 싶다면 그 방법은

git switch master
git merge branch_name

 

먼저 master branch로 위치를 바꿔주고 merge branch_name을 해주면 slave에서 작성한 code와 file들이 master branch로 merge된다.

 

## 하지만 여기서 주의 사항이 있다.

만약 master branch와 slave branch를 병합할 때 같은 source file의 같은 line에 두 branch에서 서로 다른 code로 수정이 되어있을 경우, conflict가 발생하는 데 이것은

merge 시에 confilct message

 

app.txt context

app.txt에서 HEAD는 현재 나의 위치고   

==========

slave code인데

 

두 곳 전부에서 수정이 일어나서 어떤 코트를 선택할지에 대한 결정을 하면된다.

저기 위의 줄을 다지우고 this is slave branch 내용만 남기고 다시

git add .
git commit -m "수정 완료"

 

를 하면 새로운 commit을 생성해주고 merge conflict가 해결되었고 최종적인 branch 의 merge도 완료되었다.

 

지금까지 요약하면

branch 생성 : git branch branch_name
생성된 branch로 이동 : git switch branch_name
branch merge : master(main) branch로 이동 후 git merge branch_name
commit한 내용을 보고 싶다면 : git log --all --oneline --graph
만약 merge 시에 conflict가 발생한다면 : conflict가 발생한 file을 열어서 수정하고 -> git add . -> git commit