גית וללא דחיה
מאמר זה מתייחס באמת DVCS באופן כללי, לא רק git כשלעצמו. אבל אנחנו נתמקד תשומת לב על git כי זה נשאר DVCS הפופולרי ביותר סביב היום.
בעזרת כלי מסורתי של בקרת גרסאות מרוכזת, רשומות כאלה זמינות בקלות מהיסטוריית ה-commit. כל התחייבות למערכת עוברת מנגנון הרשאה כדי לוודא שהאדם שביצע את השינוי מורשה לטעון אותו. רשומות אלה חיוניות לארגון כדי להבטיח כי רשומות מדויקות נשמרות אשר מציינות מי אחראי על העלאת כל שורת קוד לתוכנה המדוברת.
עם git, או בקרת גרסאות מבוזרת באופן כללי, יש הבחנה ברורה בין ההיסטוריה “מחויבות” לבין ההיסטוריה “העלאה” — אני מתכוון לקרוא לזה “דחיפת רשומות”. פעולות לביצוע ב-git אינן מאומתות, כיוון שהן מתרחשות באופן מקומי, כאשר נוספו להיסטוריה מטאדטה מקומיים שלא אומתו. שלב ההעלאה, aka גיט דחיפה
למה זה חשוב? ובכן למתחילים הרשו לי להתייחס לתפיסה שגויה נפוצה לגבי הצורך בהסכמי רישיון של Contributor (ICLAs) עבור חובבי Apache. נראה שאנשים רבים אינם מבינים שבכל הנוגע ליצירותיו האינדיבידואליות של חבר הנאמנים, אין הבדל בין השפה הרלוונטית. הסכם רמת שירות וגם רישיון אפאצ’י 2.0.
מה לדחוף רשומות אז היא דרך לעקוב אחורה, לכל שורה של קוד במהדורה, הפרט Committer אחראי לדחוף את הקוד הזה למאגר git של ASF. זה חשוב באופן ביקורתי בקביעת ההוכחה של תרומת צד שלישי עם git, כי למרבה הצער זה אפשרי עבור תורם כזה “להתרחק” מהתרומה שלו לפרויקט git בגלל האופי המבוזר של יומני התחייבות DVCS. הצד האחראי אז, על פי ה-ICLA, הופך למחייב שדחף את הקוד.
אסטרטגיות מוקדמות ונכונות סובבות סביב הסרת התרומה הנטושה, אך ייתכן שהנזק לפרויקט כבר נעשה. ובלי רשומות הדחיפה, פשוטו כמשמעו לא היה לנו תהליך סמכותי כדי לקבוע כיצד קוד זה באמת נכנס לתוך repo שלנו, מלבד לטלטל דרך רשומות חלופיות במעקב אחר נושאים או תקשורת ברשימה. הסתמכות על יומני מיזוג-מחויבות בלבד לקביעת הוכחה אינה מספקת מאוד מנקודת מבט של אבטחה, מכיוון שהיא דורשת דבקות נוקשה בסוג מסוים של תהליך עבודה, שאיננו רוצים להכתיב.
ללא דברים כאלה היינו צריכים לחייב לפחות חתימה PGP על התחייבות של כל תורם, שהיא מעוררת השראה עבור פרויקטים רבים. רשומות דחיפה מספקות תהליך שקוף שאינו משפיע על תהליך העבודה של פרויקט, מלבד כדי להבטיח שה-Git repo של ה-ASF הוא ה-Repo הראשי האמיתי.