Post

[프로젝트 일지 #3-1] GIT

[프로젝트 일지 #3-1] GIT

🎯 배경

지금 고민을 해봐야할것이 CI/CD툴만 가지고 배포가 가능한지 생각해봐야 한다고 생각한다. 결론부터 말하자면 가능은하다. 하지만 일반적으로 CI/CD 서버와 서버 작성 서버는 서로 다르다. 그렇다는 얘기는 CI/CD 서버로 파일을 전송을 시켜야 된다는 이야기인데 그러면 개발자가 그 파일을 직접 옮겨야 하는걸까? 물론 그렇게 할 수 도 있곘지만 생각보다 귀찮을거 같다. 생각해보면 파일을 옮길려고 CI/CD툴을 사용하는건데 이걸 수동으로 옮긴다고? 그렇게되면 CI/CD를 사용하는 의미가 퇴색되어진다고 생각한다. 그렇다면 CI/CD툴은 어떻게 파일을 배포 서버로 옮길 수 있을까? 그건 바로 GIT이라는 코드저장소를 이용하면 된다. GIT은 외부에 있다. 즉, 외부에서 코드를 저장하고 CI/CD에서 그 정보들을 가져온다면 개발자가 수동으로 옮길 필요는 없어진다. 그러면 본격적으로 GIT에 대해 학습해보자. (여기에서는 GIT 명령어에 대한 내용은 없을 수도 있다.)

⚙️ 핵심 내용 (What & How)

  • GIT의 동작원리
  • GIT의 존재의의

🔑 결과와 인사이트 (So what?)

주의사항

여기는 GIT의 명령어에 대해 상세하게 설명하지는 않는다. 따라서 add, commit등 명령어는 없을수 있다.

GIT의 동작원리

git은 두가지의 저장소를 가지고 있다. 원격 저장소와 로컬 저장소로 구분되어져 있다. 생각해보면, 우리는 코드를 외부 즉, 웹 사이트에 저장을 시켜놓는다. 그렇다면 우리는 직접 웹사이트에 코드를 등록을 할까? 그렇게도 할 수도 있지만 대부분 그렇게 하지 않는다. 아까 저장소는 로컬 저장소가 있다고 했다. 그렇다는 이야기는 이 로컬 저장소를 이용해서 원격 저장소로 코드를 등록한다는 뜻이 된다.

대강 다이어그램을 그려보면

로컬 저장소 –> 원격 저장소

라는건데 로컬 저장소는 어떻게 원격 저장소로 코드를 옮길 수 있을까?

이 작업을 우리는 push라고 부른다.

push: 로컬 저장소에서 원격 저장소로 코드를 옮기는 작업이다.

1
git push {원격 저장소 브렌치}

근데 이상하다. 코드는 옮기는건 알겠는데 로컬은 원격을 어떻게 알고 전달 할 수 있을까? github나 gitlab을 보면 알 수 있지만 모든 사람들이 코드를 한곳에서 볼 수 있는건 아니다. 그렇다는 이야기는 특정한 곳(repository)로 들어가서 코드를 읽어야 한다는건데 그 수많은 repository를 어떻게 구분할 수 있을까?

그것은 로컬 저장소에 그 정보를 저장을 해놓으면 된다.

1
git remote add {원격 저장소 이름} {원격 저장소 주소}

이름을 지정하는 이유는 정확히 어느곳으로 코드를 옮기는지 알기 위함이다. 이것을 다시 말하면 원격 저장소 등록은 여러개를 할 수 있다는 뜻이 된다. 결국 이것을 통해 push 명령어를 사용할때 어느곳으로 코드를 옮길지 결정할 수 있다.

자 이렇게 코드를 옮겼으면 코드를 받을 수도 있어야 한다. 왜냐하면 발송만 존재하고 수신이 없으면 뭔가 이상하다고 생각이 들기 때문이다.

당연히 원격 저장소 –> 로컬 저장소로 코드를 옮기는 것도 가능하다.

이것을 pull이라고 부른다.

1
git pull {원격 저장소 브렌치}

이것또한 이름을 명시를 해줘야 한다. 물론 default로 지정한곳으로 우선적으로 되기때문에 명시하지 않아도 되긴한다.

분산 버전 관리의 필요성

로컬 저장소와 원격 저장소가 각각 존재하는 의미가 무엇일까? 원격이 있다는건 로컬 저장소가 한개가 아닐수도 있다는 뜻이 된다.

그렇다는 이야기는 코드가 섞일 수 있다는 뜻이 된다. 이것을 다시 말하면 1번 로컬 저장소에서 push한 코드와 2번 로컬 저장소에서 push한 코드가 다를 수 있다는 뜻이 된다.

사실 이렇게 되면 안된다. 1번이 2번으로 바뀌는것도 문제지만 두개가 섞이는것도 문제가 되어진다.

그것을 판단은 어떻게 할 수 있을까? 아쉽게도 그건 git이 해주는것이 아니다.

1번 코드에서 2번 코드로 발전되었다면 pull을 땡겨왔을때 그것을 반영을 시켜줘야 한다. 이것을 merge라고 부른다.

자세한건 작성하지 않았다. 예를들어 충돌같은 경우는 작성되지 않았다.

GIT의 존재의의

만약에 git이 존재하지 않는다면 어떻게 될까? 코드를 직접 갖다줘야 할거라 생각한다. 이걸 수치화한다고 생각하면 약 200배의 효율을 낼 수 있다고 생각한다. 직접 갖다 주려면 코드를 압축을 해야 하고 그것을 메일이나 SNS로 전달을 해야 하기때문이다. 이러한 시간들을 고려했을때 엄청난 시간 단축이 가능해졌다.

즉, git은 코드를 단순히 저장하고 불러오는것에 넘어서 협업을 하기 위해 필수라고 생각이 든다. 그렇다고 해서 git이 존재함으로 잃는 손실도 생각을 해야 한다고 생각한다.

무엇이 있을까? 간단하다. 그건바로 GIT을 알아야 한다는 부담감이라 생각한다.

git을 또 배워야 한다니… git 명령어를 알아야 하는걸까?

다행히 요즘에는 git사용을 도와주는 도구들이 많이 등장했기때문에 git명령어 학습하는것에 대한 부담감은 줄었다고 생각한다.

하지만 그러한 도구들은 디테일한 부분을 처리해주지 않기 때문에 git명령어를 학습해놓는것이 좋다고 개인적으로 생각한다.

즉, git의 존재의의는 협업이라 생각한다. 그래서 더 git을 잘 사용해야 한다. 자칫하다가는 충돌난다.

📝 요약 (One-liner)

Git은 분산 버전 관리 시스템으로, 로컬과 원격 저장소를 통해 효율적인 코드 협업을 가능하게 합니다.

결론

  1. Git은 코드 공유와 버전 관리를 혁신적으로 개선했습니다.
  2. 로컬과 원격 저장소의 분리는 개발자 간 협업의 핵심입니다.
  3. Git 명령어 학습은 초기 진입 장벽이 될 수 있지만, 충돌 해결 등 세밀한 제어를 위해 중요합니다.
  4. 현대적인 GUI 도구들이 있지만, Git의 핵심 개념과 명령어를 이해하는 것이 장기적으로 더 유용합니다.

다음에 진행할일

AI가 이거저거 알려주긴했는데 사실 이걸하는 목적은 GIT학습이 아니니까.. 넘어가고 그다음은 CI/CD툴 확인을 확인을 해야 할거 같다. 그리고 나서 프론트와 백을 구분짓을거구 다음 과정은 분리 포스팅 이후에 작성이 될거 같다.

This post is licensed under CC BY 4.0 by the author.