IT

[코딩온] 신재생에너지 IoT 개발자 입문 251107 회고

혈중당부족 2025. 11. 11. 17:53

 

 

주 2회 업로드를 하고자 노력 중, 기록한 걸 다듬어서 글을 써보기로 한다.

 

명령어

git push –force

Remote Repo. (원격 저장소)에 커밋 지점이 없다면 바로 업로드 가능하다.

원리상 Readme.md 파일 있거나, 다른 커밋내역 있으면 공통된 커밋 지점이 없어 업로드 불가능한데 이를 강제로 덮어쓰기 하는 기능이다.

- 메인 브랜치 <1> 작업물을 두 사람이 할 때, A <2>로 하고 B <3> 해서, B가 <1> <3>으로 변경 업로드 하면 A가 한 <2>가 업로드 안 될 수 있다. 그래서 형식적으로 '메인 브랜치에 변경사항 있으니 pull 받아주세요' 해서 받고 변경한 작업을 push한다.

  ex) A B의 작업물 <3>을 먼저 pull(다운로드) 하고 <2> 작업물 업로드 함.

 

그 후에 받은 실습 문제.
작업 과정에서 제대로 됐는지 확인하는 명령어를 자주 쓰다보니 작업 속도가 빠르지 않다. 확신이 없나보다...

3번 과정은 이전에 배웠던 원격 저장소 연결.

Init 명령어로 변환하고 나서. Remote add origin + 연결 레포리지해서 연동시킨다.

명령어 git remote add origin <연결하려는 remote repo url>.git 

 

 

위에 설명대로 오류가 나고, 힌트 목록에도 git pull 하라고 알려준다. 

 git pull origin main 으로 원격저장소에서 pull(가져오기) 했는데 폴더 안에 내려 받은 파일이 없다. 커밋 내역까지 날려서 이전 작업물로 복구 못한다. (중요)

 

상태 확인해도 문제없음이라 나와 fetch origin main 명령어 사용해 재시도. 이래도 변경된 게 없다.

 

 

방금 전에 배운 명령어로 덮어 씌우자, github에 연결했던 Repo가 새로운 걸로 바뀌었다. (조심히 사용하자.)

만약에 로컬(노트북)에 이전 작업물이 있다면, 다시 push해 올려두면 된다.

 

사용하고 내가 이해한 대로 작성한 명령어. 

1. Git pull origin main(브랜치)

Remote repo의 변경사항을 local repo로 가져오는 것

Fetch + merge 라는 명령어 두 개 동시 실행

Merge: 병합.

2. Git fetch origin main

Fetch: remote 변경 사항 가져온다 (local 파일에 변경사항이 반영만 되고, commit 안됨. – 커밋 메시지를 안 가져와서 수정내역 유추가 어려움.

 

 

이제 6번인 github에서 파일 추가해본다. 

patch와 pull 수행

 

Fetch는 트래킹이 안되지만 기록을는 잘 남아있다.

 

왜 이런 경우가 생기는가?

A 로컬에 작업한 걸 올렸는데 B로컬로 가서 다른 형태로 작업한 걸 같은 레포(원격저장소)에 올리려고 하자 시점이 다르다고 충돌나는 거다. 그래서 A로컬에서 작업해둔 걸 pull로 내려받고 만지는 게 별 탈 없다. (과거 내역도 남는다.)

 

 

이렇게 git 사용하고 명령어 입력하면서 자주 쓰는 '브랜치' 에 관해 수업 들어간다.

자료 이미지.

Git 에서 사용하는 브랜치는 기존 코드에서 나온 독립적인 작업공간. (타인이 접근해서 볼 수도 있다.) 그래서 여러 개 브랜치가 생기다보니 merge(병합)을 항상 해야함.

 개발자가 개발, 테스트, 수정 목적으로 기존 코드를 변형 작업할 수 있고, git으로 배포된 메인 코드에 오류 생기지 않도록 보호. 여러명이 협업 가능하면서 각 브랜치 작업 이력 관리 가능해 추적 할 수 있다.

 작업 시, 협업 중이면 pull로 받아서 최신 버전 갱신하고, 수정사항 확인하며 일해야 한다.

 

- 분기가 나눠지는 시점은

A 브랜치로 일직선 통행 ---- (1) ----- (2) ---

  A 브랜치 작업물(1) 받아서 test 브랜치로 만듬.

  A 브랜치에서 작업물 (2) 받아서 hello 브랜치 만듬.

 이럴 때 (2) 기반으로 만든 hello 브랜치 작업물은 (1) 소유자가 없고. (2)소유자가 (1)-이전 작업물-와 같이 갖고 있는 셈이 된다.

 Test 브랜치 만든 소유자가 world 브랜치 만들면 작업물(2) 없는 채로 또 확장 됨.

 

지금은 파악하기 쉽게 비주얼 스튜디오 프로그램을 쓸 생각이다.

터미널 창 열기로 :ctrl + ' 랬는데 왜 안 열리지. 다시 물어봐야 겠다.

 

명령어 목록

git branch: 현재 브랜치 위치.

 

git branch 브랜치명 : 브랜치 생성, (브랜치는 한번에 하나씩)

ex) git branch test

 

git switch / git checkout 브랜치명 : 해당 브랜치로 위치 이동

ex) git checkout test : 테스트라는 브랜치로 이동

 

git switch –c 브랜치명 / git checkout -b 브랜치명 : 브랜치명 만들고 이동시켜줘 명령어.

> 그 전에 브랜치 위치 보고 pull로 다운 받아서 해야한다.

git branch (로컬만)

git branch –a (로컬, 원격 둘다), all 약자

git branch –r (원격만), remote 약자

 

작업 다 하면 브랜치를 정리하기도 한다.

git branch –d 브랜치명(여러 브랜치명 가능) : 브랜치 삭제.

-d: del 약자. 작업 중이거나 병합하지 않은 경우 삭제 안 됨

git branch –D 브랜치명 : 강제 삭제 (대문자 확인

 

위 쪽 명령어들은 로컬 공간으로 한정한다. 

 

git push origin –d 브랜치명(여러 브랜치명 가능), 원격 저장소

: git(원격저장소)에 지워지게 올려줘.

 

 

branch 확인하고 test로 만들면 main 바탕으로 만들어진 test branch가 생긴다.

녹색으로 표시된 건 현재 내가 있는 위치

 

브랜치 이동 명령어 쓰고 이동 됐음을 확인.

 

Main 기반하는 브랜치 하나 더 만든다면 main 브랜치로 이동해서, hello를 생성해야 main 파생 test/hello가 생긴다.

 

현 위치를 기준으로 삭제를 하면 (띄어쓰기로 파일 구분한다.)

 

Main이 남는다.

 

git switch –c 브랜치명 적용

 

 

 

배웠던 걸 토대로, Dream 브랜치 만들어 이동한 후, 해당 브랜치에서 파일 생성해 add commit push 과정을 거쳐 원격저장소에 올리기로 했다. 

Repo로 확인하니 정말로 됐다.

 

Log에서, HEAD 표시는 이게 최신 버전이라는 뜻이다.

 

그런데 원격저장소에서 내역을 확인하면

가리키는 최신이 main 브랜치에서 만든 작업물이다. Bream에서 한 작업물은 업로드 됐음에도 말이다. 로컬, 원격의 HEAD가 다르단 뜻

 

이제 브랜치 관련 실습 하고자 한다.

0. main 브랜치에서 research_ recruitment.txt 파일 생성 후 remote push 

- add commit push 과정 거쳐서 원격저장소에 올라가진다.

1 main 브랜치 바탕으로 3개 브랜치 만들기

브랜치명: research/recruitment_1 ~ recruitment_3

2 브랜치 별 취업 희망하는 직무 채용공고 1개씩 조사해서 remote push 하기

포함 내용: 채용공고명, 채용공고 링크, 담당업무, 지원자격, 우대사항

채용공고 1개 조사 완료하면 해당 브랜치에 push하고, 다른 브랜치로 이동해서 작업한다.

3 research_ recruitment.txt 에서 ‘1번째 채용공고 조사작성하고 add commit push 하고 다른 브랜치로 이동해서 무한히 반복.

 

영어를 써가며 작업하니 뜻이 자꾸 헷갈려서 메모...

Remote:원격 (원격 저장소 약칭. = github)

 

추가로 다른 브랜치에서 작업하던 중에 main 브랜치가 변경되면 git pull origin main(브랜치명)을 입력해 가져와서 반영해 작업 이어갈 수 있다. Push(올리기)만 안된다.

 

main 브랜치에서 research_ recruitment.txt 파일 생성 후 remote push 과정을 끝냈다.

 

 

명령어 잘못 입력하고 그랬는데 실수한 부분은

1 Switch -c 생성 후 이동을 복수로 해서 에러남

2 Branch 생성은 하나씩 (_3브랜치 만들 수 없다고 에러났음)

 

 

텍스트 내용 채우고 github에 push 하는 중. 

 

 

브랜치가 변경되니 텍스트 파일이 달라 비워져있는 걸 볼 수 있다.
그렇게 무사히 실습을 진행했다.

 

 

git merge는 먼저 병합하기 위해 mian 브랜치 가서 (기준) 명령어 git switch 또는 git checkout

git merge dream(합쳐질 브랜치)를 입력해봤다.

 

처음 합칠 때 이렇게 터미널이 나온다.

 이걸 :q (쉬프트+;+q) 누르면

병합 됐다. add , commit 이 처리 됐기에  'git push origin 기준 브랜치명' 으로 업로드. 

어느 브랜치에서 작업했는지의 commit – m 다 보이고 기록도 남는다.

 

 

병합 다 했으니 dream 브랜치 지우고 확인하고 나서 remote에도 push 하자

원격저장소에 브랜치가 남아있어 ' 브랜치 지우고 올려줘 명령어'로 지운다.

 

자료 설명은 이러하다.

 

그 사이 배운 3-way merge란? 

베이스에서 여러 커밋을 작업하다 병합하면 베이스를 기준으로 전부 통합시켜버린다.

 

내가 이해한 건 두 브랜치에서 각각 한 커밋을, 바탕되는 커밋에 합치니 새로 만들어진다 형식 같다.

 

이 다음 한 실습은 이랬다.

 

강아지 브랜치에서 한 작업을 완료하고

 

 

 

 

dog 브랜치 병합 업로드 하고 cat도 이와 같이 하면

 

 

 

txt 파일의 내용이 충돌나서 이러한 형식이 된다 HEAD는 현재 최신 상태가 이거라는 뜻이다. 

 

 

이렇게 해도 오류가 나길래 정확히 파악하고자 VS code를 열어보기로 했다. 

 

 

오류가 아닌 충돌이라서, 자동 병합이 되지 않는 것이므로 직접 수정해줘야 한다. 그게, txt는 비주얼 코드가 따로 해주지 않기 때문에 메모장에 가서 고치는 거다. 

 

명렁어 입력하면 터미널에서 안내를 해주는데

Fast-forward 는 붙어서 연결됐다는 뜻이다. (자동 병합 됨)
충돌 안내도 잘 뜬다.
VS code 에서의 병합 UI 형식

수정 후 상태를 보니 add도 잘 적용되어 있다. 그렇게 commit - push 과정을 무사히 거쳤다. 

 

 

순서대로 로컬, 원격 저장소의 브랜치를 지웠다. 브랜치 관리에 대한 실습을 무사히 했다.

 

브랜치 명칭을 지을 때, 회사 업무에서 혼란을 줄이고, 목적을 명확하게 하기 위해 이름 규칙을 정한다는 얘기를 들었다. 

1 일반적으로 많이 사용하는 규칙이 있으나 회사/팀마다 다를 수 있다

2 main브랜치에서는 직접 작업하거나 커밋하지 않고 병합만 수행

3 너무 길거나 복잡한 이름은 피하고 소문자 사용, 공백은 -로 대체

4 팀 내 브랜치 명명 컨벤션이 있다면 반드시 그 규칙에 따름

자료 보는데 하나의 작업만 하라는 거 같다. 명칭대로 작업해서 관리하기 편하도록. 그래서 대게 한 브랜치가 3일 이상 가는 일이 적은 모양이다.

 

마지막으로 종종 프로그램 뒤에 붙어있는 버전 형식을 알게 됐다. 이것으로 회고 작성을 끝낸다.

 

명칭이 길어 약칭을 사용하는 건 아는데 remote가 헷갈린다거나, 연결 문제거나 이런 저런... 헤맸다. 방법을 알아도 알아듣지 못하면 하기 어렵다는 걸 실감 했다.