אני אתן דוגמא איך זה עובד אצלנו:
 
(חברת מוצר, כמה עשרות אנשי פיתוח):
 
א. לכל צוות יש git repository משלו, שבו מבצעים את הפיתוח המשותף הפנימי של הצוות. בכל צוות יש "אחראי git" אחד (אחד המפתחים), שמושך שינויים מאנשים (עובדים בשיטה של pull, לא של push).
 
ב. יש git repository אחד מרכזי לחברה, עם אחראי git אחד (אחד המפתחים בחברה), שמושך קוד מה-repositories של הצוותים. אחראי ה-repositories הצותיים מושכים קוד מה-repository המרכזי ("מלמעלה") מדי פעם (לפעמים פעם ביום, לפעמים פעם בכמה ימים, לפעמים כמה פעמים ביום) ועושים merge.
 
ג. בתקופות סיום של ייצוב גרסא, עוקפים את ה-repository הציוותי, ושולחים בקשות משיכה ישר ל-repository המרכזי.
 
ד. כשאדם מפתח קוד לבד - הוא עובד מקומית אצלו. מדי פעם הוא מושך מה-repository שמעליו (ומבצע rebase) - כדי לקבל שינויים מלמעלה ולראות שהוא לא שבר את הקוד. כשהוא עשה סדרה של שינויים ש"סגורה על עצמה" ועובדת (יכול היות פעם ביום, פעם בכמה ימים, ולעיתים פעם בכמה שבועות) - הוא מושך את הקוד מלמעלה, מבצע rebase, בודק שלא שבר דברים, מתקן מה שצריך, ובסוך שולח בקשת משיכה למעלה.
 
ה. כשיש פיצ'ר שמפותח ביחד בין כמה אנשים, ודורש שינויים מסונכרנים - אחד מהם פותח אצלו branch שבו הם מפתחים את ה-feature. אותו אדם אחראי לקחת על ה-branch הזה מלמעלה כמו ב-repository הצוותי.
 
תדירות לקיחת שינויים מלמעלה נקבעת על ידי כל branch וכל repository באופן נפרד, בהתאם לצרכים שלהם ובהתאם לנוחות שלהם. מאחר ומי שמוסיף קוד חדש צריך לוודא שהוא עובד עם מה שיש למעלה - אפשר לשמור על כך שה"למעלה" יציב ועובד (פרט למקרים חריגים מאוד).
 
ו. הפיתוח מחולק ל-milestones. בזמן שמייצבים מיילסטון אחד, חלק מהאנשים כבר מתחילים לעבוד על ה-milestone הבא (נובע מגודל הצוות ביחס ליכולת למקבל פיתוח של כל "עבודת פיתוח"), ולכן פותחים עבורו branch חדש. כששולחים קוד למעלה ב-branch של מיילסטון נמוך - דואגים לבצע מיזוג שלו גם ל-branch של המיילסטון הגבוה, ושולחים אותם ביחד.
 
ז. בנוסף, בזמן ייצוב גרסא X, יש אנשים שכבר התחילו לעבוד על גרסא Y - ואז יש לה branch משלה, ואותו נוהל מיזוג כמו בסעיף הקודם.
 
אני יכול לאמר שהמודל הזה די נוח, די גמיש, ודי קל לעבוד איתו.
 
לגבי נוחות העבודה עם branch-ים מרובים - לרוב זה מתנהל די חלק (אם כי יש אנשים בודדים אצלנו שלא מרגישים נוח עם git). צריך לעבוד עם זה בצורה מאוד מתודית (אחרת אפשר לחרבש את ה-repository - ואז קשה מאוד לתקן את זה).
 
ביצוע merge בסביבה של git לרוב מהיר בהרבה מאשר ביצוע merge מקביל בסביבה של cvs, svn ואחרים. גם כשיש התנגשויות, אפשר לטפל בהן. העובדה ש-git מנהל patches ולא קבצים, אומרת שכל שינוי הוא אטומי, ולכן ביצוע revert לשינוי לא מוצלח מתבצע בפקודה אחת (במערכות האחרות צריך לבצע undo בנפרד לכל קובץ בצורה ידנית, ככל שזכור לי), ואומרת גם ששינוי לוגי אחד "נקרא" בנוחיות רבה, ללא קשר לכמות הקבצים שעליהם הוא מתפרש. זה גם אומר שאם אני מושך קוד "מלמעלה" וזה דורש ביצוע שינויים - כשאני עושה rebase אני יכול לתקן את ה-commits הישנים שלי (אלו שעוד לא שלחתי למעלה) - במקום להכניס עוד commits חדשים שבהם אני "מתקן את הקוד" - וזה מאפשר לקרוא את ההסטוריה בצורה קלה יותר. בכלל, היכולת לעקוב אחרי ההסטוריה של השינויים היא מאוד נוחה - גם לראות מי שינה מה, גם לראות מתי השתנו דברים (ואם אנשים כתבו הערות commit טובות וביצעו commits קטנים יחסית - גם להבין למה עשו את השינוי). כמות השימוש ב-git-blame ועוד יותר ב-git log -p - גדולה מאוד, ובגלל שזה עובד מאוד מהר - זה מאוד נוח. ולבסוף - זה מאפשר לבצע git-bisect שאמור להקל עלייך למצוא באיזה commit בדיוק נכנס באג מסויים למערכת (זה מאוד עוזר עבור באג מערכתי שהתגלה מאוחר, ומתקשים לדבג אותו בשיטות האחרות).
 
גם בעבודה בתוך הצוות (7-8 מפתחים) git הופך את החיים לנוחים יותר וזורמים יותר מאשר שימוש בכלים אחרים. בזמנו זה גם איפשר לי לקחת את הקוד על DoK הביתה ולעבוד חלק מהימים מהבית (כולל ביצוע commits חדשים) גם בלי חיבור vpn לעבודה. זה משהו כמעט בלתי אפשרי במערכות ניהול גרסאות שאינן מבוזרות.
 
מה שכן - מאוד עוזר אם יש אצלך מישהו שכבר עבד עם git בעבר במקום ש"יודעים מה הם עושים עם git" כדי להחליט על המתודולוגיה של השימוש ב-git - משום ש-git גמיש מדי בשביל שכל עירוב שימושים בו ייתן תוצאה קוהרנטית (למשל, עירבוב לא נכון של merge ו-rebase בין repositories שונים - יחרבש את הקוד לגמרי).
 
לקחת את git ולהשתמש בו כמו svn - מסרס את היתרונות הגדולים שלו.