Я ніколи не впевнений, коли проект достатньо далеко, щоб спочатку взяти на себе контроль над джерелами. Я, як правило, відкладаю свої зобов'язання до тих пір, поки проект не буде "завершеним рамкою", і я з цього моменту в першу чергу виконую функції. (Я не робив жодних особистих проектів достатньо великих розмірів, щоб мати основні рамки занадто великі для цього.) Я відчуваю, що це не найкраща практика, хоча я не впевнений, що може піти не так.

Скажімо, наприклад, у мене є проект, який складається з одного файлу коду. Для роботи проекту з надзвичайно базовими функціональними можливостями (1 або 2 функції) знадобиться близько 10 рядків кодової панелі та 100 ліній. Потрібно спочатку зареєструватися:

1. Порожній файл?
2. Код котла?
3. Перші особливості?
4. У якийсь інший момент?

Також, які причини зареєструватися в конкретний пункт?

Ви повинні взяти на себе зобов’язання, як тільки у вас буде повноцінний "блок".

Що таке одиниця? Це залежить від того, що ти робиш; якщо ви створюєте проект Visual Studio, наприклад, введіть рішення відразу після його створення, навіть якщо в ньому нічого немає.

З цього моменту продовжуйте здійснювати як можна частіше, але все ж виконайте лише завершені "одиниці" (наприклад, класи, конфігурації тощо); це полегшить ваше життя, якщо щось піде не так (ви можете відновити невеликий набір змін) і зменшить ймовірність конфліктів.

Що стосується мене, то ваш репо-контроль джерела є частиною базового налаштування проекту, тож я беру на себе зобов’язання відразу після того, як генерую свій порожній проект.

Вчора

...
замість цього , якщо ви не в змозі подорожувати часом ... (можливо, ваш автомобіль не може дістатися до 88 км / ч, або ваш флюсовий конденсатор просто відключився)

Тепер

Нові проекти повинні бути здійснені на кривавому місці, це божевільно не робити, а сучасні системи DVCS просто усунули всі можливі виправдання, щоб уникнути зобов’язань : git init . ; git add * ; git commit -m initial-commitтепер, поки не пізно, як це вже могло бути.

Ще одне розумне, спірне питання могло бути таким: "Коли я повинен об'єднати свої зобов'язання з спільним контролем джерела у сховищі, керованому командою, у встановленому проекті?" (зверніть увагу на прикметники, прикметники важливі) І я маю відчуття, що більшість інших відповідей насправді намагаються відповісти на це.

Ваша особиста гілка повинна вважатись божевільною , хоча б раз на день , перед сном. Ви можете просто прокинутись після цього ранку і виявите, що не маєте жодного уявлення про те, до чого, до біса, в минулу ніч. VCS повинен захищати вас від цього, і мати можливість перекидання на зовсім недавню під-версію під-версії, яка добре компілюється, працює безперебійно та / або проходить тести, може бути найкращим варіантом.

Я б сказав, що потрібно скоріше скористатися. Основна мета управління джерелами - це можливість повернутися назад у випадку, якщо щось піде не так, і це перегукується з практикою "рано чи часто".

Особисто мій перший комітет, як правило, містить лише файл .gitignore (або його еквівалент) з кількома фільтрами, на які я знаю, що знадобляться, наприклад * .py [co] для коду Python. Основна настройка проекту та / або перший найпростіший прототип - це те, що зазвичай випливає.

Перша фіксація може бути файлом README, який містить всього лише один підсумок рядка проекту, або достатньо інформації про перший етап проекту. До широких тем також можна віднести:

• Вступ
• Опис проекту
• Структура проекту
• Умови кодування
• Інструкції щодо того, як:
  • будувати
  • тест
  • розгортати
• Відомі проблеми та шляхи вирішення
• список справ
• Умови використання

Практика оновлення README перед внесенням змін у проект також називається розробкою, керованою Readme, і це дозволяє продумати зміни, перш ніж вкладати час для внесення цих змін.

Кожен, хто хоче внести свій внесок у або використовувати це програмне забезпечення, розпочне з README.

Якщо ви виконали роботу, яку не хотіли б втратити, це має бути у вашій системі управління джерелом.

Це звичайно стосується розподілених систем, таких як Git. Якщо ви використовуєте централізовану систему, і єдиний спосіб , щоб перевірити що - то, щоб зробити його видимим для всіх , ви могли б хотіти , щоб утримати - або ви могли б з урахуванням створення власного локального сховища Git, і уявлення централізованого система, коли ви будете готові.

Моє правило полягає в тому, щоб перевірити, як тільки мій файл рішення (або інший фрагмент сценарію побудови) буде зроблено, навіть якщо він містить кілька файлів, які порожні. Це добра практика, коли над проектом працює більше однієї людини. Цей файл, як правило, має найгірші проблеми злиття спочатку, оскільки люди додають речі до проекту, тому це потрібно робити рано і часто.

Навіть якщо ви єдиний, хто працює над проектом, і у нього є лише один файл, мені простіше дотримуватися того самого робочого процесу і зберегти мислення для проблеми.

Не впевнений, чи це було згадано.

Але переконайтеся, що те, що ви здійснюєте, виконує / компілює! Тож ніяких синтаксичних помилок тощо.

Немає нічого страшнішого, ніж порушений код оформлення замовлення.

Інша точка зору, більш пов’язана з тестуванням програмного забезпечення (TDD-підхід), буде виконувати, як тільки у вас з’являться нові випадки тестування зеленим кольором. Це означатиме, що у вас є нова «одиниця» коду.

Тільки перед тим, як зробити щось дурне.

Для тих із нас, що не мають магічних сил, це означає мало і часто.

Якщо ви працюєте самостійно, робіть це щоразу, коли ви отримуєте напій або будь-що інше.

Якщо ви працюєте в команді, вам, ймовірно, потрібно переконатися, що річ складається, так що якщо хтось інший отримає останню версію, він не отримає пакет помилок. Але крім цього, наскільки ви можете.

Близько 2 ~ 3 годин на проект.

Просто жартую. Немає жодної хорошої відповіді, яка б відповідала всім ситуаціям. Перш за все, якщо у вас є система управління розподіленою версією (наприклад, git або Mercurial), то звернення до місцевого репо не збирається зберігати ваші дані у випадку катастрофічного збою. Але приватне віддалене репо може коштувати вам грошей, наприклад, на github. Ви збережете історію комісій, але, на мій досвід, вам це не знадобиться, поки ваш проект трохи не просунеться.

Крім того, ви, мабуть, не хочете занадто сильно качати на початку, особливо якщо ви переміщуєте файли. Здійснення змін буде тягарем, якщо лише невеликий. Ви навіть можете вирішити викинути річ. Але якщо ви втратите зміни, які не банально повторювати, тоді ви пропустите резервну копію, а системи контролю версій створюють надзвичайно цінні системи резервного копіювання.

Деякі люди в даний час використовують DropBox або подібні для зберігання свого коду. Це може бути хорошим компромісом на початку проекту, оскільки для його створення потрібні нульові зусилля. Однак це варварська звичка в серйозній розробці програмного забезпечення, особливо якщо кілька людей торкаються коду одночасно.

Отже, я схильний встановлювати контроль над версіями щоразу, коли у мене є щось цінне, тобто не банальне для копіювання. Співвідношення суб'єктивне (і залежить від чиїх можливостей), тож вам доведеться зробити власне судження. У цей момент я зберігаю другу репо на зовнішньому диску або на github, якщо це публічний проект або мій платіжний рахунок буде його зберігати.

Багато людей вже відповіли «Відразу», і я на 100% згоден. Мені також подобається пропозиція Xion почати з моделей ігнорування VCS (тобто .gitignoreабо еквівалент).

Я думаю, що майже домовились, що немає ранніх домовленостей. Мені хотілося б додати:

• У вас менше шансів вчинити речі, які ви вирішили відмовитись, але це все ще затримується. Коли я розпочну нову розробку, я швидко кодую та відкидаю речі, а коли я вчинив пізніше, коли вже є маса файлів, я випадково вчинив матеріал лише для того, щоб видалити його в наступному фіксації. Це, на відміну від невеликих або навіть порожніх, чинить справжній шум в історії.
• Якщо ви є систематичним типом і маєте типові перші кроки у своїх проектах, то такі пункти, як точки фіксації, можуть бути повчальними для вас або для інших, і це може навіть надати можливість відключитися в певний момент і створити заново проект для повторного використання. Я працював над проектами на базі Мейвена, де це було корисно (тому що при створенні проекту Maven деякі невеликі перші кроки вже можуть визначити досить істотну базу, і хоча ці кроки робити не так багато , вони можуть зажадати достатнього роздуму, щоб гарантувати повторне використання).

Це може залежати від того, який VCS ви використовуєте.

За допомогою Git я здійснюю порожній каталог (або майже порожній файл README). Справа в тому, що я можу повернутися назад і повернути свою гілку до цього порожнього стану, якщо хочу повністю почати спочатку, поки я ще рано в процесі розробки (до того, як натиснути вгору за течією). Тоді я б зафіксував свої "згенеровані" файли (наприклад, рішення візуальної студії). Тоді, коли я фактично кодую, я почну виконувати кожну одиницю, як зазвичай.

За допомогою SVN ви підштовхуєтесь до кожної комісії, щоб ви не отримали розкіш починати так, як ви робите з Git. У цьому випадку, можливо, не буде корисно брати на себе зобов’язання рано, якщо ви думаєте, що будете робити капітальне оновлення на початку процесу. Це буде залежно від кодування людини.

Коли я запускаю новий проект, я, як правило, починаю, роблячи це перед тим, як якийсь код був доданий. Загальне правило, якого я завжди дотримувався, це: якщо ваш комп'ютер вийшов з ладу і стер всі ваші дані, то який код ви б не бажали писати з пам'яті. Десять років тому перед TDD та кращою практикою програмування я був досить оптимістично налаштований на те, що я міг запам'ятати. Зараз я схильний бути обережнішим. Як і багато інших плакатів, зазначають, що рано чинять свої зобов’язання та виконують часто. Ви нічого не втрачаєте, роблячи це.

Я працюю самостійно більшу частину часу, тому я повинен зізнатися, що я слабкий, але я взагалі зобов’язуюся перед тим, як піти додому. Таким чином, якщо я не зможу зробити це завтра, то мої колеги можуть підібрати там, де я зупинився.

На даний момент я використовую Tortoise / SVN на роботі.

Складіть порожній проект відразу. Продовжуйте здійснювати кілька разів на годину, витрачаючи працюючи над проектом. Введіть, навіть якщо код не компілюється. Я позначаю такі зобов’язання "WIP" в масажі фіксації, щоб відстежувати їх.

У мене також є сценарій, який автоматично передає всі мої проекти кожні 10 хвилин на резервну копію репо, на всякий випадок, якщо я забуду зробити це вручну. Назвемо це моїм підтримуваним хмарним буфером скасування.

Зареєструйтесь (ака. Push ) проекту в командному репо, коли вам потрібна ваша команда, щоб побачити ваш код. Це, мабуть, до того, як ваш код буде готовий бачити вашу команду, якщо ви щось схоже на мене.

Якщо ви хочете бути приємними до своєї команди, скорочіть свої зобов'язання, перш ніж натискати на команду репо.

Я переглянув усі статті і, думаю, у нас вже є багато хороших рішень, але я хотів би поділитися своєю методологією з вами.

Під час роботи над створенням рамки (з нуля) для кожного модуля відбудеться багато змін, поки модуль не буде завершений або доопрацьований. Тож у мене завжди є дві локації, одна з них - DYNAMIC, а інша - STATIC. Коли зміни відбуваються, а рамка ще не доопрацьована, вона була здійснена у DYANMIC-місці, і як тільки вона буде завершена та доопрацьована, я переміщу її до місця STATIC. Тож у мене повний контроль над джерелами.

Дякую

З будь-яким додатком ви збираєтеся витратити деякий час на розробку компонентів. Ви повинні знати, приблизно або повністю, пробіли ваших імен, проекти, зовнішні посилання, сторонні бібліотеки тощо.

Якщо ви в команді, я б запропонував вашому керівництву або тому, хто обраний, створити базовий проект, встановити залежності і перевірити, чи є цей скелет (фундамент, на якому буде будуватися ваш проект).

Ви також хочете переконатися, що у вас є завдання, випуск, магістраль тощо, гілки, які були визначені перед реєстрацією, щоб ваш процес був надійним.

Якщо ви працюєте над новим "завданням" для проекту, який вже виконується, і ви перебуваєте у власному відділенні завдань, робіть щонічні реєстрації, щоб ви зберегли свою роботу.

Зазвичай я зареєструюсь, коли я додаю щось нове, але намагаюся розділити речі на дискретні коміти.

Це означає, що якщо я додаю нову залежність, я вношу зміни, поки вони або не складуться, або вони досить великі, що було б втрачено час їх робити знову, з нуля. Якщо у мене є більш велике завдання, я намагаюся виконувати кілька разів, коли це має сенс (раз на функцію, кожен раз, коли я змушую її компілювати та запускати успішно тощо).

Я також виконую обов'язки, коли хочу отримати резервну точку (тобто "якщо те, що я зараз намагаюся, не вийде або стане занадто складним, я хочу повернутися до коду, як зараз", або коли хтось попросить мене кинути те, що я є робити і виправити якесь нагальне питання).

Якщо ви використовуєте централізовану систему керування джерелами, ви не можете довільно скористатися для резервних балів, оскільки комісія, яка не компілюється / працює, впливає на всіх членів вашої команди.

Зазвичай, коли я починаю додавати код котла (наприклад, додавати новий веб-сайт на веб-сайті django), я виконую кожну операцію, яку я виконую.

Якщо я слідую за підручником для генерації / запису коду, я використовую назви кроків у підручнику для повідомлень про фіксацію. Таким чином, я можу різнитися з переглядами та бачити, що робив крок підручника в будь-який наступний момент.

Скажімо, наприклад, у мене є проект, який складається з одного файлу коду. Для роботи проекту з надзвичайно базовими функціональними можливостями (1 або 2 функції) знадобиться близько 10 рядків кодової панелі та 100 ліній.

Це залежатиме від того, наскільки складно додавати речі:

• якби було тривіально додати код пластини котла, я би додав його та здійснив право перед тим, як запустити інший код (таким чином, якщо я помиляюся або ввожу дивну помилку пізніше, я можу просто повернутися до кодової коробки та запустити знову).

• Якби код був нетривіальним, я б робив кожен раз, коли я додавав щось нове (де-небудь між кожними двома рядками коду змінювався, до сотні або близько того).