오늘은 하루종일 Git과 씨름했다.
코드를 짤 줄 알았는데..!!
그래도 머리 깨지게 깃을 체험하면서 많이 깨닫는게 있었다.
각자의 레포지터리에서 협업하기
깃허브의 "포크" 눌러서 create fork 해서 내꺼로 가져옴
컴퓨터에 폴더를 하나 만들고
git bash 에서 파일 경로로 들어가서 git clone 하고 인텔리제이에서 그 파일을 열어봄
--> 안됨.
--> File -> Open --> 세부의 src파일을 열었음. --> 됨
git status 로 파일 뭐 있나 보고
그중에서 올릴 파일 하나만
git add 복붙(경로까지)
git commit
git push
--> pull request
git push origin main 의 origin은 깃허브 주소를 의미함.
origin2를 연결해서 사용 할 수도 있음
한 레포지터리에서 브랜치를 만들어서 협업하기
git branch
git checkout main
git checkout -b dev dev라는 branch를 내 로컬에 만듦(깃의 브랜치와 이름을 똑같이 하는게 좋음)
git pull origin dev 저장소의 dev의 내용을 내 dev로 땡겨옴
git branch -a 로 확인
git pull origin dev 한 뒤, jaehyu 브랜치로 이동하여
인텔리제이 왼쪽 밑에 Git 이라는 버튼 누르면 브랜치들 이름이 보인다.
이때, 우클린하여 merge main into jaehyun을 하면 왼쪽, 오른쪽, 가운데 떠서 딸깍만 하면 main에서 jaehyun브랜치로 가져오면서 쉽게 바꿀 수 있다.
SOLID (객체 지향 설계 원칙) -심화반 강의-
객체 지향적으로 설계하기 위해 SOLID 라 불리는 다섯 가지 원칙이 있다.
1. 단일 책임 원칙 (SRP, Single Responsibility Principle)
- 하나의 클래스는 단 하나의 책임만 가져야 한다.
- 단일 책임 원칙을 지키지 않을 경우 한 책임의 변경에 의해 다른 책임과 관련된 코드에 영향이 갈 수 있다.
2. 개방-폐쇄 원칙 (OCP, Open/Closed Principle)
- 소프트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀 있어야 한다.
- 기능을 변경하거나 확장할 수 있으면서 기능을 사용하는 코드는 수정하지 않는다.
3. 리스코프 치환 원칙 (LSP, Liskov Substitution Principle)
- 프로그램 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다.
- 상위 타입의 객체를 하위 타입의 객체로 치환해도, 상위 타입을 사용하는 프로그램은 정상적으로 동작해야 한다.
4. 인터페이스 분리 원칙 (ISP, Interface Segregation Principle)
- 범용 인터페이스 하나보다 클라이언트를 위한 여러 개의 인터페이스로 구성하는 것이 좋다.
- 인터페이스는 인터페이스를 사용하는 클라이언트를 기준으로 분리해야 한다.
- 클라이언트가 필요로 하는 인터페이스로 분리함으로써 각 클라이언트가 사용하지 않는 인터페이스에 변경이 있어도 영향을 받지 않도록 만들어야 한다.
5. 의존관계 역전 원칙 (DIP), Dependency Inversion Principle)
- 추상화에 의존해야지 구체화에 의존하면 안된다.
- 고수준 모듈은 저수준 모듈의 구현에 의존해서는 안되고 저수준 모듈은 고수준 모듈에서 정의한 추상 타입에 의존해야 한다.
이제 내일은 드디어 팀프로젝트 코딩에 집중하는 시간을 가져보자.
