개발 협업하기

우리는 왜 협업에 실패할까?

협업 과정은 프로젝트 규모가 작을 때는 문제없이 진행되는데, 규모가 커지게 되면 여러 문제들이 나오게 된다. 협업을 통해 문제를 잘 해결하면 다행이지만, 그렇지 못한다면 프로제그 참여자들의 생산성이 눈에 띄게 낮아지고, 프로젝트 성공 여부도 불투명해지게 된다.

협업 실패가 초래하는 문제점들

• 같은 업무를 하는데 더 많은 시간이 필요하다. 협업이 원활하게 이뤄지지 않는다면, 업무 조율에 상당한 시간과 노력이 필요하게 된다. 이러한 비효율들이 쌓이면, 전체 프로젝트 일정을 지연시키는 큰 문제가 될 수 있다.

• 잦은 협업 실패는 팀원 간의 소통 부재로 연결될 수 있다. 나아가 소소한 오해조차 커다란 문제로 번지게 되고, 팀원 간의 신뢰에 악영향을 줄 수 있다. 팀원 간의 깨어진 신뢰는 궁극적으로 프로젝트 실패로 이어질 수 있다.

• 중복 작업이 발생하거나, 필요 없는 일을 수행하게 될 가능성이 높아진다. 이런 비효율은 팀의 전반적인 생산성 저하로 이어질 수 있다.

협업에 실패하는 주된 원인들

• Git과 GitHub에 대한 이해 부족
  이 도구들은 현대 소프트웨어 개발에서 빠질 수 없는 요소이며, 이를 통해 소스 코드의 버전 관리와 협업 과정을 효율적으로 관리할 수 있다. 이 도구들을 제대로 사용하지 못하면 코드 충돌, 버그 발생, 브랜치 관리의 실패 등 많은 문제가 발생할 수 있다.

• 커뮤니케이션 스킬 부족
  GitHub의 Pull Request 기능, 코드 리뷰, 브랜치 관리 전략 등을 이용해 팀원들 간의 소통을 강화하는 것이 중요하다. 그렇지 않으면, 각자의 역할과 책임에 대한 이해가 부족해지고, 프로젝트의 효율성이 떨어지며, 결국 프로젝트의 성공을 보장할 수 없게 된다.

  ---

Git의 일반적인 사용 흐름

Git의 핵심 개념 정리

1. Git의 핵심 구조와 파일의 상태 변화

Git의 핵심 구조는 working directory, staging area, repository로 구성되어 있다. working directory에서는 실제 파일을 수정하며, 이 변경 사항을 다음 커밋에 반영하기 위해 Stage에 보관한다. git commit 명령어를 사용하면 staging area에 준비된 변경 사항이 repository로 디오하며, 새로운 버전이 생성된다. 파일 상태는 이 과정에서 Untracked, Modified, Staged, Unmodified 등으로 변화하게 된다.

Q) 파일의 상태가 'Untracked'에서 'Unmodified'가 될 때까지 거치는 단계를 순서대로 나열해 볼 수 있을까?

staging area에 파일을 추가하고 커밋하게 되면 'Untracaked' 상타에서 'Unmodified' 상태로 변하게 된다.

2. 커밋 (commit)

커밋은 작업 내용의 '스냅샷'을 의미하며, 한번 커밋하면 이력이 남는다. 이런 특성 때문에 문제가 발생했을 때 이전 상태로 쉽게 되돌릴 수 있다. 즉, 커밋은 Git에서 관리하는 가장 작은 단위의 버전이라고 할 수 있다.

Q) 커밋과 푸시에 차이점은 무엇인가?
커밋과 푸시는 다른 동작이다. 커밋은 local 저장소에서 변경 내역을 저장하는 동작이며, 푸시는 이 변경 내역을 remote 저장소에 업로드하는 동작이다.

3. 브랜치 (branch)
   브랜치는 독립적으로 작업을 진행하고 그 결과를 저장할 수 있는 개별적인 흐름을 의미한다. 브랜치를 사용하면, 서로 다른 작업을 별도로 진행하고 나중에 하나의 코드베이스로 병합할 수 있다.

Q) 브랜치를 버전이라고 할 수 있을까?
브랜치는 특정 커밋을 가리키는 참조(reference)로, 여러 개의 작업을 독립적으로 진행할 수 있다.

Git을 처음 접하는 사람들이 브랜치를 '버전'이나 '스냅샷'이라고 생각하는 이유는 브랜치가 특정 커밋을 가리키며, 그 커밋은 프로젝트의 특정 버전이나 상태를 '스냅샷'으로 저장하기 때문이다. 이런 의미로 어떤 면에서는 브랜치가 특정 '버전'을 가리킨다고 볼 수 있다.

하지만, 브랜치 자체가 '버전'이나 '스냅샷'이 아니라는 것이 중요하다. 즉, 브랜치는 단지 '스냅샷'인 커밋을 가리키는 참조일 뿐이다. 이 브랜치를 통해 우리는 서로 다른 커밋, 즉 서로 다른 '버전'이나 '스냅샷'을 쉽게 전환할 수 있다.

4. local 저장소와 remote 저장소

Git에서는 local 저장소와 remote 저장소라는 두 가지 저장소를 사용한다. local은 개인의 컴퓨터에 위치하며, remote는 인터넷상의 서버 등에 위치한다. local에서 작업을 진행한 뒤, remote에 푸시(push)하여 다른 사람과 협업하거나 백업을 생성할 수 있다.

Q) git push를 수행할 때 아래와 같은 오류를 본 적이 있을 것이다. 왜 발생한 것이고, 어떤 의미인가?

fatal: The current branch master has no upstream branch.
To push the current branch and set the remote as upstream, use
git push --upstream origin master

해당 오류는 현재 master 브랜치가 remote 저장소의 브랜치를 추적하고 있지 않을 때 발생한다. 즉, git push 명령어를 실행할 때 local master 브랜치가 어떤 remote 브랜치로 푸시해야 하는지 알 수 없기 때문이다.

git push를 사용하면 master 브랜치로 푸시하면서 remote 저장소의 origin에 있는 master 브랜치를 추적하도록 설정한다. 이 후부터는 git push 명령어를 실행할 때 remote 저장소의 origin/master로 자동으로 푸시된다.

---

일반적인 Git의 작업 흐름

웹 사이트를 만드는 프로젝트에 참여하고 있다고 가정해 보자. 새로운 기능인 "사용자 프로필 페이지"를 추가하려고 한다.
1. git pull : 먼저 remote 저장소에서 최신 코드를 받아온다. 이를 통해 현재 local 코드가 최신 상태인지 확인하고, 다른 사람이 진행한 작업을 local repository에 포함시킨다.
2. git checkout -b add_profile_page : 새로운 기능을 위한 브랜치를 생성한다. 이 브랜치는 "사용자 프로필 페이지"를 추가하는 작업을 포함하며, 브랜치 이름에 이 내용르 반영하는 것이 좋다.
3. git add -A : 새로운 프로필 페이지에 필요한 모든 파일과 변경 사항을 staging area에 추가한다. 이는 새로운 HTML, CSS, JavaScript 파일 등이 될 수 있다.
4. git commit -m "fead: add user profile page" : staging area에 있는 변경사항을 커밋하여, 작업 내용에 대한 스냅샷을 생성한다.
5. git push : 커밋한 변경 사항을 remote 저장소에 푸시한다. 이를 통해 다른 팀원들이 이 변경 사항을 볼 수 있다.

---

GitHub 훑어보기

1. 팀을 만들기 위한 기능 : Organization

Organization은 팀원들을 한데 모아 프로젝트아 저장소를 효율적으로 관리하는 팀 협업 도구이다. 이 기능은 주로 회사나 대규모 조직에서 권한 관리와 보안을 향상시키기 위해 사용된다.

이 기능을 활용하면 Front-end와 Back-end 등의 다양한 영역으로 나눠진 저장소를 한데 모아, 프로젝트 관리를 간소화할 수 있다. 이는 팀원들 간의 협업을 더욱 원활하게 하고, 프로젝트 통합 관리를 가능하게 한다.

또한, Organization 내에서는 Projects라는 기능을 이용할 수 있다. Projects는 할 일 목록 등을 관리하는 도구로, 이를 통해 프로젝트의 진행 상황을 시각화하고 작업의 우선순위를 정할 수 있다. 이 기능을 활용하면, 팀원들이 작업 항목과 진행 상황을 빠르게 파악하며, 효과적인 협업을 실현할 수 있다. 그러나 Projects를 최대한 활용하기 위해서는 이슈 관리 등의 기본적인 협업 지식이 필요할 수 있다.

Organization의 핵심 기능으로 Teams를 들 수 있다. Teams 기능을 통해 소속된 collaborator를 목적에 따라 그룹화할 수 있다. Teams에서는 필요에 따라 다양한 팀을 만들고 운영할 수 있다.

2. Issues

Issues는 버그 추적과 프로젝트 관련 토론을 위한 중요한 기능이다. 사용자들은 이슈를 작성하여 버그 리포트, 기능 요청 등을 다른 사용자들과 공유하고 토론할 수 있다. 이슈를 통해 프로젝트의 문제를 추적하고 해결할 수 있으며, 팀원들과의 협업과 의사소통을 강화할 수 있다.

3. Pull Requests

Pull Requests는 다른 사용자들에게 자신이 작업한 코드 변경 사항을 검토하고 병합해달라고 요청하는 기능이다. 다른 사용자들은 Pull Requests를 검토하고 의견을 주고받을 수 있으며, 프로젝트에 기여할 수 있다. Pull Requests는 코드 변경의 품질을 개선하고 버그를 예방하는 데에 중요한 역할을 한다. 이를 통해 다른 사람들과의 협업과 코드 리뷰를 통한 품질 향상을 이끌어낼 수 있다.

4. Code Reviews

Code Reviews는 GitHub에서 코드 리뷰를 위한 기능을 제공한다. Pull Requests를 통해 달느 사람들이 작업한 코드를 검토하고 피드백을 주고받을 수 있다. 코드 리뷰는 코드의 품질을 향상시키고 버그를 예방하는데에 핵심적인 역할을 한다. 팀원들은 코드 리뷰를 통해 서로의 코드를 검증하고 개선할 수 있으며, 이를 통해 더 견고하고 효율적인 코드를 개발할 수 있다.