도움말 - 글감 수집하기 (인용)

도움말 - 부분 리뷰 작성하기

이제, 스케치(Sketch) 디자이너도 GIT 을 사용할수있습니다.

ProductHunt에서 사용해보실수있습니다

Version control 는 파일 세트에 대한 모든 변경 사항을 기록하고 저장하는 시스템으로 언제든지 이전 상태로 되돌아 갈 수 있습니다. 개발자들은이 방법을 오랫동안 사용해왔습니다. (버전 제어 시스템의 첫 번째 종류는 70 년대에 개발되었다.) 이제 소프트웨어없이 소프트웨어를 심각하게 작성하는 것은 생각조차 할 수 없다.

대조적으로, 버전 제어는 대부분의 디자이너가 무시하거나 생각조차하지 않는 것입니다. 결과적으로 이러한 디자이너 (및 해당 팀)는 다음과 같은 버전 관리 전 시대의 고전적인 문제에 종종 직면하게됩니다.

  • 애매하고 / 창조적인 파일 이름은 다른 버전을 추적하게합니다.
  • 오래되거나 / 버려야할 초안 상태 항목을 구분할 명확한 방법이 없습니다

  • 팀원들이 두 버전간에 변경된 사항을 신속하게 확인할 방법이 없습니다.

  • 마지막 2 시간의 작업물을 실수로 이어지는 손실

  • 기타.



Dropbox는 어떻습니까?

Enki에서는,  Sketch를 사용합니다. 하지만 최근까지 Dropbox에서 스케치 파일을 공유하고 있었지만 그다지 훌륭하지 않았습니다 ...

예를 들어, 최신 변경 사항을 확인하기 위해 Sketch 파일을 열고 스크롤을 시작합니다. Sketch는 "autosave"이라고하는이 멋진 기능을 제공합니다. 스크롤하면 스케치 파일이 변경됩니다. 따라서 실제 변경없이 동일한 파일의 충돌하는 사본이 여러 개있을 것입니다.

이것은 Dropbox에서 우리가 가진 많은 문제 중 단지 하나 일 뿐이며 오래된 것들은 동일한 근본 원인, 즉 통제가 불가능 합니다.

대부분의 사람들처럼, 우리도 자동화를 좋아합니다. 그러나 버전 관리의 핵심은 콘텐츠의 진화에 어떤 순서와 의미를 부여하는 것입니다. 

중요한 변경 사항 (팀에 알릴 가치가있는 변경 사항)과 작은 변경 사항을 구별해야합니다. 실제 실험과 비교하여 개인적인 실험 (결코 공유하지 않을 수있는 실험)을 구분하고 싶습니다. 

가장 중요한 것은 실제 인간의 단어를 사용하여 변경 내용을 간결하게 설명하고자하는 것입니다. 자신의 이익을 위해 (최근에 한 일을 기억하십시오), 그리고 팀의 이익을 위해!

이러한 것들은 Dropbox로 제어 할 수 없습니다.

왜 git이  훨씬 나은가?

이미 git에 익숙한 분들은이 섹션을 건너 뛰고 싶을 것입니다. 다른 사람들을 위해 : git을 버전 제어의 최첨단으로 생각하십시오. TON을 제공하여 수백 가지 워크 플로우를 수용하는 데 필요한 모든 기능을 제공합니다. 여러 버전의 파일을 유지 관리하고 여러 실험을 수행 할 수 있으며 작업의 최신 "최신"버전을 유지할 수 있습니다. 필요한 경우 변경 사항을 롤백 할 수 있으며 원하는 때에 기록을 다시 쓸 수도 있습니다.

간단히 말해서 : git는 매우 똑똑하고 강력한 도구입니다.

또한 매우 성숙하고 안정적인 도구로서, 특히 오픈 소스 세계에서 활발한 개발자 커뮤니티에 의해 사용 및 유지됩니다. 전임자의 모든 최상의 기능 (예 : cvs, svn)을 결합했으며 드문 경우의 경우에만 기술적으로 부족합니다. 따라서 전문 개발자는 git해야하는지 거의 궁금하지 않습니다. 그들은 기본적으로 그렇게합니다.

그럼 디자이너들은 왜 git을 사용하지 않는 걸까요?

이 질문에 대한 세 가지 주요 대답이 있습니다. 첫 번째 대답은 잘못된 대답으로 간주됩니다. git은 디자이너에게 너무 복잡합니다. 허락하신다면, git는 익숙해지는 간단한 도구는 아닙니다. 주니어 개발자는 실제로 익숙해지기 전에 약간의 연습이 필요합니다. 그러나 git의 핵심 기능을 이해하는 데는 컴퓨터 과학 또는 수년 간의 프로그래밍 경험이 필요하지 않습니다. 실제로 필요한 모든 것은 공부할 시간이 조금 필요합니다.

두 번째 해답 - 더욱 정확한 IMO - 디자이너 커뮤니티는 아직 자식 사용 문화와 습관을 갖지 못했습니다. 개발자들이 git을 표준으로 만드는 데는 수년이 걸렸습니다. 그리고 일부 기술 팀 (예 : 은행 부문)은 이전 작업 방식 (예 : git의 전신 인 svn 사용)을 변경하기를 여전히 꺼립니다. 같은 방식으로, 디자이너 커뮤니티는 git에서 불필요한것을 제거하고 그 가치에 대한 신뢰를 구축해야합니다. 그리고 이것은 약간의 시간이 걸릴 것입니다.

세 번째 해답은 가장 실용적인 것인데 - git은 주로 디자인이 아닌 코드 (텍스트 파일과 같이 : 스케치 파일과 그림과 같이) 용으로 설계되었습니다. 스케치 파일을 서로 비교할 수있는 쉬운 방법이 없습니다. PSD 파일도 동일합니다.

여기서 큰 개선을위한 여지가 있습니다. 디자이너의 생산성을 대폭 향상 시키려면 다음 디자인 툴이 "비슷한"파일 포맷을 필요로 할 것입니다.

그러나 그 동안 우리가 지금 당장 행동을 취하는 것을 멈추어서는 안됩니다.

제가 어떻게 해결 하려고 할까요?


Logo credit : Miloš Milikić

디자이너가 스케치에서 git을 직접 사용할 수 있도록 스케치 플러그인을 만들었습니다. 플러그인은 디자인의 모든 부분에 대해 이미지를 내보내 검토 프로세스를 향상시킵니다. 팀의 모든 구성원은 Github의 인터페이스를 통해 다음 반복 내용을 신속하게 확인할 수 있습니다.

스케치 폴더에서....


git로…


이제 설계 프로세스의 각 단계가 문서화되었습니다. 신규 사용자는 현재의 반복 과정에서 우리가 어떻게 끝났으며, 왜 다른 옵션이 아닌 이옵션을 사용했는지 이해할 수 있습니다.

아직 완벽하지는 않습니다. 스케치 파일은 "un-mergable"으로 유지됩니다. 즉, git이 동일한 파일의 두 가지 수정을 조정할 수 없습니다. 만약 2 명의 팀원이 같은 파일의 다른 부분을 동시에 작업한다면 git은 무엇을해야할지 모릅니다.

비교하면, 텍스트 파일 (예를 들어 소스 코드)에서 작업 할 때, git은 수정 된 라인을보고 함께 병합합니다. 우리가 같은 라인에서 일하지 않는다면 아무런 문제가 없습니다.

스케치 (또는 PSD 등)를 텍스트 파일로 표현할 수 있다면 우리는 마침내 동일한 파일에서 동시에 작업 할 수 있습니다.

자, 어떻게 도와 드릴까요?

기본적으로 텍스트 파일 인 JSON (JavaScript Object Notation) 파일로 파일을 변환하는 Sketch 용 도구가 있음을 알게되었습니다. 유감스럽게도 변환은 양방향이 아니므로 JSON 표현에서 스케치 파일을 만들 수는 없습니다.

이 기능을 사용할 수있게되면 무한한 가능성의 바다가 열립니다.

하지만 Sketch가 git에 익숙해지는 방법을 배우려면이 기능을 추가 할 때까지 기다릴 필요가 없습니다. git에 대한 소개가 많이 있습니다. Enki에서 git 화제를 시작 했으므로 git와 관련된 이동 중에도 유용한 팁과 트릭을 원한다면 확인하십시오.

git에 대한 소개글 링크

  1. git에 대한 소개글

  2. git에 대한 소개글

  3. git에 대한 소개글

  4. git에 대한 소개글

  5. git에 대한 소개글


오, 그건 그렇고,
ProductHunt에서 사용해보실수있습니다. 안녕하세요. :)

번역글 입니다. 원본링크


리뷰