🌟 220709.TIL

Git ?

버전 관리 소프트웨어
가장 대중적으로 쓰인다

• 과거 작업으로 회귀 가능
• 과거 작업내용 열람 가능

처음 해야 하는 것

// 작업 파일을 터미널로 열고
git config --global user.email "???@???.com"
git config --global user.name "username"

// 작업 폴더를 vscode로 열고
git init

git init 명령어를 입력하면 git이 작업 폴더를 주시한다

Add & commit

git add 파일명.확장자
git commit -m '코멘트'

add 명령어를 사용해 staging area 로 파일을 저장해놓는 과정을 스테이징,

스테이징 된 파일을 repository로 이동 시키는것 (commit)을 버전 생성한다 라고 한다

굳이 add 와 commit 을 나누는 이유는

모든 파일을 다 저장하지 않아도 되기 때문

예를 들어 이미지 파일은 어지간하면 변경되지 않기때문에 매번 저장해 줄 필요가 없다

주로 쓰이는 명령어

git add . // 모든 파일 스테이징
git status // 어떤 파일을 스테이징 해 놓았는지, 수정이 되었는지 알 수 있음
git log --all --oneline // 지금까지 커밋 한 내용 확인

git diff

git diff // 최근 변경사항 알려줌
git difftool // vim 을 이용한 변경사항 알려줌
git difftool '커밋id' '커밋id' // 커밋id를 입력해서 특정 버전끼리의 차이점을 알려줌

근데 요즘엔 이런거 안씀

git graph 를 사용하면 훨씬 더 깔끔하게 볼 수 있다

이런식으로

복사본 만들기 - branch 기능

commit의 복사본 만들기

git branch '이름'
// '이름' 이라는 이름으로 최근 커밋의 사본을 만듬
git switch '이름'
// '이름' 이라는 branch로 이동

gitgraph로 본 branch

secondbranch 에서 작업을 하다가

master 로 변경하면?

브랜치를 복제했던 분기로 되돌아 간다

master 브랜치와 합치고 싶다면

master 브랜치로 이동 한 후

git merge '대상 브랜치'
// 이렇게 입력하면 대상브랜치가 master 브랜치와 병합(merge)된다 !

gitgraph 로 본 merge

예쁘다!

궁금한 게 갑자기 생겼다

그렇다면

브랜치의 브랜치의 브랜치의……

이런식으로도 만들 수 있을까 ?

될 것 같아서 바로 해봤다

너무 예쁘다 !

그런데…

병합할때 똑같은 파일을 수정해 병합하게 되면 conflict error 가 발생한다

오류가 발생하는 이유?

개발하는 과정에서, 하나의 기능에 대한 변경 요구사항을
반영하기 위해 특정 파일을 변경하게 되고 이는 해당 파일과 정보를
주고받는 다른 파일로 전파되어 추가적인 변경 작업을 요하게 된다. 이 때,
여러 개발자들이 서로 협의하지 않은 채 다른 기능을 동시 병렬적으로
변경하다가 동일한 파일을 변경할 경우 병합 충돌(merge conflict)이 발생할
수 있다(Berzins and Dampier, 1996). 이렇게 파일 간 정보 교환으로 인해
종속성이 존재하는 시스템을 동시 병렬적으로 개발하다가 충돌이 발생하는
상황을 그림 1.3과 같이 표현할 수 있다. 병합 충돌의 유형에는 구문 충돌,
의미 충돌, 구조 충돌 등이 있으며 이로 인해 파일 내에서 충돌이 발생할
수 있다(Mens, 2002). 이를 해결하는 방법론에 대한 연구로는 충돌이 발생한
이후 수정된 내역을 추가로 수정하거나 제거함으로써 해결하는
전략(Munson and Dewan, 1994; Edwards, 1997), 충돌을 발생시킨 두 개발자가
각자의 버전을 통합하기 위해 협력하는 방법론(Brosch et al., 2009) 등 병합
충돌에 대한 연구가 활발히 이루어져 왔다.

(출처) : Identifying Potentially Conflicting Files by Predicting Change Probability using Software Change Log Data( 소프트웨어의 파일 변경 확률 예측을 통한 충돌 가능성이 있는 파일의 식별 - 이주용)

논문을 다 읽어보기엔 얇은 지식으로 너무 어려웠고

내가 얻고자 했던 요점은 개발자들은 개발협업 과정에서 같이 동시다발적으로 개발하는데

예를들어 오픈소스 프로그램의 경우 서로 협의하지 않고 다른 기능을 동시에 병력적으로 개발하다가

간혹 동일한 파일을 변경하면 충돌이 일어난다는 것이다

어설프게 대충 구현해본 conflict error

터미널 상황은 이렇다

윗쪽이 master branch

아랫쪽이 conflictTest branch 인데

병합하려고 하니까 오류가 발행한다는 것이다

vscode 는 고맙게도 4가지 옵션으로 conflict error 를 해결할 수 있게 옵션을 만들어 놓았다

Accept Current Change

- HEAD, 기존(master) 브랜치를 적용

Accept Incoming Change

- 변경된 부분을 적용. 병합 대상이 된 브랜치의 내용을 적용

Accept Both Change

- 둘 다 적용
- 방식이 조금 특이한데 변경된 부분 둘 다를 한꺼번에 적용한다

Compare Change

- error 부분을 비교분석 할 수 있게 보여줌

fast-forward merge

지금까지 배웠던 방식은 3-way merge 라고 하는데

만약 HEAD 브랜치에 수정사항이 없고

작업한 브랜치를 HEAD 브랜치와 병합하고 싶다면

출처 : https://backlog.com/git-tutorial/kr/stepup/stepup1_4.html

이런식으로 작업한 브랜치(bugfix)를 HEAD 브랜치(master)로 바꿔줌으로써 간단하게 병합할 수 있다

gitgraph 로 fast-forward merge 를 하려고 하면 이런 창이 뜨는데

Create a new commit even if fast-forward is possible

(fast-forward 가 가능하더라도 새 커밋을 만들까요?)

옵션을 체크해제 하면

체크했을때와 체크하지 않았을때의 차이

git rebase

강제로 fast-forward merge 를 하고싶을 때 쓴다

윗 상황처럼 HEAD 브랜치에 수정사항이 없다면 바로 할 수 있지만

그렇지 않은 경우에는

신규브랜치의 시작점을 HEAD 브랜치 최근 커밋으로 옮긴 다음 병합한다

왜 이걸 쓰냐면

전부 3-way merge 를 하면 복잡하고 log 출력시 병합된 다른 브랜치들의 커밋내용도 출력되서

알아보기 힘들어서 그렇다고 한다

추가로 squash and merge 하는 방법도 있고

github 에 내 파일을 올려 보기

1. 깃 허브에 레포지토리 하나를 생성한다

1. private / public 설정해서 이름도 예쁘게 짓고

1. 이거 터미널에 복사하고 붙혀넣기 한다

1. 이렇게

1. 쨔쟌

추가로

로컬 리포지토리의 파일을 리모트 리포지토리로 올리는 것을 '푸시(Push)'

리모트 리포지토리에서 로컬 리포지토리로 내려받는 것을 '풀(Pull)'

라고 하는데

이러한 명령을 이용해서 가져올수도, 올릴수도 있다.

vscode 에는 여기서 쉽게 할 수 있다

오늘이 가장 힘들었다

오류가 정말정말 많이 났다

정말로 정말로 많이났다

아니 정말 진짜로 많이났다

하나 해결하면 하나 오류뜨는 수준

궁금해서 이것저것 건드려본게 문제라면 문제일 수 있겠다 😇

뭐만 잘못 누르면 커밋이 갑자기 안된다

경로가 잘못됐다고 하지를 않나, 디렉토리를 찾을 수 없다고 하지를 않나

처음 써보는 거라고 해도 하나만 딱 잘못건드려도 오류가 난다니

정말 대단히 무섭지 않을 수 없었다

그럼에도 개발자가 깃을 다룰 수 없다면 회사에서 못쓴다고 할 정도로 중요하기에

언젠가는 꼭 제대로 공부해야겠다고 생각했다

오늘은 튜토리얼이고 정말 간단한 기능들만 배웠지만 말이다

버전관리, 과거로 돌아갈 수 있다는 점

마치 타임머신을 타고 여행하는 느낌이 너무 낭만적이다

실제로는 코드를 이전으로 되돌린다는게 그렇게 좋은 의미가 아닐 것 같지만 🫢