팀 프로젝트 깃 브랜치 연결, 작업물 pull&push
깃허브에서 개인브랜치 생성하기
로컬작업공간(노트북, 컴퓨터)에서 깃허브 레퍼지토리 세팅하기
프로젝트 작업공간으로 새로운 폴더 생성하기.
해당 작업공간 폴더에 들어와 깃 배시 열기
git init
Git 초기화
깃 시작 명령어
git clone https://github.com/username/repository.git
깃허브에 만들어진 폴더 그자체와 브랜치들이 다 들어온다.
개인브랜치 생성같은 작업을 할 필요가 없다.
혹은 세부적으로 작업해주고 싶다면... 하단의 remote~~ 부터 명령어들을 적어주면 된다.
((
$ git remote add origin https://github.com/username/repository.git
원격 저장소 추가
레퍼지토리 주소 연결
우리 팀 프로젝트의 단계별 깃 브랜치들.
main(기본브랜치) - develop(중간브랜치) - 개개인들의브랜치들
git fetch origin
git checkout develop
git pull origin develop
- git fetch origin으로 원격 저장소의 최신 정보를 가져옵니다.
- git checkout develop으로 develop 브랜치로 전환합니다.
- git pull origin develop으로 원격 develop 브랜치의 최신 변경 사항을 로컬 develop 브랜치로 가져옵니다.
git checkout -b 개인브랜치명
내 로컬브랜치 생성 및 이동(왠만하면 원격, 깃허브의 내 브랜치명과 같게 만들자. 헷갈리지 않도록)
-b 플래그는 새 브랜치를 생성하고 체크아웃합니다. 개인브랜치를 생성하고 그 브랜치로 전환합니다. 이 시점에서 개인 브랜치는 develop 브랜치의 최신 상태를 기준으로 하고 있으며, develop 브랜치의 작업 내용이 개인브랜치로 복사되어 있습니다.
))
최신 작업물 가져와 이어작업하기. 작업전 pull
git branch
현 브랜치를 확인합니다.
깃배쉬를 켰을때 현 브랜치위치를 꼭 확인해주자. 엄한데에다 작업물올리면 큰일난다..
git pull origin 개인브랜치
하면 개인브랜치 작업물을 싹다 받아올 수 있다.
++ 빈 폴더면 깃에 올라오지 않는다. 해당 폴더를 반드시 업로드 하고싶다면, 별 내용없는 파일이라도 해당 폴더안에 넣어서 올리자.
git checkout develop
`develop` 브랜치로 전환
git fetch —all ( - 두개임)
상황 파악: fetch는 원격 저장소에서 변경된 내용을 로컬 저장소로 가져오기 때문에, 실제로 pull하기 전에 원격 저장소의 최신 상태를 확인할 수 있습니다.안전성: fetch는 로컬 작업 공간에 영향을 주지 않으므로, 현재 작업 중인 브랜치에 영향을 미치지 않고 원격 브랜치의 최신 상태를 확인할 수 있습니다.
git fetch --all 명령어를 추가하는 것이 필수적이진 않지만, 안전하고 정확한 동기화를 보장하는 데 도움이 됩니다. 만약 프로젝트의 상태를 더욱 신중하게 관리하고 싶다면, 이 명령어를 추가하는 것이 좋습니다. 특히 팀 프로젝트에서 여러 명이 동시에 작업하고 있는 경우, 예상치 못한 충돌이나 문제를 미리 방지할 수 있습니다.
하지만 단순히 최신 상태로 작업을 병합하려는 경우라면, git pull만으로도 충분할 수 있습니다. 따라서 상황에 따라 git fetch --all의 사용 여부를 결정하는 것이 좋습니다.
git diff 로컬개인브랜치명 origin/원격개인브랜치명
(같다면 문제가 없겠지만, 다르다면 어떤게 어떤 브랜치인지 구분해서 기입해야한)
원격 브랜치와 비교: 원격 브랜치와 로컬 브랜치의 차이를 확인하려면, 원격 브랜치의 최신 커밋을 로컬 브랜치와 비교합니다.
git pull origin develop
최신 상태로 업데이트
git checkout 개인브랜치명
개인 브랜치로 전환
작업후 푸쉬
텍스트파일 하나 만들어 올려보기vi abc.txt
(i 누르면, 깃배시에서 글씨를 쓸 수 있다. 다 쓰고 나면 esc, 왼쪽하단에 :wq적고 나온다)
git add .
변경된 파일 스테이징. 모든 변경 사항을 스테이징.
git status
파일 변경 상태 확인
git commit -m "커밋메세지"
변경 사항 커밋
git push origin 개인브랜치명
커밋한 변경 사항을 원격 저장소의 내브랜치에 푸시
물론이죠! 주어진 작업을 완료하기 위해 Git Bash에서 사용할 수 있는 명령어들을 단계별로 설명해드릴게요.
### 1. 원격 `develop-1`의 최신사항을 로컬 브랜치 `develop-1`에 내려받기
먼저, 원격 저장소의 변경 사항을 로컬에 반영합니다:
```bash
# 원격 저장소의 변경 사항을 가져옵니다
git fetch origin
# 로컬 브랜치 develop-1로 체크아웃합니다
git checkout develop-1
# 원격 브랜치 develop-1의 최신 변경 사항을 로컬 브랜치 develop-1에 병합합니다
git merge origin/develop-1
```
### 2. 로컬 브랜치 `scraping`의 내용을 `develop-1`에 반영하기
이제 `scraping` 브랜치에서 변경 사항을 `develop-1` 브랜치에 병합합니다:
```bash
# 로컬 브랜치 scraping으로 체크아웃합니다
git checkout scraping
# develop-1 브랜치의 변경 사항을 적용하기 위해 develop-1으로 다시 체크아웃합니다
git checkout develop-1
# 로컬 브랜치 scraping의 변경 사항을 develop-1에 병합합니다
git merge scraping
```
### 3. 로컬 `develop-1`을 원격 `develop-1`에 푸쉬하기
마지막으로, 로컬의 `develop-1` 브랜치를 원격 저장소에 푸쉬합니다:
```bash
# 로컬 브랜치 develop-1을 원격 저장소에 푸쉬합니다
git push origin develop-1
```
이 단계들을 차례로 실행하면 요구하는 작업을 완료할 수 있습니다. 각 단계는 문제없이 실행되도록 진행하면서 필요한 경우 충돌 해결을 수행해 주세요.
개인 브랜치에서만 작업하고, 직접적으로 develop 브랜치와 동기화하지 않는 상황에서도, 여전히 develop 브랜치와의 동기화는 중요할 수 있습니다. 그 이유와 방법을 설명할게요.
왜 develop과 동기화해야 할까요?
- 최신 변경 사항 반영: 팀원들이 develop 브랜치에서 작업하고 있기 때문에, 당신의 개인 브랜치가 develop 브랜치의 최신 변경 사항을 반영하지 않으면, 작업 중에 충돌이 발생할 수 있습니다.
- 통합 테스트: 개인 브랜치에서 작업을 완료한 후 develop 브랜치에 병합하기 전에, 최신 develop 브랜치의 변경 사항과의 통합 테스트가 필요할 수 있습니다. 이를 통해 충돌을 미리 예방하고, 코드가 잘 작동하는지 확인할 수 있습니다.
- 코드 리뷰 및 병합: 개인 브랜치의 작업을 develop 브랜치에 병합하기 전, 최신 상태로 유지된 develop 브랜치와 병합하여 충돌을 미리 해결하는 것이 좋습니다.
이렇게 함으로써 팀 프로젝트의 일관성을 유지하고, 원활한 통합 작업을 할 수 있습니다.
Q.
그럼 이제 A가 자신의 작업물을 push 후 develop에 merge 하려면 develop브랜치를 pull 해와야 하는거지??
A.
A가 자신의 작업물을 develop 브랜치에 병합하기 전에 develop 브랜치의 최신 상태를 로컬로 가져와야 합니다. 이는 git pull 명령을 통해 이루어지며, 이후 자신의 feature-A 브랜치에 병합하여 충돌을 확인하고 해결한 후, develop 브랜치로 병합해야 합니다.
A가 develop 브랜치를 pull 해올 때, A가 작업한 작업물들이 사라지지 않습니다. 대신, develop 브랜치의 변경사항들이 A의 로컬 저장소로 내려받아지고, A가 작업 중인 파일과 병합되는 과정이 발생합니다.
자세한 설명:
- 로컬 feature-A 브랜치에서 작업한 내용은 유지됩니다. A가 feature-A 브랜치에서 작업한 모든 내용은 그대로 남아 있습니다.
- develop 브랜치의 변경사항만 가져옵니다: git pull을 실행하면 원격 저장소에 있는 develop 브랜치의 최신 변경사항들이 로컬 develop 브랜치로 가져와집니다. 이때 변경된 파일이나 새로운 커밋만 가져오는 것이지, 로컬에서 A가 작업한 내용이 덮어쓰여지지 않습니다.
- 병합 시 변경사항만 적용: feature-A 브랜치로 다시 돌아와서 develop 브랜치의 변경사항을 병합(merge)할 때, develop 브랜치의 최신 변경사항과 A가 feature-A 브랜치에서 작업한 내용이 서로 비교됩니다. 변경된 부분만 병합되며, 동일한 부분에서 충돌이 발생할 수 있습니다.
- 충돌 해결: 만약 feature-A 브랜치에서 작업한 내용과 develop 브랜치의 최신 변경사항이 동일한 파일이나 코드 라인에 영향을 미치는 경우, 충돌이 발생할 수 있습니다. 이 경우 Git이 충돌을 해결하도록 요청하며, A가 수동으로 충돌을 해결한 후 커밋을 해야 합니다.
결론:
A가 develop 브랜치를 pull 해올 때 A의 작업물들은 사라지지 않고, develop 브랜치의 최신 변경사항들만 로컬에 내려받아집니다. 그리고 feature-A 브랜치에서의 A의 작업과 병합하는 과정에서 충돌이 발생할 수 있으며, 이를 해결한 후 병합을 완료할 수 있습니다.
우선 명령어 위주로 간략하게 글을 적었다. 명령어의 흐름이나 전체적인 이해가 필요하다면, 하단의 링크를 참고하자.
[GIT] ⚡️ 버전 관리하기 (git init / add / commit / log / diff)
Git 버젼 관리 시작 git init 깃 저장소를 초기화한다. 저장소나 디렉토리 안에서 이 명령을 실행하기 전까지는 그냥 일반 폴더이다. 이것을 입력한 후에야 추가적인 깃 명령어들을 줄 수 있다. # 버
inpa.tistory.com