6년차 개발자. 8. Git(Svn 비교), Github

Поделиться
HTML-код
  • Опубликовано: 11 янв 2025

Комментарии •

  • @KoreaTaiwan
    @KoreaTaiwan 11 месяцев назад +1

    쉬운 설명 감사합니다! (후배분들이 부럽네요)

  • @대복이-x4d
    @대복이-x4d 2 года назад +1

    감사합니다. 덕분에 쉽게 공부하고있어요.

  • @KoreaTaiwan
    @KoreaTaiwan 11 месяцев назад

    프로젝트에서 빗버킷없다면 pl이나 동료한테 pr을 어떻게 주나요? 대형 프로젝에서 협업툴없이 sr건을 생성하고 브랜치와 매핑 시켜서 생명주기 관리하는게 가능한가요?

    • @ChakhanCoding
      @ChakhanCoding  11 месяцев назад

      안녕하세요. 착한코딩입니다.
      형상관리 서버가 없다면, 대형 프로젝트가 아니더라도
      파일을 통째로 주는 방식 등을 사용해야하니 아주 불편할거에요ㅎㅎ
      소스를 제외한 의사소통은 레드마인, 지라, 노션 등으로 할 수 있겠지만
      상용 프로그램의 소스는 무조건 형상관리를 해야합니다.
      가끔 보안 정책 등의 이유로 외부 서버를 사용하는 못하는 경우
      회사 폐쇄망에 github나 bitbucket을 세팅해 사용합니다.
      그것도 안된다면 팀 별로 여분의 PC를, 형상관리 서버로 사용하기도 합니다:)

  • @영웅서기
    @영웅서기 2 года назад +1

    안녕하세요 선배님 웹개발쪽으로 가고 싶은 취준생입니다.
    제가 이제 깃을 써보려고 하는데 깃허브에 커밋을 자주해서 잔디를 심으라는 말을 들었습니다.
    혹시 깃허브에 커밋을 할때
    의 기준을 어떻게 잡아야할까요?
    알려주시면 정말 감사하겠습니다.

    • @ChakhanCoding
      @ChakhanCoding  2 года назад +1

      안녕하세요.
      github contributions(기여도) 그래프 모양이
      잔디를 심어 놓은 것과 비슷해서 비유를 많이 하는데요.
      개발자마다 커밋을 하는 시점이 다른데
      제 생각은 그래프를 채우기 위한 커밋은 의미가 없습니다.
      다른 사람보다 일을 많이 한 것 처럼 보이기 위해서 일부러
      커밋을 많이 할 필요는 없습니다.
      여러 명이 협업을하는 실무에서는 오히려 커밋을 많이 하면
      히스토리 row가 많아져 가독성이 떨어집니다.
      개인 프로젝트를 진행할 때에는 백업 목적으로
      작업 단위를 작게 나눠서 커밋해도 상관없지만,
      회사에서는 큰 작업 단위로 하는 게 좋습니다.
      여러 명이 커밋+푸시하는 repository에서 커밋 단위를 작게 쪼개고 싶다면
      개인 branch를 사용하는 방법이 있습니다.
      중요한 건 커밋 숫자가 아니라
      동료나 미래의 내가 커밋 히스토리 1건만 봐도
      어떤 변경 사항이 있었는지 쉽게 알 수 있어야 합니다^^

    • @영웅서기
      @영웅서기 2 года назад

      @@ChakhanCoding 조언감사합니다.

  • @임쭈쭈현
    @임쭈쭈현 2 года назад +1

    감사합니다~

  • @whenai
    @whenai Год назад

    와…뭔 말인지 하나도 모르겠네요…