גיט טקסטי: Git ללא־מתכנתות

מילים דיגיטליות 

בקרת גרסאות היא כח על שמאפשר לנוע בחופשיות אחורה וקדימה בזמן, לפצל יקומים ולעשות את הבלתי־יאמן (כמו שת״פ!) — אין סיבה שרק מתכנתות יהנו מזה.

מצב העמוד: נבט 
תוכן עניינים

העמוד הזה הוא רק נבט קטנטן, טיוטה ראשונית שעוד רחוקה מבשלות.

מה זה בקרת גרסאות ולמה זה טוב

מה זה

אולי השם „בקרת גרסאות”לפעמים מכונה גם „ניהול גרסאות”. באנגלית השם הכללי הנפוץ בימינו הוא version control. לא מוכר לך, אבל סביר שהשתמשת בצורה כלשהי של זה גם אם לא ידעת לשיים את זה:

אז כל אלה שיטות פשוטות לבקרת גרסאות, ולכולן יש את החסרונות שלהן. למרבה השמחה, א·נשים טובות וחכמות עמלו הרבה כדי לבנות לנו כלים טובים מאלה, כלים יעודיים למטרה של ניהול גרסאות שונות של קבצים על פני זמן, פיצול ומיזוג של ענפים של שינויים ושיתוף פעולה בין א·נשים (אפילו מאות!) באופן נוח.חלק ממה שיפה בכלים האלה הוא שהם מועילים גם לארגון העבודה של אדם אחד, גם לקבוצה קטנה וגם לפרוייקטי פיתוח עצומים כמו הליבה של לינוקס, עם המוני מפתחות ומספר אסטרונומי של שורות קוד. התוצאה היא דרך פעולה ששינתה לחלוטין את איך שפיתוח תוכנה מתקיים.

אבל המילים האחרונות הן בדיוק הסיבה שכתבתי את הדף הזה: ההשפעה של בקרת גרסאות היא בעיקר בעולם הפיתוח, ואין סיבה שזה יהיה מוגבל לספירה הזאת: גם מי שלא מתכנתות יכולות להפיק תועלת מארגון העבודה סביב הכלים האלה, והמטרה כאן היא להנגיש שימוש בבקרת גרסאות — ספציפית בעזרת מערכת בשם Git, שהיא הכי נפוצה בפער — אצל א·נשים שכותבות מלל ולא (רק) קוד: אקדמאיות, בלוגריות, סופרות, עיתונאיות וכל מי שעובדת עם קבצי טקסט (עוד על זה בהמשך).

למה זה טוב

סיבה אחת היא עשיית סדר בכאוס. נניח שפתחת מעבד תמלילים ועשית איזה שינוי בקובץ. איזו דרך יש לך לעקוב אחרי השינויים? אפשר להשתמש בשיטות החורניות־משהו שהוזכרו למעלה, בחלק ממעבדי התמלילים יש תמיכה בסיסית בגרסאות בזמן השמירה, ובחלק משירותי האכסוןכמו דרופבוקס כמדומני. אני לא משתמשת בזה אז אני לא מכירה ממקור ראשון, אבל קראתי שזה קיים. יש גם תמיכה בסיסית. החסרונות של השיטות האלה הוא שהן לוקחות את הרע מכל העולמות:

לעומת זאת, ניהול גרסאות מודרני בנוי בצורה של נקודות שמייצגות את מצב הדברים בזמן מסויים ומתחברות ביחד:במונחים מתמטיים — אם המשגה כזאת מדברת אלייך — מדובר באופן רגיל בגרף מכוון חסר מעגלים עם שורש (צומת שממנו קיים מסלול לכל צומת אחר בגרף): הכיוון הוא סדר הזמן (איזה מצב בא אחרי איזה מצב, ומה השינויים בין מצב א׳ לב׳), חוסר המעגליות נובע מחוסר המעגליות של הזמן שלנו ושל השתלשלות הגרסאות (צריך לכתוב סיפור מד״ב על פרדוקסים של מסע בזמן ובקרת גרסאות!), והשורש הוא הקומיט הראשון במאגר, ממנו הכל נובע ומתפתח.
למידע נוסף: ויקיפדיה. תודה לאוּר על התיקון.
אני מודעת לזה שהאייקון בצד () הוא לא מכוון; זה רק איור.

זה מתחבר סיבה השניה למה בקרת גרסאות זה טוב: בטחון. כשאת שומרת באופן מסודר שינויים במערכת בקרת גרסאות (וכאמור, נותנת כותרות קצרות וקולעות), את יכולה להיות בטוחה שלא אם כן תעשי דברים ממש טיפשיים בכוונה (ויש מגנוני בטחון נגד לעשות שטויות) את לא הולכת לאבד דברים. זה שונה מאוד מעבודה ללא בקרת גרסאות, שדומה קצת למשחק בחשמל חי על העותק היחיד שיש לנו.לדוגמה, נגיד שעשית איזה שינוי לפני יומיים ופתאום קלטת שמחקת או שינית משהו שלא רצית ועכשיו לכי תשחזרי איך זה היה קודם. את לא רוצה להסתמך על ה־undo במקרה כזה… מעבר לבטחון שנותנת שמירת הגרסאות, יש את זה שנובע מהיכולת לפצל ענף של שינויים, לעבוד עליו באופן שבטוח לא יפגע בענפים האחרים, ובסוף למזג ביחד באופן שמאפשר גם אחרי המיזוג לראות מה השתנה איך ומתי. זה קצת מזכיר עבודה בשכבות בתוכנה גרפית, כששינויים בכל שכבה לא משפיעים על האחרות.

הערה קטנה: בקרת גרסאות היא לא תחליף לגיבוי. כל אדם מהכלים האלה נותן הגנה מסוג אחר.אם כבר מדברות על זה, אני ממליצה בחום על Borg, שכולל שלל פיצ׳רים שימושיים לגיבוי, ולנהוג לפי חוק ה־3-2-1: לפחות שלושה עותקים, לפחות שני סוגי מדיה (כמו גיבוי מקוון וגיבוי בכונן נייד) ולפחות אחד שנמצא במקום פיזי אחר (לא הכל בבית). Everything not saved will be lost, כמאמר מעשה עתיק יומין.

הסיבה השלישית היא שיתוף פעולה. בזכות הארגון של הגרסאות והעובדה שאפשר בקלילות להתנסות בשינויים בלי לסכן את הקיים והשמור, ובזכות כלים שפותחו למטרה הזאת בתוך גיט והאקוסיסטמה שמסביבה, המערכת מאפשרת לכמה א·נשים לעבוד על אותו הפרוייקט במקביל: ללא הארגון והסדר כל נסיון לשתף פעולה היה נגמר בבלגן טוטלי, וללא הבטחון לא היה אפשר לשלב קבצים עם שינויים שעבדו עליהם א·נשים שונות בלי חשש. ככה מתנהלים היום כמעט כל הפרוייקטים של פיתוח תוכנה, ואין סיבה שלא להשתמש באותן השיטות גם לכתיבת מאמרים משותפים, עריכת ספרים משותפים, בלוגים שיתופיים וכד׳.

העמוד עדיין לא כתוב כולו. כמה ראשי פרקים להמשך:

* למה בקרת גרסאות?
** סדר בכאוס
*** באתרים: היסטוריה של הדף
** למה גיט דווקא?
* עבודה עם קבצי טקסט פשוט
** בלוגים: מרקדאון ב־SSGs, טייפסט, רק לזרוק מילה על אופציות נוספות
** כתיבה אקדמית: לאטך וטייפסט
** מה לעשות עם עבודות עם וורד, ליברה אופיס או גוגל מסמכים וכד׳?
*** ללמוד לעבוד עם קבצי טקסט פשוט שתמיד נמצאים אצלך ותמיד קריאות ושמישות ונוחות
*** אם אין ברירה, עקרונית אפשר לכלול גם קבצים בינריים בגיט אבל זה פשוט לא הכלי המתאים לזה ועדיף להמנע
**** כמו לדפוק מסמר עם מזלג: זה פשוט לא הכלי המתאים למטרה, והתוצאה בהתאם
* שת״פ
** לעבודה ממש ממש ביחד בזמן אמת הכלי המתאים הוא אוברליף או ממשק הווב של טייפסט או דברים דומים
*** השאלה היא עד כמה זה באמת משהו שנדרש, הסינכרוניות הזאת
**** אני לא מכחישה שיש תסריטים שבהם זה עדיף, פשוט את צריכה לשאול את עצמך אם זה התסריט שלך
*** בכל מקרה, גם אם עובדות בכלי בזמן אמת, אפשר לעקוב אחרי גרסאות עם גיט (אין סתירה), פשוט צריך למצוא את הנקודות המתאימות לבצע בהן קומיט
** לעבודה בבלוקים, שיכולים גם להיות די קטנים, עדיף גיט
*** יש לזה גם את היתרון שברור מה קורה בשת״פ, והדברים לא בכאוס
**** עצם העבודה בבלוקים עם כותרת עושה סדר בדברים
***** אפילו כשעובדות לבד! אפילו אם אף אחת אחרת לא תקרא את ה־commit messages שלך עדיין יש לזה אפקט מועיל של סדר
* ממשקים
** lazygit
** [[https://git-scm.com/tools/guis][אופציות נוספות]]
*** אין לי נסיון עם אף תוכנה אחרת שם כי lazygit עונה באופן מושלם על הצרכים שלי, אבל למי שחוששות משורת הפקודה אני משערת ש־[[https://desktop.github.com/][GitHub Desktop]] בשלה ונוחה (דיסקליימר: מעולם לא השתמשתי בזה)
**** למרות השם, אפשר להשתמש בה גם לא עם גיטהאב
**** למרות שהיא מפותחת על ידי מיקרוסופט מדובר בתוכנה חופשית בקוד פתוח
** נחמד ומועיל לדעת להשתמש בגיט דרך ממשק הפקודה הסטנדרטי, אבל זה ממש לא הכרחי
*** טוב כידע משלים, טוב בשביל דברים מיוחדים שרוצות לעשות ולא נתמכים בממשק, אבל לאו דווקא הדרך הכי נוחה להשתמש בגיט גם בשימוש שותף אצל מי שמכירות את שורת הפקודה (אני מעדיפה לייזיגיט כי זה מקצר את המרחק בין המחשבה והאצבעות ומציג את הכל בצורה ברורה על המסך)
** מצד אחד, יש ב־Stack Exchange תשובות לכל השאלות הבסיסיות שקשורות לממשק שורת הפקודה, ולהרבה לא בסיסיות; מצד שני, עם ממשקים הרבה פעמים בכלל לא צריך להגיע ללשאול את השאלה ולחפש ברשת, אם הממשק מסביר את עצמו בצורה טובה ונגישה (נגיד בלייזיגיט יש הסברים מאוד ברורים בלחיצה על ~?~)
** תמיכה מתוך העורך
*** כל עורך מודרני
**** הכלים שמגיעים עם LazyVim וההגדרות ברירת המחדל מתאים לצרכים שלי
**** למי שמעדיפות עורכים גרפיים, יש את VSCode/VSCodium, שהשמועות אומרות שנגיש יותר למי שבאות מהעולם הגרפי
*** טוב לדברים מסויימים (סימון של מה שהשתנה בקובץ, עבודה עם hunks ו־diff ו־blame), שקשורים הדוקות לעריכה, אבל רק משלים לדברים אחרים, שנעשים בעזרת כלי מתאים אחר
* השימוש בגיט
** ענפים זה טוב, מארגן את העבודה כך שדברים לא מתנגשים והקומיטים נשארים נקיים וברורים
* דברים לשלב איפשהו:
** [[https://hed.im/@ruxotves/117090449629062622][שכבות של רתיעה]]
** שיטות גרועות־אך־נפוצות:
*** תמיכה בסיסית ולא מספיק טובה שיש בכלים קיימים כמו דרופבוקס, גוגל דוקס, תוכנות אופיס וכד׳
**** למה לא מספיק טובה?
***** אי אפשר לסמוך עליה, וזה גרוע גם להיות אכולות דאגה כל הזמן שאנחנו מחרבות לעצמנו וגם אם באמת חרבנו אז לא בטוח שנוכל לחזור באופן מועיל
***** אוטומטיות מול כוונה. מושג הקומיט
***** ענפים ושאר דברים
****** אמנם מוסיף עוד עבודה, אבל זה גם שווה את זה כשלעצמו, וגם גורם לעבודה מסודרת יותר על החומר עצמו
** יש „#link("https://he.wikipedia.org/wiki/%D7%90%D7%96%D7%95%D7%A8_%D7%99%D7%A9%D7%99%D7%91")[אזור זהבה]”: לא לקבץ בקבוצות קטנות מדי („הקלד את האות שי״ן במילה ‚שלום’”) אבל גם לא גדולות מדי („הוסף את עבודת הדוקטורט”). השינויים צריכים להיות קשורים, מאותו הסוג ו„אטומיים”, כלומר לא פְּריקים לתת־קבוצות שהיה עדיף לשמור בנפרד.
* איך לעבוד עם גיט וטקסט
** בלוגים ואתרים
*** [[https://brennan.day/every-commit-a-sentence-git-commit-messages-for-bloggers/][ההצעה של Brennan Kenneth]]
** כתיבה ארוכה יותר
*** מה? מאמרים, ספרים וכד׳
*** שאלה רלוונטית: האם ואיך לחלק לקבצים קטנים יותר
**** בבלוגים ואתרים יש יחס די פשוט: דף אחת באתר ↔ קובץ מקור אחד (+קבצים נלווים כמו קבצי תמונה); אבל בכתיבה ארוכה יותר זה פחות ברור
**** השתכללות הכלים לא נותנת תשובה חלקה: מצד אחד דברים כמו LSP, שמאפשרים ניווט פשוט במסמך מורכב וקבלת מבט־על, מקטינים את הצורך בחלוקה לקבצים, אבל הם גם מאפשרים ניווט פשוט ומתכלל גם בפרוייקטים שמפוצלים על פני מספר קבצים
**** קיפול הוא ידידנו הטוב
***** ב־NeoVim
****** vim.keymap.set("", "<tab>", "za", { desc = "Toggle Fold" })
******* כדאי להכיר את הקיצורים הרלוונטיים, אבל ~za~ מספיק שימושי כדי לתת לו מקש יחיד
****** [[https://github.com/kevinhwang91/nvim-ufo][nvim-ufo]]. מותקן עם LazyVim, שאני ממליצה בחום גם למתחילות וגם למתקדמות
**** הרלוונטיות של השאלה לעבודה עם בקרת גרסאות
*** סוגי בקומיטים קונבנציונליים
**** הסוג post/page מתאים לכתיבה של יחידות אטומיות במידה מסויימת (אבל שיכולות להתחבר בשבילים, כמובן!), בעוד שבכתיבה ארוכה יותר בסופו של דבר אנחנו עובדות עם טקסט ארוך אחד, מורכב ומחולק.
***** פתרון אחד הוא לעבוד די רק עם ~edit:~ לשינויים של תוכן הטקסט, כולל הרחבות
****** מאבד רזולוציה
***** פתרון אחר הוא להפריד בינו לבין ~add:~ או ~write:~, שמיועדים להוספה של חומר חדש (בניגוד לעריכה או להרחבה בקנה מידה שנשאר בתחום מה שהיה לפני הקומיט)
****** כהרחבה של הפתרון הקודם, בתלות באיך שהטקסט בנוי אפשר להשתמש בסוג ~section:~ (או ~add:~ או ~write:~), ולהחליט שהחל מרמה מסויימת של סיעוף ומטה זה ~edit:~ והחל ממנה ומעלה זה סוג אחר
**** סוגים נוספים
***** ~bib:~ לדברים שקשורים לביבליוגרפיה או ~data:~ שקשורים לקבצי נתונים שנעשה בהם שימוש
***** לדברים שקשורים לקוד ממש, במידה ויש, אפשר להשתמש בסוגים המקובלים
** כמו בקוד, גם כאן כדאי להשתמש בגיט די מההתחלה, ולא לחכות שיהיה איזה משהו ראשוני ורק אז להתחיל
* בשולי הדברים, Git forges
** לא חייבות להשתמש בכלל
*** בטח אם עובדות לבד ולא רוצות לשתף את הריפו
*** עקרונית אפשר לעבוד עם גיט בלי פורג׳ז (נגיד עם דואל), אבל כיום זה בגדר חכמה מיסטית אזוטרית
** סקירה (להפנות אל ~disdonu-zinojn:heb:publish-online~)
*** לשימוש כללי ממליצה על קודברג (או סורסהאט)
*** גיטלאב פסדר, אבל למה בעצם להתפשר על משהו באמצע בין תוכנה חופשית בקוד פתוח שמתוחזקת ונכתבת על ידי הקהילה ובין תוכנה קניינית ומסחרית בקוד סגור?
*** הייתרון היחיד של גיטהאב זה שלהמון א·נשים יש חשבון שם אז יותר זמין לקבל pull requests ושימצאו את הריפו שלך במקרה (+כוכבים…)
*** לאמיצות ולמי שמתות על ביזור ממליצה על רדיקל
** לא רק שזה לא חתונה קתולית (קל מאוד להעביר פרוייקטים), זאת למעשה יכולה להיות פוליקולה (קל מאוד לעשות שפרוייקט ישותף בכמה מקומות, ולסנכרן ביניהם בקלות)


מקור · היסטוריה