GitLab 버전 관리와 협업 하면서 막혔던 부분 기록 일지

fork로 복사를 끌어와 나중에 MR로 original에 집어넣는다.

git reset에서 option선택

• git config user.name / git config user.email : 이름과 이메일 설정
• git diff {commit_id} {commit_id} : commit차이 알려줌
• git reset --{option} {commit_id} : 가리키는 HEAD를 바꿈 즉, working directory가 바뀜(hard여서 바뀜)
  • --soft는 워킹 디렉터리가 잘 반영되어있어서, 바로 commit해도 된다. 또는 고치고 add, commit해도 된다. 
  • --mixed를 하면 코드를 수정하고 git add, commit을 해야 한다.

[커밋 보기]

• git reflog : HEAD가 가리켰던 commit 목록을 보여줌
• git log --all --graph : 그래프 모양으로 보여줌
• git log --all --graph --oneline : 상세정보 생략되어 간결하게 볼 수 있음

[브랜치]

• git checkout {branch_name} : 브랜치 선택하기
• git checkout {commit_id} : HEAD가 직접적으로 해당 커밋 가리킴 
  • Detached 상태 - 브랜치로부터 분리되어 있는 상태
• git branch -r : 원격 브랜치 목록보기
• git branch {branch_name} : branch 만들기
  • branch를 처음 만들고 push 할 땐, git push --set-upstream origin {branch_name} : 안내문구 뜰 거임!
• git rm --cached {file_name} : git ignore 하기 전에 이미 commit 했으면 지워야 함.

Merge 정책

• Merge Commit : 모든 commit들을 log에 남긴다. 어떤 상황이든 새로운 커밋을 만들면서 머지한다.
• Merge Commit with semi-linear history : Merge Request 보냈을 때, Fast-forward Merge가 가능할 때만 Merge허용
  • 항상 새로운 Commit 생성되며 Merge, 
  • 매번 rebase작업을 해줘야 머지 가능
• Fast-forward : 새로운 커밋이 안 생기고 기존 머지에 쭉 당겨짐, 실제 fast-forward가 가능할 때만 Merge

Merge Commit vs. Merge Commit with semi-linear history

 

원본 프로젝트에서 머지된 것들을 포함하여 가져오기[원본-upstream/ 복제본(내꺼)-origin]

• git remote add {URL을 가리킬 이름} {URL} ex) git remote add upstream 원본 URL
• git pull upstream {branch_name} ex) git pull upstream develop // 원본의 신규 커밋들을 모두 가져옴
• git merge upstream/develop : Fast-Forward

로컬도 최신화 성공!

 

[Rebase] : FastForward Merge가 안될 때, 사용

rebase가 필요한 시점(Fast-Forward가 안될 때)

빨간 박스와 초록 박스(develop이후 갈라진 두 커밋들) 현재 develop브랜치 이후에 커밋을 부치려고 함.

• git rebase develop
• 코드라인에 수정해야 할 부분들이 나오고 자신이 원하는 방향으로 수정하면 됨.
• 수정후 git add -> git rebase --continue -> (최종 커밋을 넘길 수 있는 창이 등장) <그대로 저장>

fast-forward 가능상태로 변경 성공

두 커밋이 분기가 갈라지지 않고, 하나의 흐름으로 이루어져 있어서 Fast-forward Merge 가능!

• git push -> 에러 발생 : 컴퓨터의 feature-B 브랜치는 rebase가 된 상태인데, Gitlab의 복제본 프로젝트의 feature-B 브랜치는 그렇지 않은 상태이기 때문이다.
• git push --force : 복제한 내 프로젝트이기 때문에 사용해도 괜찮다.
• 이후, Gitlab에 들어가서 MergeRequest를 보내주면 된다! 
• 다시 터미널로 접속해서 -> git pull upstream develop
• 이제 내 컴퓨터의 feature-B 브랜치와 원본 프로젝트의 develop브랜치가 같아진 상태가 된다. 따라서
• 내 컴퓨터의 develop 브랜치도 동기화해준다.
• git checkout develop -> git merge upstream/develop
• 복제했던 프로젝트(Gitlab에 있는 프로젝트의 develop브랜치 동기화) : git push origin develop

---

git ignore 적용

문법

# : comments

# no .a files
*.a

# but do track lib.a, even though you're ignoring .a files above
!lib.a

# only ignore the TODO file in the current directory, not subdir/TODO
/TODO

# ignore all files in the build/ directory
build/

# ignore doc/notes.txt, but not doc/server/arch.txt
doc/*.txt

# ignore all .pdf files in the doc/ directory
doc/**/*.pdf

• git rm -r --cached . //파일 생성 후, 이미 한번 ignore적용을 안했다면 cached {파일이름}해야 적용이 된다.
• git add .
• git commit -m ""

---

깃 기록 삭제하고 다시 저장

• rm -rf .git
• git init
• git remote add origin

---

머지 충돌 해결

1. git stash 로 작업중이던 파일들 저장해둔다.
2. 작업중인 브랜치로 들어가서 git pull origin ${리모트브랜치명}
3. 업데이트 된것을 확인하고 git stash pop 으로 가져온다. (git stash list로 확인 가능)
4. 적용후 git add . git commit -m " 메시지" 를 한다. (non-fastforward)
5. git pull (git pull origin ${현재 작업중인 브랜치})
6. git push (git push origin ${현재 작업중인 브랜치})

**추가**

[도커]

• docker파일은 배포할 때, 만들고, 그때, docker run {name}을 이용해서 실행한다.
• 도커를 연결하고 설정 후 실행하려면, docker-compose up -d 하면 로컬 DB가 만들어진다.(compose도 설치)
• 그리고 docker-compose.yml파일을 만들어놔야 한다.

만약 잘못 커밋하고 원격저장소에 push까지 해버린 상태라면..(이런 끔찍한 일을 저질러버렸다..)

• 나는 git reset으로 이전 상태로 돌아간 후, 수정을 하고 -> git add .
• git commit --amend -m "수정할 메시지"
• git push -f (origin) {branch이름} 
• 이렇게 하면 깔끔하게 수정이 된다.

---

Squash and merge

• Squash는 여러 개의 커밋을 하나로 합치는 기능
• 머지할 브랜치의 커밋을 전부 하나의 커밋으로 합친 뒤 타겟 브랜치에 커밋하는 방식으로 머지를 진행
• 실질적인 머지로 인해서 생성된 머지 커밋이라기보다는 그냥 다른 브랜치의 변경 사항을 하나로 뭉쳐놓은 커밋

장점

1. 일단 머지 커밋이 남긴 하기 때문에 머지가 되었다는 사실을 히스토리 상에서 한 번에 알아볼 수 있다.
2. 버전 별로 어떤 것이 변경 되었는지 한 눈에 알수 있다.
3. 머지된 브랜치의 자잘한 커밋 사항이 남지 않기 때문에 머지가 되었다라는 사실 자체에만 집중한 기록이 남게

단점

1. 일반 머지는 해당 브랜치에서 누가 어떤 커밋을 통해 어떤 라인을 수정 했는지 까지 알려주지만                  Squash and merge 전략은 머지 대상 브랜치의 모든 커밋을 하나로 통합해버리기 때문에 그 정도의 자세한 정보는 알 수가 없다