עד עכשיו, כל העבודה על המשחק נעשתה במחשב נייד אחד. במעבדה, השותף שלכם עובד על אותו משחק ממחשב נייד אחר. וזה לא רק סידור של המעבדה. כמעט בכל בסיס קוד שתעבדו עליו יש כמה אנשים, כל אחד במחשב שלו. בסרטון הזה נראה איך git שומר על העותקים שלהם מסונכרנים, דרך מאגר מרוחק על שרת כמו GitHub. אחר כך נשתף עבודה על המשחק ששמורה בקומיטים, ולשלב את השינויים כששניכם עשיתם משהו חדש.
בפרויקטים אמיתיים, כמה אנשים עובדים על בסיס קוד אחד. לכל אחד יש עותק מלא של המאגר במחשב שלו, ושם הוא עושה קומיטים לעבודה שלו. עם כל קומיט, העותקים מתרחקים זה מזה. בכל מחשב יש עבודה שהאחרים עוד לא ראו.
כדי לאחד את העותקים, git משתמש ב-remote. זה עוד עותק של המאגר, על שרת שכולם יכולים להגיע אליו, בדרך כלל GitHub. כל מחשב מחליף קומיטים עם ה-remote, ואף פעם לא ישירות עם מחשב אחר.
אז העבודה עם אחרים היא סדר עבודה קבוע. שתפו את הקומיטים שלכם דרך ה-remote, והורידו את מה שהאחרים שיתפו. בסרטון הזה נעשה את זה עם שותף אחד, על המשחק שלנו. אותו סדר עבודה עובד גם לצוות שלם.
המשחק כבר נמצא ב-GitHub, עם השהיה, מצב כהה, והתחלה מחדש ממוזגים לתוך main. הסוכן של השותף שלכם מריץ git clone עם הכתובת של המאגר. clone מעתיק את המאגר כולו, כל קובץ וכל ההיסטוריה, אל המחשב שלו. המאגר שב-GitHub, זה שדרכו שני המחשבים מעבירים עבודה זה לזה, נקרא remote. כל מחשב מדבר עם ה-remote, אף פעם לא ישירות עם המחשב השני.
השותף שלכם מבקש מהסוכן שלו צליל כשהניקוד עולה. הסוכן בונה אותו בענף פיצ'ר, השותף סוקר אותו, ואז ממזגים אותו לתוך ה-main שלו. הקומיט הזה קיים רק במחשב שלו. קומיט לבדו לא שולח כלום ל-GitHub, ולא משנה כלום במחשב שלכם.
הסוכן שלו מריץ עכשיו git push, ששולח את הקומיטים החדשים ל-remote. ל-GitHub יש עכשיו את הקומיט של הצליל. במחשב שלכם עדיין יש את הגרסה המוקדמת. אחרי push העבודה זמינה ב-remote. הוא לא משנה שום קובץ, באף אחד מהמחשבים.
בינתיים, אתם מבקשים מהסוכן שלכם לשמור את השיא ולהציג אותו לצד הניקוד הנוכחי. סוקרים את זה וממזגים לתוך ה-main שלכם, בדיוק כמו קודם. הקומיט שלכם והקומיט של השותף התחילו שניהם מאותה גרסה מוקדמת. בכל אחד מהם יש עבודה שלשני אין.
הסוכן שלכם מריץ עכשיו git push, ו-git מסרב. ההודעה אומרת שה-remote מכיל עבודה שאין לכם. ב-main שלכם חסר קומיט הצליל של השותף, ו-git לא יזרוק אותו. צריך לשלב את שתי ההיסטוריות לפני שאפשר לשתף את התוצאה.
אתם מבקשים מהסוכן להכניס את העבודה של השותף באמצעות מיזוג, ולשמור את שני הפיצ'רים. הפקודה לזה היא git pull, עם האופציה --no-rebase, שאומרת ל-git לשלב את העבודה במיזוג. pull עושה שני דברים בזה אחר זה, ונסתכל עליהם אחד-אחד.
הסוכן מריץ עכשיו git pull. השלב הראשון הוא ההורדה. המאגר שלכם מקבל את הקומיט של הצליל, ואת ההיסטוריה שהוא צריך. ה-main שלכם עדיין מצביע על הקומיט של השיא, והקבצים שלכם עדיין לא השתנו. זה שקומיט נמצא במאגר עוד לא אומר שהשינויים שלו נמצאים בקבצים שלכם.
השלב השני הוא המיזוג. git ממזג את העבודה שהורדה לתוך הענף שלכם, בדיוק כמו שמיזג קודם את שני הפיצ'רים המקומיים. המיזוג משלב את השינוי של השיא ואת השינוי של הצליל. לקומיט המיזוג החדש יש שני הורים: שני הקומיטים הקודמים. אם שני השינויים מתנגשים, git עוצר בדיוק כמו קודם. אמרו לסוכן איך התוצאה צריכה להתנהג, וקראו את הפתרון שלו לפני שהמיזוג מסתיים.
בדקו את המשחק המשולב לפני שמשתפים אותו. כשצוברים נקודות, הצליל עדיין צריך להישמע, והשיא צריך להישמר גם אחרי רענון של הדף. הסוכן מריץ גם node --test. מיזוג יכול להסתיים בלי קונפליקט, ועדיין להשאיר קוד שצריך תיקון.
הסוכן שלכם מריץ שוב git push, והפעם זה מצליח, כי ה-main שלכם מכיל את כל מה שיש ב-remote. GitHub מקבל את ההיסטוריה המשולבת, עם השיא שלכם והצליל של השותף. המחשב של השותף שלכם עדיין לא השתנה.
הסוכן של השותף מריץ עכשיו git pull, והמחשב שלו מקבל את הגרסה המשולבת. ה-main שלו עושה fast-forward. קומיט המיזוג שלכם כבר מכיל את הקומיט של הצליל שלו, ולכן ה-main שלו פשוט עובר אליו, בלי קומיט מיזוג נוסף.
אותו קומיט נמצא עכשיו בשלושת המאגרים. הם זהים כי כל אחד מכם עשה push ו-pull, ולא כי git מסנכרן את המחשבים מעצמו. עבודה בלי קומיט ו-push נמצאת רק במחשב אחד.
יש עוד דרך לעדכן פיצ'ר לגרסה החדשה של main, שנקראת rebase. הרבה צוותים מעדיפים rebase, ואולי גם אתם. נחזור לרגע שלפני ששילבנו את הפיצ'רים, ונבחן דרך אחרת לעשות את זה. נניח שהשינוי של השיא היה עדיין בענף משלו, בזמן שב-main כבר היה הקומיט של הצליל. אם מריצים git rebase main על הענף הזה, git מיישם מחדש את השינוי שלכם מעל הקומיט החדש יותר של main. הענף מקבל קומיט חדש שמחליף את הישן. אם שני השינויים מתנגשים, פותרים את זה כאן, בענף שלכם, לפני שמשהו בכלל מגיע ל-main.
כשהענף כבר יושב מעל main, להזיז את main קדימה זה רק fast-forward. אין קומיט מיזוג, וההיסטוריה נקראת כקו אחד. זו כל הנקודה בשיטת העבודה הזאת. קודם מיישבים את ההבדלים בענף שלכם, כדי שכל מיזוג לתוך main יהיה פשוט. המיזוג שעשינו קודם, שמוצג כאן בתחתית השקף, שומר את שני הקומיטים המקוריים ומראה איפה שני הקווים נפגשו, והקונפליקט נפתר בתוך המיזוג עצמו. שתי השיטות בסדר גמור, והבחירה היא עניין של טעם. נסו את שתיהן במעבדה ותראו איזו אתם מעדיפים. כלל אחד תקף בשתיהן. מכיוון ש-rebase מחליף קומיטים, אף פעם אל תעשו rebase לקומיטים שכבר יש לאנשים אחרים, אחרת ההיסטוריה שלהם לא תתאים לשלכם.
זה סדר העבודה במעבדה. הפיצ'ר של כל סוכן מקבל ענף ותיקייה משלו. סקרו את העבודה ועשו לה קומיט, מזגו אותה לתוך main, ובדקו את המשחק המשולב. ואז שתפו. עשו push לעבודה שלכם, ו-pull לעבודה של השותף. למשחק שלנו יש עכשיו חמישה פיצ'רים, משני מחשבים, והיסטוריה אחת. שתפו עבודה גמורה לעיתים קרובות, כדי שבכל פעם יהיה פחות לשלב. וכש-git מסרב לעשות push, קראו את הסיבה, ובקשו מהסוכן להסביר מה צריך לקרות לפני שהוא מנסה שוב.