오늘 첫시간에는 Github 충돌방지에 대해서 배웠다. (저번에 배운거 복습하는거 같은데?)
깃허브 merge
merge란 , 개발자들이 같이 협업하는 과정에서 각자의 브랜치를 만들어서 개발을 할 때 각자의 일이 끝나고 결국에는 main 브랜치에서 소스코드를 합쳐서 테스트도 해보고 시스템에 적용을 해야한다.
이 때 , 각 브랜치를 합치는 것 (병합) 을 merge라고 함.
merge에는 두가지 상황이 존재
- 서로 다른 파일을 수정했을 때
- 서로 같은 파일을 수정했을 때
1번 상황의 경우에는 문제가 될만한 것이 없다.
2명의 개발자가 A파일과 B파일을 각자 수정했다면 merge를 할 때 충돌할 것이 없으니 자동으로 소스코드가 합쳐질 것이다.
문제가 되는건 2번의 경우. 2번의 경우에는,
- 서로 같은 이름 파일 수정, 수정한 부분 다름
- 같은 이름 파일 수정, 수정한 부분이 같을 때 V
여기서 2-2의 경우를 우리는 conflict 충돌이 일어났다고 한다.
이런 경우에는 <<HEAD>> 부터 ====까지는 master브랜치의 소스코드이고 ====부터 >>>>N브랜치
까지는 N브랜치의 소스코드인데 , git이 이 부분이 오류가 났다고 알려주는 것이기 때문에 이 부분의 코드를 수정하거나 지우거나 해서 파일을 저장한 후에 다시 commit을 해주면 정상적으로 merge가 된다.
- merge에서 메세지 파악하기
- 1.fast-foward : 빨리감기라는 뜻으로 예를 들어 A브랜치에서 급하게 다른 것을 만들어보려고 B브랜치를 생성하고 B브랜치는 여러번의 commit이 있었다.이런 상황에서 A브랜치에서 B브랜치를 merge한다고 가정할 때, A브랜치에서 B브랜치를 분기해준 것외에 별 다른 commit이 없었으므로 A브랜치는 B브랜치만큼 그냥 "빨리감기"하면 되는 상황이다.그래서 이런 상황일 때 별도의 commit log없이 B브랜치가 만든 최신의 commit log를 가리키게 만드는 것을 fast-foward라고 한다.
- 2.recursive strategy : 재귀적인 전략으로 예를 들어 A브랜치에서 B브랜치를 생성했다. 그 후 A브랜치도 commit이 여러번 있었고 B브랜치도 commit이 여러번 있었을 때 A브랜치에서 B브랜치를 merge한다.이러면 fast-foward할 수 없고 git은 A브랜치와 B브랜치의 조상 commit을 찾아 내부적으로 3way merge라는 방법을 이용하여 merge를 해준다.
실전에서는 프로젝트의 가장 중요한 부분인 master브랜치를 함부로 merge할 수 없기때문에 최대한 충돌을 예방하는 방법을 사용해야한다.
고로, master브랜치의 변화를 지속적으로 내 브랜치로 가져와서 내 브랜치와 충돌부분이 없는지 지속적으로 비교하며 작업해야 나중에 기간이 길어져도 master브랜치에 merge할 때 충돌이 적게날 수 있다.
Github 에서 프로젝트 보드 생성해서 협업하기
github 프로젝트를 사용하면 좋은 점
- 프로젝트 관리의 편의성
- 작업 항목을 카드 형태로 보드에 추가하고, 해당 항목의 상태를 컬럼으로 표시해서 프로젝트를 직관적으로 볼 수 있게 한다.
- 협업과 투명성 강화
- 작업 항목과 관련된 pull request , issue 등을 카드와 연결하여 프로젝트의 전반적인 진행상황을 투명하게 공유할 수 있음.
- issue와 결합된 관리
- issue를 프로젝트 보드의 카드로 추가하고 , 해당 작업의 진행 상태를 간편하게 업데이트 할 수 있음.
- 커스터마이징 ㅆㄱㄴ
- 사용자정의 field , lable , column 등을 추가하여 프로젝트 보드를 팀의 성격에 맞게 최적화 할 수 있음.
project 생성
- project 탭에 가서 new project로 프로젝트 보드 생성(대부분 board 형식으로 사용한다)
- 레포지토리에서 생성함 !
issue 사용방법
- New issue 버튼으로 새로운 issue를 생성한다. open과 closer 상태로 issue의 상태를 확인가능.
- issue를 생성하면 우측에 여러 설정을 할 수 있는것이 있는데 각각
- Assigness : 해당 작업 담당자
- Labels : 해당 작업의 성격
- Milestone : 해당 작업이 속한 파트
- 우측칸에 작업 담당자 , 프로젝트 연결
- 하면 To do 칸에 해당 issue가 생기는 것을 볼 수 있다.
- 다시 issue에서 issue closed를 하면 Done 에 issue가 간 것을 볼 수 있다.
git 터미널에서 branch로 push하기
- 로컬 저장소 폴더에서 git clone [git url]
- 깃허브에 있는 파일을 로컬 저장소로 복사함
- 후에 cmd 에서 git fetch origin
- origin은 누가 지정한게 아니고 초기설정 이름임 !
- git switch [branch]
- 작업하는 파일 생성
- git add *
- git commit -m .
- git push origin 하면 다시 github로 push가 된다.
주의점 . push를 하기 전 누군가 이 브랜치에서 작업을 하고 있다면 pull로 로컬 저장소를 최신화 시켜주고 다시 push를 해야 정상적으로 push 가 된다.
이클립스 github 에서 import 하기
- 이클립스에서 import 버튼 클릭
- 그 다음 나오는 창에서 github url 입력
- 밑에 계정에는 내 github 계정 입력
- 비밀번호는 토큰생성후에 토큰값을 넣어준다
- 작년부터 비밀번호를 입력하는 것은 막혔다고 한다.
- import를 할 폴더에는 반드시 workspace로 지정해줘야한다! (관리 용이)
- 가져온 파일 실행해보기.
오후는 모듈 3번 화면설계로 챕터가 넘어갔다. (진짜 빠르네..)
유스케이스 (use case)
유스케이스 : 시스템 사이에서 교환되는 메시지의 중요도에 의해 클래스나 시스템에 제공되는 고유 기능 단위이며, 상호 행위자 밖의 하나 혹은 그 이상의 것이 시스템에 의해서 실행되는 행위를 함께 함
- 유스케이스 다이어그램 작성법
- 1. 시스템 정의 -> 2. 액터 정의시스템과 상호작용하는 외부 시스템 (Secondary Actor)를 정의합니다. -> 3.Actor가 요구하는 서비스를 식별합니다. -> 4. 관계 정의Actor와 유스케이스 사이의 관계를 정의합니다. -> 5. 유스케이스 구조화
- 두 개 이상의 유스케이스의 공통된 서비스를 추출하여 일반화시킵니다.
- 유스케이스 간의 관계를 정의합니다.
- Actor와 Actor 사이의 관계를 정의합니다.
- Actor들이 시스템과 상호작용하는 행위를 식별합니다.
- 3. 유스케이스 정의
- 사용자 (Primary Actor)를 정의합니다.
- 시스템 영역과 이름을 정의합니다.
유스 케이스 작성 순서
1. 시스템 정의
시스템 영역과 이름을 정의합니다.
2. 액터 정의
사용자 (Primary Actor)를 정의합니다.
시스템과 상호작용하는 외부 시스템 (Secondary Actor)를 정의합니다.
3. 유스케이스 정의
Actor가 요구하는 서비스를 식별합니다.
Actor들이 시스템과 상호작용하는 행위를 식별합니다.
4. 관계 정의
Actor와 Actor 사이의 관계를 정의합니다.
Actor와 유스케이스 사이의 관계를 정의합니다.
유스케이스 간의 관계를 정의합니다.
5. 유스케이스 구조화
두 개 이상의 유스케이스의 공통된 서비스를 추출하여 일반화시킵니다.
다이어그램을 만들 때 유스케이스는 인터넷 사이트라고 가정했을 때, 하나의 페이지라고 생각하면 된다.
extend는 페이지를 들어가는 창에 커서를 올렸을 때 아래에 뜨는 기능들이라고 생각하면 된다.
만들 때 생각할 점
프로그램 만들때 이용자 선정
어떤 기능이있을까 생각
사용제한이 어떻게 있나?
유스케이스는 CRUD 의 기능들을 가지고 있다. (반드시 모두 포함되지는 않음)
마지막으로 피그마에 사용법에 간단하게 배웠는데 , 짧은 시간만 하고 수업이 끝나서
완전히 숙지하지는 못했다. 하지만 잠깐 사용해봤는데도 느낀 점은 왜 전세계 대부분 프런트엔드 작업에서 이 프로그램을 사용하는지 알 것 같다는 점이다.
깔끔한 인터페이스.
원할한 협업이 가능하도록 되어있는 공유(share) 기능
나도 프런트엔드를 희망하고 있기에 이 프로그램에 대해서는 앞으로 더 많은 연구가 필요할 것 같다.
'Developer Note > 국비과정 수업내용 정리&저장' 카테고리의 다른 글
| 24년 8월 16일 (0) | 2024.08.19 |
|---|---|
| 24년 08월 14일 (0) | 2024.08.15 |
| 24년 8월 12일 (0) | 2024.08.12 |
| 24년 08월 09일 (0) | 2024.08.09 |
| 24년 08월 08일 (0) | 2024.08.08 |