git, github 공부

음. 시작.

와우... 연말에 시작한다 .. 내년에는 ㄹㅇ git 쓸 것 같아

코딩애플님의 git&github 강좌를 보고 쓴 글입니답!

https://codingapple.com/course/git-and-github/

(무료) 매우쉽게 알려주는 git & github

Next.js는 프론트엔드부터 서버까지 만들 수 있는 React기반 프레임워크입니다. 이것만 사용해도 풀스택 웹개발이 가능합니다. Next.js 사용시 서버사이드 렌더링이 쉽기 때문에 React, Vue만 사

codingapple.com

2025.12.16.TUE

그래서 git 왜 쓸까?

: 안정적인 개발을 위하여...

ㅇㄴ 이메일 저걸로 좀 공식(?)적인 자리에서 쓰고 있는데 ... e가 넘 많아서 .. 하 .. 3개만 할 걸 쩝... 어쩌겠누?

git add 파일명, git commit -m '메모' 해서 기록 완료

기록한다 == 버전 관리한다... 뭐 그렇대..

(작업 폴더) --git add--> (staging area) --git commit--> (repository)

ㅇ ㅏ .. 잠깐.. 왜 나 브런치인지뭔지가 master인거지...? (이건 살짝 포인터 개념으로 들어가면 이해할 수 있을 듯...)

주소(커밋)는 그대로고 그 주소를 가리키는 “포인터 변수 이름”만 master → main으로 바뀐 거다.

git log --all --oneline로 내가 기록남긴 것들 볼 수 있다

오늘은~ 여기까지 ... 에휴..

대신 백준 풀러 가겠습니당 그 전에 게임 한판만 하고 ;;

git status로 상태를 확인해보니 ... 현재 branch가 love라고 하네요

git add . 로 제가 만든 love.txt를 바꿔준 후, 커밋해주엇습니당~

👉 git연습합니당 커밋은 love 브랜치의 ‘복사본’이 아니라, love와 main이 공유하는 시작점(공통 조상) 이다.

👉 “지금 커밋을 가리키는 이름표를 하나 더 붙인다”

👉 파일은 브랜치 소속이 아니다. 오직 “커밋이 어느 브랜치에서 만들어졌는가”만 중요하다.

라고 합니다....

👉 Git은 “이 파일이 어디서 왔는지”를 묻지 않고 “이 커밋이 어느 브랜치에서 만들어졌는지”만 본다.

이게 중요하네용... 그래서 늘 뭔가 git add . 하기 전에 git status로 내가 현재 어느 브랜치 위에 서있는가를 확인해야 합니당...(아마도...??) 걍 빨강불뜨면 그 파일은 닫는 게 ... ㅎ

git log --all --oneline --graph로 시각적으로 branch 이동 볼 수 있다

이야 이거 보기 좋네요... 이건 사랑이 아니었음을...

자자 그럼 이제 love를 main으로 머지(이게머지..? ㅎ ) 해주는 방법을 알아볼까요??? ㄱ

결국은 branch 하나 더 파는 이유도 기존에 쓰던 main은 건드리고 싶지 않은데... 그래도 필요하긴 해서 그런거자나여..아닌가;;??

근데...

똑같은 파일에 똑같은 줄을 수정한 걸 merge하려고 하면 충돌 발생!!!!!!!!!!!!

👉 Git은 “같은 기준 커밋에서, 같은 줄을, 서로 다르게 바꾼 경우” 어느 쪽이 정답인지 판단할 수 없어서 merge conflict를 낸다.

아.. 참고로

“Git 하다가 이상한 글쓰기 화면 나오면 Esc 누르고 :wq”

ㅎㅎ..꼼수만 느는 .;;;

음 그래서 branch파서 각각 작업하고 merge해주는 거래요. 와! 너무너무 똑똑한 것 같애여.

오늘은 ~~ 여기까지 .

파일 3개 만들고 커밋도 3개 했음 거기서...또 다른 커밋을 한 걸 전 커밋상태로 돌리고 싶어서 git restore a를 해보았지만 ....

ㅇ ㅏ ... 커밋까지 된 상태는 못 되돌린다네여 ...

git restore 파일명 -> 얘는 add도 하기 전에 스테이징하기도 전에 그 상태에서만 작동하네여 ...

(그니깐 컨트롤 z 안될 때 쓰면 좋을 듯.ㅋ)

와 중요한 건... 순서인듯해욥... 그

(작업 폴더) --git add--> (staging area) --git commit--> (repository)

으악...

그럼 결국은 바로 전 으로 정말 가주는 게 restore인 것 같네용.

따지고 본다면, add를 했다는 건 스테이징단계까지 간거니깐. ..

git revert 커밋아이디로 그 커밋을 삭제하지는 않지만 그 커밋을 적용하진 않는 커밋을 새로 하나 만듭니당

와 참 안전한 방법이네요 .... ㅎ ..

자 이젠 github 로 가볼까욥!!

벌써 2025년도 끝이 보이네요

내 21살 안녕 ...

22살 어서오고 ~

github도 어서오렴. ㅎㅎ

저의 2025년은 ㅎㅎ 좋았어요

자 다시 github !!

사실 숨김파일 보기하면 .git이라는 폴더가 있다(얘가 바로 repository)

우선 git에 대해 다시 복습하자면, 얘는 파일버전 기록해주는 프로그램이다. 그리고 git이 파일 기록해두는 장소를 repository라고 한다.

그러나 이걸 로컬 히스토리에다가 저장해뒀을 때 만약 내 컴퓨터가 고장난다면 ... ????

(사실 난 뭐 없어서 상관없긴함)

하지만...그럼 안돼.

그래서 온라인 repository(==원격저장소)를 만들어서 사용한다!

온라인 repository(==원격저장소)가 있으면 컴퓨가 고장나도 ㄱㅊ을거고, 협업할 때도 개꿀일 것이다.

github.com은 기본브랜치 이름을 main으로 강요해서 밑에 git branch -M main 명령어도 써줍니당.

자 이제 원격저장소로 업로드하려면,

git push -u 원격저장소주소 올릴로컬브랜치명

사실 더 간단한 방법이 있습니다.

git push 할 때 -u 라는 말이 주소를 기억하라는 뜻이거든요??

그래서 한 번 -u썼으면 git push까지만 해도 ㅇㅋ입니당.

git push만으로 main에서 했던 'b추가완료' 커밋을 push해줬어욥

자 그럼 이제 협업을 하기 위해선 어떻게 해야할까요??

아무래도 소스 코드를 가지고 있어야겠죠!

(소스 코드(Source Code)는 컴퓨터 프로그램의 동작을 정의하는 사람이 읽을 수 있는 프로그래밍 언어(C, Java, Python 등)로 작성된 명령어들의 집합)

그러기 위해선, 원격저장소에서 가지고 와야겠죠~

git clone 원격저장소주소 를 터미널에서 입력하면, 거기있던 코드들이 전부 다운받아집니다!

자 그럼 이렇게 팀원도 막 코드를 짜겠죠! 그리고 git push를 나중에 해서 올릴 겁니다. 하지만 그러기 위해서는 조건이 있습니다!

1. 팀원도 깃허브 아이디를 가져야 한다.

2. setting에서 collaborators에 그 팀원 아이디를 추가해야 한다.

원격저장소에 변동이 생긴 상태에서 git push를 하면 에러메시지가 뜬다.

이럴 때는 git pull 명령어를 사용해준다. git pull은 원격저장소에 있던 내용을 로컬저장소에 합쳐주는 명령어다.

사실 'git pull 원격저장소주소 브랜치명' <-이게 맞긴한데, 저흰 이미 -u로 원격저장소주소 저장해뒀죠! 아니면 remote로 바꿨던 origin이라고 써도 됩니당. 그리고 브랜치명을 입력해서 특정 브랜치만 가져오는 것도 할 수 있어요. ! 그러니깐 git status로 내가 지금 있는 브랜치명을 확실히 해둬야겠죠!!

그리고 사실은....

git pull은 git fetch + git merge 합쳐진 명령어입니답! git fetch는 원격저장소의 신규 커밋을 임시저장소에 저장해달라는 거고, git merge는 그 브랜치를 내 브랜치에 merge 해달라는 뜻입니다~ 그리고 merge에서 충돌 발생할 수도 있는데 뭐 같은 줄 변경했거나 그럼 좀 곤란한거죠... !!