Git GitHub CUI

Viva의 놀이터·2020년 10월 7일
0

Git & GitHub

목록 보기
2/2

git을 사용하는 2번째 방법인 CUI를 알아보자

목차

로컬저장소 추가하기

add, commit 자세히 알아보기

branch 알아보기

merge로 버전 합치기

branch 충돌 해결하기

다른 저장소 Fork하기

Pull request 하기

느낀점

add, commit 자세히 알아보기

add는 이전에 말한것과 같이 파일을 선택하는 개념이다.
commit은 add에서 선택한 파일을 저장하는 개념이다.

(a,b,c,)를 add 하고 commit을 하였다. 그럼 저장소에 (a,b,c)가 들어있고

b를 b1로 수정을하고 c를 c1로 수정을하고 d를 추가해서 add한뒤에 commit을하면 저장소에는 (a,b1,c1,d)가 들어가 있다.

마지막으로 a를 삭제하고 b1을 다시 b로 c는 c2로 수정하고 add를 한뒤에 commit을하면 저장소에는 (b,c2,d)가 들어가 있다.

branch 알아보기

branch는 쉽게 말해 "다른이름으로 저장" 이라고 생각하면 편하다.

기존의 파일에서 다른 버전으로 혹은 색 다르게 만들어 보기 위해서 다른이름으로 저장한 뒤 원본 파일이랑은 다르게 자유롭게 작업하는것과 비슷하다.

명령어는 "git branch 변수명" 이다.

만든 브랜치로 이동하기 위해서는 "git checkout 브랜치이름" 입력해주면 해당 브랜치로 이동이 된다.
ex) git branch Branch1 => Branch1 브랜치 생성
ex) git checkout Branch1 => Branch1 브랜치로 이동

이동한 브랜치에서 작업을 해주면 된다.

merge로 버전 합치기

merge는 여러 갈래로 파생된 브랜치를 병합 할 때 사용한다.
예를 들어 위의 그림을 기준으로 Branch1과 Master을 병합할 때 사용하는
명령어다.

merge를 할 때 우선 기준이 되는 브랜치로 이동을하고(git checkout 기준)
합치고 싶은 브랜치를 병합시킨다.(git merge 원하는 브랜치)

branch 충돌 해결하기

브랜치끼리 병합을 하다가 종종 충돌이(conflict) 발생을한다.
이는 브랜치끼리 병합을 했을 때 겹치는 부분중 어디를 삭제하고 어디를 남길지를 사용자가 결정해야 할 때 발생을 한다.

ex)

git checkout master ==> master 브랜치로 이동
git branck merge_test ==> merge_test 브랜치 생성
(파일 수정)
git add . ==> master 브랜치 스테이지에 수정 파일 올림
git commit -m "여기에 merge를 할거임" ==> 수정 파일 커밋
git push ==> master 브랜치에 수정된 부분 저장
git checkout merge_test ==> master 브랜치에서 merge_test 브랜치로 이동
(파일 수정) ==> merge_test의 파일 수정
git add . ==> merge_test 브랜치 스테이지에 수정 파일 올림
git commit -m "충돌시킬 무언가" ==> 수정 파일 커밋
git push ==> merge_test 브랜치에 수정된 부분 저장
git checkout master ==> merge_test 브랜치에서 master 브랜치로 이동
git merge merge_test ==> 기준인 master 브랜치에서 merge_test 브랜치 병합
(충돌 발생)

이런식의 병합 충돌이 일어난다. 여기서
<<<< HEAD ... ==== ... >>>> merge_test 사이에 들어가는 부분이 충돌이 일어나서 사용자의 결정을 기다리는 부분이다. 따라서 저 부분을 사용자가 원하느 방식으로 수정한뒤에

원하는 방식으로 수정한뒤에

다시 add, commit, push 해주면 충돌이 해결되고 병합이 성공적으로 이뤄진다.

다른 저장소 Fork하기

처음에 언급했던것과 같이 git과 github는 다른 사람과 협업을 도와주는 도구이다.

Fork는 쉽게 말하면 다른사람의 원격 저장소를 복사하여 가져오는 행동위를 말한다.

Fork를 하고 clone을 통해서 로컬 저장소에 생성하는 것이 일반적이다.

Pull request 하기

Fork하여 생성한 저장소에서 작업을 한 뒤에 원본 저장소에 push 혹은 merge를 하기위해서 사용하는 것이 Pull request이다.

pull request는 "내가 코드를 만들었는데 원본에 병합해도 되겠니??"
라는 의미이다. 이 명령어를 사용하면 원본과 요청된 코드의 차이점을 알기 쉽게 리뷰할 수 있다. 또 같이 협업하는 저장소이기에 다른 팀원에게 내가 어떤부분을 수정했는지 알려주는 역할을 한다.

PR(pull request)을 하는 이유:
여러명이 같이 개발을하느데 자기가 개발하고 바로 push 혹은 merge를 하면 마지막으로 내가 본 코드랑 현재 바뀐 코드를 비교하기 힘들고 저장소를 관리하기가 힘들기 때문이다. 즉 저장소를 효율적으로 관리하기위한 개발자들의 약속이다.

공부하다 알게된 브랜치 관리 tip!!

feat/기능이름 => 프로젝트에서 작동하는 기능을 하나씩 만들 때 사용한다.

fix/버그 이름, hotfix/급한버그 ==> 프로그램에서 발생하는 오류를 해결하기 위한 작업을 저장하는 브랜치

기능, 오류 작업이 끝이나면 메인 브랜치(보통 dev, master)로 PR(pull request)을 보낸다.

메인관리자 혹은 사수 혹은 동료개발자가 PR 요청을 보고 수락한다.

또한 메인 브랜치에 커밋을 할 때는 신중하게 해야하는데 개발을 하는데 정신이 없는 상태에서 커밋의 말투까지 신경을 쓰면서 하기 어렵기에 리뷰어가 PR을보고 해당 내용을 정리헤서 메인 브랜치에 커밋을 한다고 한다.

느낀점

프로그래밍을 하다보면 사람들이 git을 많이 쓰고 진짜 편리한 도구라고들하는데 잘 알지못했던 나는 그것에 공함하기 어려웠다. 하지만 이번에 git과 github를 공부하고 나서 왜 이러한 기술들이 중요한지를 확실하게 느꼈다. git을 공부하기전 git을 통해서 협업을 한적이있는데 그때 PR을 보내지 않고 혼자 push하고 merge를 해서 같이하던 동료가 고생을 했었는데 이제 왜 고생을했는지 이해가 되고 미안하기도 하다.

profile
역사를 잊은 기술에겐 미래가 없다

0개의 댓글