[초심자를 위한] Git은 이거면 돼 😊

Wang Hoeun·2024년 10월 24일
git초심자를 위한
2

초심자를 위한

목록 보기
4/4

같은 학교 학우분들께 Git 강의를 진행하며 작성한 내용입니다.
https://lapis-drifter-4ad.notion.site/s-Git-125215570276800ca817fa5a68d22a8f?pvs=4
=> 노션 원본 바로가기

Git 이란?

이게 뭔소리여~! 싶은 사전적 정의를 함께 살펴봅시다 ! ⇒

💡
Git은 분산 버전 관리 시스템(DVCS)으로, 파일의 변경 이력을 추적하고 여러 사람과 협력하여 작업할 수 있도록 돕는 도구이다.
Git을 사용하면 프로젝트의 소스 코드나 문서 등의 변화를 기록하고, 언제든지 과거의 특정 시점으로 되돌릴 수 있다.
또한, 분산 저장소를 기반으로 하기 때문에, 모든 사용자는 프로젝트의 전체 히스토리를 로컬에 저장하고 있어 인터넷 연결 없이도 작업이 가능합니다.

github란?

💡
GitHub는 Git을 기반으로 한 웹 호스팅 서비스로, Git 저장소를 온라인에서 호스팅하고 관리할 수 있도록 도와준다.
개발자들은 GitHub를 사용해 코드 버전 관리를 쉽게 할 수 있으며, 전 세계 사람들과 협업하여 소프트웨어 프로젝트를 진행할 수 있다.

일단 가장 먼저 git 설치,github 계정 만들기 !

(직접 보여줄게요)

구글링 하면 너무 잘 나오지만,

git 홈페이지에 들어가서 git 을 설치한다 ! 자신의 운영체제에 맞는 git 을 선택하고 설치한다.

다 설치 했는데 확인하는 경우에는 git --version 을 입력해 git 의 버전 여부를 확인하면 된다.

<그런 뒤 내 github 계정과 연결해줘서 어떤 계정인지 알려줘야겠지!>

[1] 난 그냥 터미널에서 작업할거다!

그러면 github 에서 계정 만들고, user.name이랑 user.email

아마도.. git config —global user.name 이런식으로 설정해주면 될거임!! 그렇게 설정 따로 해주기!

[2] Intellij 나 VSCode 같은 IDE로 코드 작업하는 사람이다~ (대부분이 이거겠죠~?)

그러면 github 계정을 각 IDE에 연결 시켜주기 !

Intellij는 settings 들어가서 Version Control 에 github 있을거임 ! 거기서 내 계정 연동 시키고,

VSCode는 좌측 하단에 github랑 연동하는 버튼이 바로 있다 ! 거기서 내 계정 연동 시키면 되는거다!!

<그런 뒤 이 폴더는 git 을 사용할 폴더라는 것을 알려줘야겠지 !! git 사용 활성화>

[1] 나는 내가 먼저 폴더 만들고 git repo에 올릴거다 ! 하면

자기 경로에 폴더 생성하고 해당 폴더에서 git init 을 해준다 !

그러고 git remote 설정해줘서 push 하면 되는거임 (이건 바로 밑에서 이어서 설명 예정!)

[2] 그게 아니라 나는 그냥 미리 생성된 repo clone 부터 받을거다!

깃허브에 들어가면 레포지토리를 만들 수 있다.

내 개인 레포를 팔 수도 있고, organization 을 만들어서 해당 organization 에서 공용 레포를 팔 수도 있다 !
(물론 개인 레포를 public으로 팔수도 있음 ! 하지만 여러명이면 그냥 organization 파는것도 추천! 다양한 파트의 레포를 한번에 관리할 수 있어서)

레포지토리를 만들게 되면 home에 보이는 초록색 버튼! 해당 부분을 눌러서 repo의 url을 복사 해준다.

그런 후 내가 만든 내 로컬 경로(폴더)에 터미널을 열어서 git clone “복사한 repo url”을 넣어준다.

그러면 repo 와 연결이 자동으로 되며 git 저장소로 활성화도 완료 !!

remote local

remote 가 뭐고, local 이 뭐여~

git remote :

💡
원격 저장소를 의미하며, 보통 GitHub, GitLab 같은 원격 서버에 저장된 Git 저장소를 가리킨다. 원격 저장소는 협업자들과 코드 변경 사항을 공유하거나, 다른 기기에서 같은 저장소를 접근할 수 있는 위치이다.

⇒ 그니까, 간단히 말하면 이거는 repository 인거다 !!
내 노트북 속 개인 폴더가 아니라, 코드들이 다 올라가 있는 그 위치 !!! 를 의미함! (주소지 같은거임 외부 주소지..? 랄까)

git local :

💡
로컬 컴퓨터에 있는 Git 저장소. 즉, 개발자가 현재 작업 중인 Git 저장소.

⇒그니까, 이거는 내가 지금 작업하고 있는 폴더 !! 아까 폴더 만들어서 나 여기 git 활성화 할게 ~ 하고 git init 해줬잖아 ! 그거 때문에 내 로컬도 git을 쓸 수있게 된거다 !!
이거는 내 컴퓨터를 의미함 !! (내 폴더속 장소~ 내가 코드 입력하고 있는 이 노트북~~)

자, 이해가 안 가면 한번 과정 예시를 들어볼게요.

🚀
일단 협업하려고
1. repository 하나 팠다 !
2. 그러면 clone 받아와서 내 로컬 폴더와 연결 해줬겠지 !! (초록 버튼으로 윗 사진 참고)
3. 막~ 내 코드 작업을 하고 작업 내용 저장까지 했어.
⇒ 그럼 여기서 이 코드들은 어디에 있는걸까요 ~??
4. 바로바로, local 에 있는거에요.
5. 깃허브에 들어가서 아무래 내 코드 어딨나 찾아봐도 없어 !! 내가 로컬에서 작업하던거를 아직 remote(repository) 에 안 올렸으니까!
6. 그래서 이제 다른 사람들도 내 코드 보라고! git remote 를 설정해준 후, 해당 remote 에 push ! 해주는 겁니다~
7. 그제서야 내 로컬속에 있던 코드들은 원격 저장소로 올라가는 것이다!

자 그럼 git remote (원격 저장소)설정은 어떻게 해요 !??! 할 수도 있는데,

git remote -v 라는 명령어를 IDE에서 짠 하고 입력하면,
내가 설정한 remote 주소를 확인할 수 있어요. (나 앞으로 여기를 내 원격저장소로 지정할거야 ! 하는거!)

여기서 만약, git clone 으로 연동을 해줬다면 이미 git origin이 설정된게 있을거고, 그렇지 않다면 아마 아무것도 안 나올 겁니다 !

그럴때

git remote add origin “원격 저장소 url” 를 입력 해주게 되면
내가 어디에다가 이 코드를 올리고 협업할건지 정할 수 있어요.

그러고 다시 git remote -v 입력하면 짜잔 origin 이 잘 설정 되어 있다 !!

각각의 원격 저장소에 붙여진 이름

여기서 우리는 git origin 을 설정할 수 있고, git upstream 을 설정할 수도 있습니다.

그럼 origin은 뭐고, uptsream은 뭐지? 할 수 있는데,
이건 단지 remote 를 나타내는 이름이에요.

origin은 주로 기본 remote를 지칭해요.
가장 기본이 되는 원격 저장소의 이름을 origin이라고 지정해두는 거죠 ! 우리가 작업하는 메인 원격저장소가 origin인 경우가 많습니다.

upstream 은 포크(fork)한 원본 저장소! 를 지정할때의 이름으로 많이 쓰여요.

  • fork란? => 우리가 막 ~ 공용 레포를 만들었는데, 이거 뭔가 나 실험하고 싶은게 하나 있어 !! 근데, 로컬에서 작업하는거 말고 꼭 올려봐야지만 확인이 가능해 !! 싶은거를 공용 레포에 올릴 수 없잖아요 !!! 대표적인게 오픈소스에 관여할때 !! 같은게 있겠죠! 이미 유명하신 분들이 다 만들어둔거에 내가 한 오류 백만개 코드를 repo에 올려서 잘 되는지 테스트 하고 싶을 수 있는데 그러면 안되잖아요 ! 그럴때 보통 내 개인 레포로 fork를 떠와서 개인 레포에서 작업을 한답니다 ! 
요기 fork 버튼 있다 ! repo 우측 상단에

그래서 upstream도 git remote add upstream “fork 떠온 레포의 url”을 입력해주면 git push upstream “올릴 branch” 를 해줄 수 있겠죠 !! origin 에 올리는게 아니라 upstream에만 올리는거닷!

그 외에도 remote를 설정해주고 싶을때가 있는데 아마 여러분은 origin 하나만 사용하는 경우가 많을거고, 뭐.. back-up이나 그런 remote 를 추가해 줄 수 있겠지만 너무 많은 remote는 과부화를 일으키고 오히려 비효율성을 초래하니 권장하진 않습니다!

하지만, 모든것에 그렇듯이 써야할 마땅한 이유가 있고, 장단점에서의 단점을 극복할 수 있다면 사용해도 되겠죠 !

branch 개념

자 그럼 이제 branch에 대해 설명해볼게요!!

branch가 뭐지 ~ 몇번씩 들어봐서 익숙하신 분도 있겠지만요.

사전적 정의를 다시 한번 더 불러오면

💡
Git에서 독립적인 작업 공간을 의미한다.
브랜치는 서로 다른 작업을 병렬적으로 진행할 수 있도록 해 주며, 각 브랜치는 기본적으로 메인(주요) 브랜치로부터 분리되어 별도의 변경 사항을 기록할 수 있다.
브랜치를 사용하면 한 프로젝트에서 여러 가지 기능을 동시에 개발하거나, 실험적인 작업을 할 수 있으며, 메인 코드에 영향을 주지 않고 작업을 진행할 수 있다.

main 에서 뻗어나가는~ 느낌이에요!!

우리가 repository를 만들고 다 똑같은 파일에서 작업을 시작했는데

예를 들면 연재가 1번 상원이가 2번 경훈이가 3번 작업을 맡았는데, 작업이 순차적으로 이뤄져야할때 연재의 작업이 너무 많아서 아직 안 끝났어. 그럼 언제까지나 기다릴 수 없잖아요.

그럴때 필요한게 뭐다? 뭔가 병렬적으로 작업을 진행 할 수 있게 해야겠구나~ 하는거죠.

여기서 아이패드로 설명을 한번 할게요! (main 과 develop 그리고 issue 별)

좀 더 자세하고 다양한 branch 전략 들을 알고싶다면 “branch 전략”이라고 구글링 해가며 공부해보세요 !!

branch도 생성할때 컨벤션을 정합니다. branch를 생성하는데 이름이 중구난방이면 확인하기가 어렵죠.

그래서 컨벤션으로 branch 생성 시 이름을 어떻게 할거냐 ! 라던지,

develop 에서 내려오게 할거냐, 아니면 fork 떠서 branch 생성 개별적으로 하고 공용 repo에 보내는 식으로 할거냐 !! 등등을 정하게 됩니다.

이 부분(브랜치 전략)은 추가적인 공부가 필요한데,

방법을 알려주자면,

일단 사전 조사를 했을때 여러분은 깃 초보자이기에 git을 자주 사용해왔던 다른 팀원들이 익숙한 협업 방식이 있다면 그거로 진행하세요.

하지만 협업을 할때는 말이죠! 무조건 그 이유가 중요해요.

왜? 라는 질문에 답변했을때 그 답변이 타당해야합니다. (아주 중요함. 그냥 무조건 좋아요 하다간 프로젝트 산으로 감)

그 답변이 타당하지 않다면,

제가 추천드린 main - develop - 기능 branch 방식이 가장 기본이 되는 구조일거에요.

branch 명 컨벤션(규칙)은 “commit msg”/”이슈 번호”-”설명” 을 추천드립니다 .

예시 : feat/#3-login chore/#1-cicd

이 구조로 진행하세요.

협업을 처음 해본다면 이 구조가 불편하거나 적합하거나 하는 느낌이 하면서 들 수 있을겁니다.

그때 이제 깨달음을 얻고 아! 다른 구조로 해볼까? 하고 막 검색하고 막~ 찾아보는거에요 !!

그런식으로 공부 시작하면 된답니다 !!

main(master)

내가 지금 어디 branch에 있는지 알고 싶어요!!

그럴때 git branch 라는 명령어를 쳐서 확인하는데요 !!

가장 먼저 git clone을 받아서 git branch를 치게 되면 git main 혹은 git master branch에 위치해 있어서

main

master

이렇게 둘중 하나로 뜨게 될겁니다 !

음.. repo에서 main으로 바꿔주지 않고 clone 했다면 아마 master로 되어있을거구요!

둘은 같은 개념이에요 !!

2020년 전에 git 이 처음 만들어졌을때부터 가장 최상위인 branch명을 master로 지정해왔지만, 2020년 이후부터는 최상위 branch 이름을 main으로 지정하곤 했어요.

그래서 밑 사진과 같이 repository에서 main branch로 바꿔준 후 clone을 받아와도 되구요!

만약 이미 clone을 받아왔다면

  • 이 과정을 따르세요~!!

    이름 변경 방법:

    기존 프로젝트에서 기본 브랜치를 master에서 main으로 변경하려면 아래와 같은 과정을 따릅니다.

    1. 로컬에서 브랜치 이름 변경:

      bash
코드 복사
git branch -m master main

    2. 원격 저장소에서 기본 브랜치 변경:

      • GitHub에서 기본 브랜치를 변경하려면, GitHub의 저장소 설정 페이지에서 Settings -> Branches로 이동해 기본 브랜치를 main으로 변경할 수 있습니다.

    3. 원격 저장소에 푸시:

      bash
코드 복사
git push -u origin main

    4. 이후 master 브랜치 삭제:

      bash
코드 복사
git push origin --delete master

master에서 main 으로 바꾸는게 어렵지 않다 ~~!

checkout 과 switch

checkout 도 들어봤죠 ? 주로 branch를 이동하거나 생성할때 사용하곤 하는데요!!

switch 도 동일한 역할을 합니다.

# checkout 으로 branch를 전환할때
git checkout "브랜치명"
# checkout 으로 branch를 생성 및 전환할때
git checkout -b "브랜치명"

# switch 로 branch를 전환할때
git switch "브랜치명"
# switch로 branch를 생성 및 전환할때
git switch -c "브랜치명"

그렇다면 checkout 과 switch의 차이점은 뭘까요?

  • checkout 과 switch 차이점

    git checkout과 git switch는 Git에서 브랜치를 전환하는 데 사용되지만, 몇 가지 차이점이 있습니다. Git 버전 2.23.0부터는 git switch가 새롭게 도입되었으며, 두 명령어는 용도가 조금 더 명확하게 구분되었습니다.

    1. git checkout:

    • 역할: checkout은 브랜치를 전환하거나, 특정 커밋으로 이동하거나, 파일을 특정 상태로 복원하는 등 다목적으로 사용됩니다.

    • 사용 예시:

      bash
코드 복사
git checkout main         # main 브랜치로 전환
git checkout -b new-branch  # 새 브랜치 생성 및 전환
git checkout commit-hash  # 특정 커밋으로 이동 (detached HEAD 상태)
git checkout file.txt     # 특정 파일을 마지막 커밋의 상태로 복원

    • 다목적 사용의 문제점: checkout 명령어는 너무 많은 기능을 담당하고 있어서, 혼란스러울 수 있습니다. 예를 들어, 브랜치를 전환하는 것과 파일을 복원하는 것이 같은 명령으로 이루어져, 의도를 명확하게 구분하기 어려운 경우가 생길 수 있습니다.

      2. git switch:

    • 역할: switch는 브랜치 전환에만 사용됩니다. 즉, 특정 브랜치로 이동하거나 새로운 브랜치를 생성할 때만 사용되는 명령어입니다. switch는 checkout의 브랜치 전환 기능만을 대체하여, 더 명확하게 동작을 구분하려는 의도로 도입되었습니다.

    • 사용 예시:

      bash
코드 복사
git switch main            # main 브랜치로 전환
git switch -c new-branch   # 새 브랜치 생성 및 전환

    • 명확성: git switch는 브랜치 전환이나 브랜치 생성에만 사용되기 때문에, 의도된 작업이 명확합니다. 파일을 복원하거나 커밋 상태로 이동하는 등의 작업은 switch로는 불가능하고, 이 작업은 여전히 checkout을 사용해야 합니다.

      차이점 요약

    • git checkout: 다목적 명령어로, 브랜치 전환, 커밋으로 이동, 파일 복원 등을 처리합니다.

    • git switch: 브랜치 전환에만 초점을 맞춘 명령어로, 작업 의도를 명확하게 드러냅니다.

      결론

    • git checkout은 여전히 다용도로 사용할 수 있고, 기존 사용자에게 익숙한 명령어입니다. 다만, 다양한 작업을 한 명령어로 수행하는 특성상 혼동이 생길 수 있습니다.

    • git switch는 브랜치 전환이라는 특정 작업에만 사용되며, 그로 인해 작업 의도가 더 명확하고 실수를 줄일 수 있습니다. 따라서, 브랜치 전환 작업만 할 때는 switch를 사용하는 것이 더 직관적이고 명확합니다.

      실무에서 작업할 때 브랜치 전환이 주된 목적이라면 git switch를 사용하는 것이 좋으며, 파일 복원이나 커밋 이동 등 여러 작업을 한 번에 처리하려면 git checkout을 사용할 수 있습니다.

입니다 ~

그래서 저는 예전에 토스분과 협업할때 브랜치 이동만을 목표로 했었기에 switch를 사용했었는데, 저희 학교에서는 switch를 사용하는 사람을 못 봤습니다 ㅠ

하지만 브랜치 이동 만으로 checkout과 switch를 혼동해서 사용하는건 좋지 않아요. (물론 다른 목적으로 이동될때 사용하는건 어쩔 수 없지만)

연재는 checkout을 쓰고 상원이는 switch를 쓰면 안된다는 이야기에요.

  • 다양한 이유 git checkout과 git switch를 같이 사용하는 것은 혼란을 야기할 수 있으며, Git 작업 흐름에서 일관성을 유지하는 데 문제가 생길 수 있습니다. 두 명령어가 유사한 역할을 하지만 목적과 사용성이 다르기 때문에, 혼용할 경우 몇 가지 단점이 발생할 수 있습니다.

    1. 일관성 부족

    • 혼란의 원인: checkout과 switch가 둘 다 브랜치를 전환하는 기능을 제공하지만, 사용 방식이 약간 다릅니다. checkout은 브랜치 전환 외에도 파일 복원, 커밋 이동 등의 기능을 포함하고 있고, switch는 오직 브랜치 전환에만 초점을 맞춥니다. 두 명령어를 혼용하면 작업의 의도와 목적이 혼동될 수 있습니다.

    • 예시: 한 번은 git checkout main을 사용해 브랜치를 전환하고, 다른 상황에서는 git switch main을 사용하는 경우, 사용자는 두 명령어의 차이를 직관적으로 이해하지 못하고 혼란을 겪을 수 있습니다.

      2. 학습 및 유지보수의 어려움

    • 명령어 중복: 협업 중에 팀원들이 checkout과 switch를 혼용하여 사용하면, 팀 내에서 Git 사용 방식이 통일되지 않아 작업 환경이 복잡해집니다. Git 명령어를 처음 배우는 사람들은 두 명령어의 차이와 각 상황에서 어느 명령어를 사용해야 하는지 헷갈릴 수 있습니다.

    • 커뮤니케이션 문제: 팀 내에서 checkout과 switch를 구분해서 사용하면, 커뮤니케이션 시에도 혼란이 생길 수 있습니다. 예를 들어, "브랜치를 전환하려면 switch를 사용해야 한다"는 규칙이 정해졌더라도, checkout을 사용하면 해당 규칙을 깨게 되며 협업 흐름에 혼선을 줄 수 있습니다.

      3. 기능 중복으로 인한 실수 가능성

    • 혼동된 목적: checkout은 브랜치 전환 외에도 특정 파일을 복구하거나 커밋을 이동하는 데도 사용됩니다. switch와 혼용할 경우, 의도하지 않게 브랜치 전환 외의 작업이 수행될 수 있습니다. 예를 들어, 실수로 git checkout some-file을 실행해 특정 파일을 복원하게 되는 상황이 발생할 수 있습니다.

    • 사용 의도의 불일치: checkout과 switch는 겉으로는 비슷해 보이지만, 각각의 목적이 명확히 구분되어 있습니다. 이를 혼용하면, 어느 명령어가 더 적절한지 판단하기 어려워 실수가 발생할 가능성이 커집니다.

      4. 추가 학습 부담

    • Git의 새로운 사용자는 checkout의 다목적 기능과 switch의 브랜치 전환 기능을 모두 배우고 사용해야 하므로 학습 부담이 늘어납니다. 특히, Git 2.23 버전 이후에 도입된 switch를 잘 모르는 사용자는 혼란을 겪을 수 있습니다.

      5. Git 버전에 따른 호환성 문제

    • 구버전 호환성 문제: Git의 2.23 이전 버전에서는 git switch 명령이 지원되지 않습니다. 그래서, 일부 환경에서는 checkout을 사용할 수밖에 없는 경우도 있을 수 있습니다. 이때 두 명령어를 혼용하면 작업 환경에 따라 버전 호환성 문제가 생길 수 있습니다.

      결론

      git checkout과 git switch를 함께 사용하면, 기능이 중복되면서 의도하지 않은 동작이나 혼란이 발생할 수 있습니다. 각 명령어는 사용 목적이 다르므로, 하나의 명령어를 일관되게 사용하는 것이 더 효율적입니다. 브랜치 전환만을 원한다면 switch를 사용하고, 파일 복원이나 커밋 이동과 같은 다양한 작업이 필요할 때 checkout을 사용하는 방식으로 구분하는 것이 좋습니다.

그래서 여러분들이 플젝 하며 마주칠 다양한 사람들이 checkout을 사용한다면 checkout으로 브랜치 이동과 다양한 경우들에서의 기능들을 사용하도록 합시다!

브랜치를 바꿀때 주의할 점! (+ git stash)

추가적으로 branch를 바꿀 때는 chaged 영역과 staging 영역에 변경 사항이 없어야지 바꿀 수 있는데요 ! 모두 다 commit 을 완료 하고 branch를 바꿀 수 있답니다!!

그래서 commit 하고 싶지 않은데 branch를 이동해야할때 git stash 라는 친구도 사용합니다!

  • git stash 란? Git에서 현재 작업 중인 변경 사항을 임시로 저장하고, 작업 디렉토리를 깨끗한 상태로 되돌리는 명령어입니다. 이를 통해, 커밋하지 않은 변경 사항을 잠시 보관해 두고, 다른 브랜치로 전환하거나 급한 버그 수정을 할 수 있는 등의 작업을 할 수 있습니다.

commit 이랑 각 영역은 밑에서 더 설명 드릴게요 !

다양한 명령어

자 그럼 이제 개념들을 어느정도 이해했으니까 명령어들을 알아볼게요.

솔직히 오늘 이거만 외워가도 개념 몰라도 그냥 쓸 순 있다. (대신 원리 모르면 오류나면 못 고침)

그냥 냅다 명령어 사용 과정 보여드릴게요

# 하나하나 꼭꼭 읽어보쟈

git branch # 현재 어떤 브랜치인지 확인
git checkout -b develop # develop branch 만들기 및 이동
git checkout -b "박경훈메롱" # 박경훈 메롱 branch develop 하단에 만들고 이동

# ~~~ 어쩌구 저쩌구 작업함 (코드 쓰기)
# 박경훈메롱 브랜치에서 만들어야 할건 api1, api2, api3 등

# api1 완성
git add .
git commit -m "feat: api1 완성 됐고 뭐뭐뭐 구현함. (최대한 자세히)"
# api2 완성
git add .
git commit -m "feat: api2 완성 됐고 뭐뭐뭐 구현함. (최대한 자세히)"
# api3 완성
git add .
git commit -m "feat: api3 완성 됐고 뭐뭐뭐 구현함. (최대한 자세히)"

# 이제 다함 remote 에 올리고 싶다 origin에!
# push 하기전에 branch 명 까먹었으면 git branch로 확인
git push origin "박경훈메롱" # 현재 branch를 origin에 올린거임!
# push 할때는 꼭 해당 branch로 이동해서 push 해야해요!!

commit.. 의 중요성이랄까

commit 이 뭐죠?

git add . 를 해주고 git commit -m 를 했는데 커밋이 뭔가요~?

💡
Git에서 특정 시점에서의 변경 사항을 저장하는 것을 의미한다.
즉, 프로젝트 파일들의 변경 이력을 저장하고, 이 시점의 상태를 스냅샷처럼 기록하는 것이다.
커밋은 Git의 핵심 개념 중 하나로, Git을 통해 프로젝트를 관리할 때, 모든 중요한 변화는 커밋을 통해 기록된다.

입니다!

그래서 내가 작업하던 내용들을 중간중간 저장해주는거에요.

우리가 물론 ctrl s를 눌러서 해당 내용을 저장할 수 있지만, git 은 내가 ctrl s를 누르던 뭘 하던 알아차리지 못합니다! 왜냐면 ctrl s를 누른건 내 컴퓨터에 저장한거고 git에 저장한게 아니기 때문이에요!!

그래서 git add . 을 해주고 git commit 으로 중간중간의 변경 사항을 깃에서 저장해주는 겁니다!

  • git add 란? Git에서 현재 디렉토리(및 그 하위 디렉토리) 내의 모든 변경된 파일을 스테이징(staging) 영역에 추가하는 명령어이다. 여기서 . 은 현재 디렉토리를 나타내며, 그 디렉토리 안에서 수정된 모든 파일을 스테이징하는 역할을 나타낸다. 현재 변경 되었지만 아직 git에 올라가지 않은 영역이 changed 영역이고,
    git 에 올라가있는 영역을 스테이징 영역이라고 한다. 그래서 changed 영역에서 staging 영역으로 보내기 위해 git add 를 해주는 것이다. . 말고 파일명을 작성하여 해당하는 파일 하나만 staging 영역에 올릴 수 있다 !

commit은 정말 엄청 중요한데요.

내가 작업한 내용들을 복구할때나 git이 꼬였을때 이 commit 만 잘 해놨다면 무조건 복구할 수 있답니다. (물론 push나 pull 도 잘 했어야겠지만!!)

commit 을 하게 되면 각각의 고유한 id 값이 생겨요. 예를 들면

git commit -m “feat: 로그인 api 구현” 으로 commit 을 하면, f4d4f039de5d9d701f84c6543defeef5238049f8 이런 값이 생긴답니다 !!

해당하는 commit id 값은 다양한 비상 상황에서 아주 유용하게 사용할 수 있는데 뭐.. 몇가지 예시를 들어보자면

  1. 헐 내가 main branch에서 작업해버렸어 ㅠㅠ 아직 push 는 안했는데 commit 을 해버렸네 ⇒ rebase 나 cherry-pick 사용
    • rebase 랑 cherry-pick 은 아직은 어려울거 같아서 나중에 하고 싶을때 저를 찾아오시거나 찾아보세요 !!
  2. 헐 내가 develop branch 에서 새로운 브랜치를 만들었어야 했는데, 기존 branch 하위에 만들어버렸어 ㅠㅠ 커밋 내용들을 옮기고 싶어. ⇒ rebase 나 cherry-pick 사용
  3. 헐.. 내가 잘못된 코드를 짰었어. 이 commit 들을 삭제 하고 싶어 자꾸만 오류가 나. 혹은 이 부분부터 끝까지 없애고 싶어 등등 ⇒ git reset --hard 를 사용!

이런 다양한 작업들!! 을 가능하게 해줍니다.

삭제나 어느 시점에서부터의 작업을 이동하는건 가능하지만, commit 순서를 바꾸는건 불가능 해요!!!

예를 들면 자동차를 만드는 코드가 있는데, 자동차 완성 코드랑 자동차의 핸들을 만든 코드의 위치를 바꿀순 없잖아요 !! 이건 꼬여버리게 되기 때문에 그건 안됩니다!

이런식으로!

fetch,merge 와 pull

자, 이제 remote 에 push 하는 법 commit 하는 법을 다 알았으니 받아오는 방법을 알아야겠죠?

내 로컬 속 코드들만 있으면 상대방의 코드에서 연결 해서 코드를 작성할 수가 없으니 말이에요!!

일단 냅다 말해보면 origin 에 있는 내용을 불러오는 명령어는

git pull origin “브랜치명” 입니다.

저는 그중에서도 pull 은 develop branch 에서만 쓰는데요 ! (무조건 그런건 아님)

그 이유는 바로

git 충돌 때문입니다.

충돌 혹은 잘못된 병합

자! 상황을 하나 이야기 해볼게요.

병렬적으로 작업을 분산해서 해도 기본적인 틀은 main branch 와 develop branch 에서 나온 코드니까 겹치는 부분이 있겠죠.

근데 A 라는 사람이 코드 작업을 먼저 마무리 하고 해당 내용을 push 했어요. 그래서 develop 에 반영을 시켰고,

그리고 B 라는 사람이 해당 develop 에 내용을 내가 작업하던 내용에 pull 했는데, 내가 작업한 부분과 위치가 같아서 코드가 충돌이 날 수 있겠죠.

git 이 어느 코드로 병합 시켜야하는지 몰랐을때의 문제에요.

그래서 보통 충돌이 나면 해결해주는데, 사실 오히려 충돌이 나면 다행입니다.

  • 충돌 해결 방법
    • 충돌이 발생한 파일 확인:
      bash
코드 복사
git status
      충돌이 발생한 파일들이 목록에 표시됩니다.
    • 충돌 부분 편집:
      충돌이 발생한 파일을 열어보면, 다음과 같은 표시가 있습니다:
      ```
plaintext
코드 복사
<<<<<<< HEAD
(현재 브랜치의 변경 내용)
=======
(병합하려는 브랜치의 변경 내용)
>>>>>>>
```

여기에서 두 변경 사항 중 하나를 선택하거나, 두 변경 사항을 수동으로 병합한 후, 파일을 저장합니다.
    • 충돌 해결 후 스테이징:
      충돌을 해결한 후, 해당 파일을 스테이징해야 합니다.
      ```bash
bash
코드 복사
git add <충돌 해결된 파일>
```
    • 병합 완료:
      충돌이 해결되면 병합을 완료할 수 있습니다.
      ```bash
bash
코드 복사
git commit
```

git 이 사람과는 다르게 멍청하기 때문에 잘못된 코드를 자동으로 이게 맞다! 생각해서 병합해버릴 수가 있어요.

그래서 12345 가 맞았는데 갑자기 12745 로 짠! 하고 자동 병합이 되어버릴 수가 있죠.

이런 병합 오류를 막기 위해 우리는 자동 병합을 해주는 pull 을 잘 써줘야 해요.

git pull 은 git fetch 와 git merge 를 합친 친구에요!!

pull = fetch + merge

  • git fetch: 원격 저장소의 변경 사항을 로컬로 가져오는 작업.
  • git merge: 가져온 변경 사항을 현재 브랜치에 병합하는 작업.

을 나타냅니다.

그래서 보통 fetch 는 가지고 오고 병합은 안 하니까, 내 로컬에서 pr 내용 확인하고 싶을때 사용하곤 합니다.

merge는 단순히 병합만 해주는 거여서 다른 브랜치의 내용을 병합하는 과정을 해줘요!!

그러면 이거를 잘 활용해 봐야겠죠?

일단 우리한테는 모두에게 동일한 develop branch가 있어요.
(여기서는 코드 안 짜니까 우리가 건드리지 않음)

그럼 develop branch 에서는 아무리 pull 을 받아도 내가 작업한 내용이 없으니까, 공통된 부분에서 새로운 부분만 받아올 수 있겠죠??? (병합 오류 안 남!!)

자 그럼 나의 develop 브랜치를 최신화 했다 !!!

그러고 지금 현재 내가 작업하고 있는 branch 에 현재 내용을 반영하고 싶다면 뭐를 하면 될까요 ??

해당 하는 브랜치로 이동해서 git merge develop 을 하면 됩니다!!

그러면 병합 오류 나는 일 없이 확인하고 진행할 수 있겠죠. 계속해서 develop branch를 안전하게 지킬 수 있구요 !!

물론 git merge develop 했을때 충돌 나는 경우도 있습니다 !!

그거를 위에 적혀져 있는것 처럼 잘 해결하면 브랜치에 새로운 내용 최신화 할 수 있다 !!!

그래서 중간중간 develop 최신화 할때마다 팀원들에게 알려야 하고 (같은 파트 사람들)

팀원들은 devleop 최신화와 내 브랜치에 반영을 해주면 됩니다!

Github

아까 위에서 무슨 develop 에 반영?

새롭게 바뀐 origin 내용 ? 이런 이야기를 했는데,

도대체 우리는 그저 로컬에서만 작업을 해주고 있는데 어떻게 origin 의 develop 이 새롭게 반영되냐 !

할 수 있겠죠.

그건 바로 pr 을 날리고 develop branch로 merge를 했기에 가능했을 것입니다 !!

일단 main은 최대한 안 건드리기 위해 저는 무조건 develop 에서만 pr을 날리는 편이구요!

그러면 계속해서 기능을 만들고 올리는 곳이 develop 이 되겠죠 !!

그걸 어떻게 하냐! 를 설명 드릴게요.

issue, pr,milestone 등등

PR(Pull Request)

깃허브에 딱 들어가면 되게 다양한 탭이 보여요. 그 중에서 가장 먼저 pr을 설명 드리겠습니다!

pr은 우리가 우리의 로컬 브랜치를 git push origin “브랜치명”을 하자마자 만들 수 있어요.

pull request 의 약자 인데요 !!

기존 브랜치에 내용이 새롭게 업데이트 되었는데, 다른 브랜치로의 병합 요청을 할 수 있도록 알람이 뜨는 겁니다 ! (안 뜰때도 있는데 그럴땐 그냥 new pull request 라는 초록색 버튼을 누르면 돼요!)

그러면 어떤 markdown 형식의 글을 쓸 수 있는 공간이 나타나고 그 밑에 스크롤을 내려보면 회색 작은 글씨로 내가 날렸던 commit 들이 시간에 맞춰서 보여져요!!

markdown을 입력하는 곳은 다른 팀원들에게 내가 어떤 내용을 작업했는지 알려주는 공간이구요!

어떤 브랜치에서 어떤 브랜치로 병합하고 싶은지도 위에 항목을 선택할 수 있어요!!

(이건 직접 보여주기)

pr 도 정말 중요한데요 !!

코드 작업 량이 많아지고 지속적으로 오프라인 소통 할 수 없을때 내가 작업한 내용에서 어떤 내용이 담겨 있는지, review 로 어떤 부분을 같이 체크 해줬으면 좋겠는지 등등을 써 놓을 수 있답니다.

저는 pr을 얼마나 잘 쓰냐. 그리고 review를 얼마나 꼼꼼하고 예쁘게 달아주냐를 협업 시에 굉장히 중요시 여겨요. 실제로 그게 협업의 퀄리티를 올려주고 협업 능력을 길러주죠.

주로 pr 작성 시 템플릿을 만들어서 사용하는데 이거는 시간이 없어서 넘어갈게요 ! 혼자서도 구글링해서 다 해볼 수 있음~

그래서 pr을 만들게 되면 병합을 하기 전에 사람들이 확인할 수 있고 수정할 부분을 함께 볼 수 있어요. 그런 후 더블 체크를 하고 develop 에 병합을 시키는거에요 !!

Issue

이슈가 뭐지~? 당근의 어떤 한 팀에서는 이거를 티켓이라고 부르기도 하는데요!

💡
GitHub, GitLab 등과 같은 버전 관리 플랫폼에서 프로젝트 관련 논의나 작업 항목을 추적하기 위한 도구입니다. 이슈 트래커(issue tracker)라고도 불리며, 프로젝트 관리와 협업에서 중요한 역할을 합니다. 이슈는 버그 보고, 새로운 기능 요청, 작업 할당, 질문 등 여러 목적을 위해 사용될 수 있습니다.

이슈는 다양한 목적을 가져요.

  • 이슈의 주요 목적

    이슈의 주요 목적:

    1. 버그 추적:
      • 프로젝트에서 발생한 버그를 보고하고, 이를 해결하기 위한 토론과 작업을 진행합니다.
    2. 기능 요청:
      • 새로운 기능이나 개선사항을 제안하고, 아이디어를 논의하고 구체화하는 데 사용됩니다.
    3. 작업 할당:
      • 팀원들에게 작업을 할당하고, 작업 진행 상태를 추적하는 데 사용됩니다. 작업을 완료하면 이슈를 닫을 수 있습니다.
    4. 질문 및 논의:
      • 프로젝트와 관련된 질문이나 논의를 위한 공간을 제공합니다. 이를 통해 프로젝트의 중요한 사항을 기록할 수 있습니다.
    5. 문서화:
      • 프로젝트에서 중요한 이슈나 결정 사항을 문서화하여 프로젝트의 상태와 계획을 쉽게 파악할 수 있도록 합니다.

이를 어떻게 활용할지도 컨벤션으로 정해보면 되는데

저는 주로 이거를 작업을 나누고 브랜치명에 참고하여 쓰곤 합니다 ! 토스나 당근에서도 이런 형식으로 사용하는것으로 알고 있어요 !! 물론 팀바팀이겠지만 ~

(직접 보여주기)

이외에 다른것들도 정말 다양하게 쓰이는데요 ! 스프린트를 결정하는 milestone 다양한 cd 확인을 위한 actions 문서화를 위한 wiki 칸반보드 대용을 해주는 기능 등 정말 많은 기능을 깃허브내에서 내포하고 있습니다!!

다 알려주고 싶지만, 시간이 없어서..

어려운 부분은 없고, 찾아보면 나오니! 한번씩 꼭 써보세요! 분명히 필요한 기능들이 있을겁니다.

(나중에~)

협업 시 git 사용 과정

실습과 함께 진행 ! 직접 해보는 시간

Q1. branch 를 만들고 자유롭게 이동하고 싶다.
(단, main 밑에 develop. develop 밑에 feat/#1-practice 브랜치 만들어보기!)

Q2. 작업을 마치고 내용을 커밋하고 싶다.

Q3. 작업을 마치고 내용을 커밋하고, 원격저장소에 올리고 싶다.

Q4. 팀원이 올려둔 코드 내용을 받아 오고 싶다.

Q5. 받아온 코드 내용을 내 branch에 합치고 싶다.

Q6. 내가 작업한 내용을 develop 에 반영하고 싶다 !

관련 extension

git graph

git history

이제는 익숙해진 git! 혹시 빼먹은 부분이 있으려나~?? QnA

깃헙의 매력~

깃은 굉장해 ~

profile
Wang Hoeun
성장하고있는 프론트앤드 개발자 입니다!
이전 포스트

[초심자를 위한] 배포 플랫폼 (프론트 Vercel)

2개의 댓글

comment-user-thumbnail
차한음
2025년 8월 10일

자세한 Git 정리 감사드립니다!

1개의 답글