Newbi 개발자 Git 관련 내용 정리

25.09 ~ 26.01 에 있었던 제가  git 관련 겪은 일을 포스팅해보겠습니다.

 

1. LF will be replaced by CRLF

git을 설치하고, 기본 세팅한 프로젝트를 git add .을 하자 아래와 같은 warning이 발생했습니다.

PS C:\경로명> git add . warning: in the working copy of '프로젝트명/.gitignore', 
LF will be replaced by CRLF the next time Git touches it warning: in the working copy of '프로젝트명/build.gradle', 
LF will be replaced by CRLF the next time Git touches it warning: in the working copy of '프로젝트명/gradlew', 
LF will be replaced by CRLF the next time Git touches it warning: in the working copy of '경로명/Main.java', 
LF will be replaced by CRLF the next time Git touches it

위 warning 내용은 "파일명의 작업 복사본에서, 다음에 git이 이 파일을 다룰 때 LF가 CRLF로 바뀔 것입니다."라는 뜻입니다. 현재 이 파일은 리눅스/맥 방식(LF)으로 줄 바꿈 되어 있는데, 윈도 방식(CRLF)으로 자동 변환해서 저장하겠다는 의미입니다.

 

위 경고를 다음에 만났을 때 바로 해결하기 위해선 줄바꿈(Line Ending) 처리 방식을 알아야 합니다. 운영체제(OS)마다 텍스트 파일에서 줄을 바꿀 때 - enter를 할 때 - 사용하는 보이지 않는 기호가 다릅니다.

• Linux/macOS: LF(Line Feed). \n 기호를 사용한다. 커서를 한 줄아래로 이동하는 방식
• Windows: CRLF(Carriage Return Line Feed). \r\n 기호를 사용한다. 커서를 줄 맨 앞으로 이동 후 한 줄 아래로 이동하는 방식

LF will be replaced by CRLF the next time Git touches it warning...의 의미는 현재 프로젝트 폴더 내의 파일들이 linux/mac 방식인 LF로 작성되어 있으니, 내 컴퓨터인 Windows(CRLF) 방식에 맞추어서 git이 자동으로 변환해 주겠다는 뜻입니다.

 

이 경고를 앞으로 발생하지 않게 하려면, 코드를 보낼 때는 LF로 내 컴퓨터로 가져올 때는 내 컴퓨터에 맞게 하는 것이 좋습니다. 만일 협업 정책이 있다면 그에 따르는 게 맞고요.

맥 사용자의 경우는 기본이 LF이므로 warning을 보지 않을 가능성이 높습니다.
윈도우 사용자 기준으로 보낼 때(commit)는 LF로, 받을 때(checkout)는 CRLF로 자동 변환하려면 아래와 같이 git에게 시키면 됩니다.

git config --global core.autocrlf true

2. GitLab 연동을 위한 SSH Key 설정 및 자동화

Gitlab이나 Github을 사용할 때 매번 비밀번호를 입력하는 일은 번거롭습니다. SSH를 설정하면 보안은 강화하면서도 접속 과정은 훨씬간편하게 할 수 있습니다.

*SSH(Secure Shell): 네트워크 상의 다른 컴퓨터에 안전하게 접속하기 위한 프로토콜. 모든 데이터를 암호화해서 중간에 누군가 가로채도 암호화된 기호일 뿐이라 내용을 알 수 없다. 

 

SSH 키 생성

ssh-keygen -t 알고리즘방식 -C "your_email@example.com"

-t ed25519: 생성할 키의 Type을 지정. (ed25519, rsa, ecdsa 등) 

-C "이메일" : 생성하는 키에 대한 주석(Comment)을 추가합니다. 본인의 이메일을 적어 어떤 서비스용인지 구분하는 용도로 사용.

 

`C:\Users\사용자\.ssh`에 2가지 파일이 생성

id_ed25519  : private key로 내 컴퓨터에 보관

id_ed25519.pub : public key로 서버(GitLab, GitHub)에 등록

 

SSH Config 파일 설정으로 접속 자동화 하기

매번 긴 호스트 주소와 포트 번호를 입력하는 건 귀찮은 일입니다. config 파일을 만들면 별명(Alias)만으로 간단히 접속할 수 있습니다. 설정 방법은 아래와 같습니다.

1. .ssh 폴더 안에 새 텍스트 파일 작성.
2. 파일 이름을 확장자 없이 config로 저장.
3. 아래 내용을 입력.

Host 내가 터미널에서 입력할 별칭
 HostName 실제 접속할 서버 주소
 Port 서버 접속 포트 번호(기본 22가 아닌 경우 지정)
 User 접속할 사용자 계정 이름(Git 서비스는 보통 git 사용)
 IdentifyFile ~/.ssh/id_ed25519

 

GitLab에 공개키 등록하기

1. id_ed25519.pub 파일을 메모장으로 열고 전체 내용을 복사
2. GitLab 웹 사이트에 접속하여 [User Settings] -> [SSH Keys] 메뉴로 이동.
3. [Add new key]를 클릭하고 복사한 내용을 붙여 넣고 저장.

연결 테스트 및 신뢰 확인

ssh -T git@호스트주소

처음 연결하면 Are you sure you want to continue connecting (yes/no/[fingerprint])? 라는 질문이 나온다. "이 서버를 처음 보는데 믿을 수 있는 서버가 맞나요?"라는 질문이다. yes를 입력하면 됩니다. 한 번 입력하면 서버 정보가 내 컴퓨터의 known_hosts 파일에 저장되어 다음부터 묻지 않습니다.

 

3. Git 충돌 해결하기

`git push` 명령어를 치자  아래와 같은 오류가 발생했습니다.

To 깃주소.git
 ! [rejected]          로컬 브랜치 -> 서버 브랜치 (non-fast-forward)
error: failed to push some refs to '깃주소.git'
hint: Updates were rejected because the tip of your current branch is behind                                                                                                                                                                                                                                        
hint: its remote counterpart. If you want to integrate the remote changes,
hint: use 'git pull' before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

• 로컬 브랜치에서 원격 브랜치로 전송이 거부되었다. (non-fast-forward 오류)
• 오류: '깃주소. git' 저장소로 일부 참조(코드)를 push 하는 데 실패했다.
• 힌트: 당신의 현재 브랜치(로컬 브랜치)의 끝이 원격 저장소의 끝보다 뒤처져 있기 때문에 업데이트가 거부되었다.
• 힌트: 원격 저장소의 변경 사항을 통합하려면, 다시 psuh 하기 전에 git pull을 먼저 실행하세요.

한 마디로, 내가 코드를 수정하는 동안 다른 동료가 먼저 코드를 수정해서 서버(원격 저장소)에 올려둔 상황입니다. 이때 내가 git push를 통해 내 코드를 억지로 올리면 서버에 올라가 있던 코드가 사라질까 봐 보호 차원에서 push를 막은 것이고요. 그러므로 서버에 있는 최신 코드를 받아와서(git pull), 내 코드와 합친 다음에 다시 올리라는 메시지입니다.

 

여기서 잠시 Fast-Forward에 대해서 살펴보자.

Fast-Forward는 원격 저장소(서버)의 마지막 커밋 뒤에 내 커밋(로컬 커밋)을 그대로 이어 붙이기만 하면 되는 상황입니다.

서버: A -> B -> C

로컬: C -> D

이렇게 있는 경우 로컬 커밋을 서버로 push 하면 A -> B -> C -> D로 그대로 이어 붙이면 된다. Git은 단순히 빨리 감기하듯 최신 위치를 D로 옮기면 됩니다.

 

문제는 Non-Fast-Forward인데, 앞에서 본 것처럼 내가 작업하는 동안 누군가 서버에 새로운 커밋을 넣었을 때 발생합니다.

서버: A -> B -> C->E(동료의 커밋)

로컬: C-> D(나의 커밋)

이 경우 로컬 커밋을 서버로 push하면  A->B->C-> E로(내 것을 무시할지) 할지 A-> B->C -> D(동료 것을 무시하고 덮어쓰기 할지)로 할지 선택해야 합니다. 이 부분은 git이 자동으로 판단하지 않고 개발자에게 맡겨야 하므로 reject 하게 됩니다.

 

그러나 이후에 git pull을 수행하자 문제가 발생했습니다.

error: You have not concluded your merge (MERGE_HEAD exists).
hint: Please, commit your changes before merging.
fatal: Exiting because of unfinished merge.

• 오류: 아직 Merge 작업을 끝내지 않았습니다. (MERGE_HEAD 파일이 존재합니다)
• 힌트: merge를 하기 전에 현재 변경 사항들을 먼저 commit 해주세요.
• 치명적 오류: 미완성된 merge 작업이 남아있어서 명령어 실행을 종료합니다.

이전에 git pull이나 git merge를 시도했다가 충돌이 발생하거나 중단된 적이 있습니다. 이 증거로. git/MERGE_HEAD라는 파일이 남아있으므로 Git은 새로운 병합(git pull)을 절대 허락하지 않는다. git pull은 git fetch + git merge를 수행한 것이기 때문에 새로운 병합을 포함하고 있습니다.

 

이를 해결하는 방법은 1) merge 작업 자체를 취소하거나 2) 마저 합친다. 두 가지 방법이 있습니다

1) merge 작업 자체를 취소하는 경우: git merge --abort 명령어를 수행

2) 마저 합친다: git status로 충돌 난 것을 확인하고 충돌 해결(없으면 그대로) > git add . > git commit -m "원격 변화를 머지하고 충돌을 고친다" 이 작업을 수행하면 MERGE_HEAD가 사라지므로 다시 git pull이나 git push를 하면 됩니다.

 

내가 해야 했던 것은 1)의 방식인데 2)를 수행한 문제가 있었습니다. merge를 취소하는 방식은 아래와 같습니다.

- 로컬에서 머지 전 상태로 돌린다: git reset --hard HEAD~1

- reabse 방식으로 pull 받기: git pull --rebase origin 로컬_브랜치명

  - 이 rebase로 pull 받는 과정에서 충돌이 나면 해결하고 git add .을 수행

  - git rebase --continue

- 원격에 강제로 덮어쓰기를 한다.(원격기록을 변화시켜야 했다) : git push origin 로컬_브랜치명 --force  

 

후기

Git과 같은 가장 기본적인 도구들을 얼마나 능숙하고 꼼꼼하게 다루는지는 중요하다는 것을 다시 느낍니다. Git, gitattributes, gitignore 등을 제대로 학습해야겠습니다. 우선, 경고나 워닝이 나오는 것을 꼼꼼히 읽겠습니다.