oh the Irony (קצת ארוך

[TakeCtrl]

אני עומד מאחוריה, שוקל להגיש בג"ץ שיגן על המיעוט..

ניסיתי לעשות גוגל על ניהול בgit ונפלתי על זה...
http://nvie.com/posts/a-successful-git-branching-model/
ואז יש מאמר שסותר אותו
https://barro.github.io/2016/02/a-succesful-git-branching-model-considered-harmful/
וערימה של טוקבקים עם וויכוחים ברמות של להט אנטי merge ואנטי rebase , כאילו זה וויכוחים של check נגד Unchecked exceptions...
שזה כבר סימן לא טוב.
עבודה עם CLI לא באה בחשבון, אני לא עושה דברים פעמיים כולל כתיבת פקודות שחוזרות על עצמם , יש לי שכל בגודל של גרעין אבטיח וcontext switch אצלי נחשב טראומטי, אם באמצע קוד אני צריך לפתוח shell->לכתוב איזשהי פקודה->לוודא שהדיסלקציה/דיקסגרפיה לא דפקה אותה (כמו שתמיד קורה) זה סיבה להשמדה עצמית.
&nbsp
זו הסיבה שאני חולה על plink, צריך להרים/להוריד שרת בlinux? אין בעיה, כותב oneliner יוצר קובץ עם פרמטר שמקבל IP ועוד shortcut עם פרמטר של אותו IP. מעתה והלאה double click and grab your...
כל פעולות git שאני אעשה (הנפוצות) חייבות להיות רק מinterlij, אני מנסה להקים בתור אימון של repo מקומיים שמקושרים למרוחק ומנסה להבין לכל השדים והביטים מה זה אומר checkout with rebase, rebase onto , ומה ההבדל אם אני עושה את זה Remote או local .. מה קורה עם התחלתי ליצור קבצים חדשים לפני שפתחתי branch חדש והאם יהיו לזה תופעות לוואי אם אצור לאחר מכן branch. ומה קורה עם הקבצים שהם כבר commited, והתחלחתי לעבוד עליהם וגם שחכתי לפתוח branch..

 

[BravoMan]

אם תלך לחפש באינטרנט איך נכון לעבוד עם כלי כלשהו (זה ממש לא חייב להיות git), תמיד תמצא דעות סותרות וויכוחים.
&nbsp
שנה מסלול: במקום לחפש מאמרים מסובכים על איך הכי טוב לארגן את ה-git שלך, תחליט מה בדיוק הפונקציונליות שאתה רוצה ש-git ייתן לך, ולך חפש איך משיגים אותה.
&nbsp
כמובן, לרוב תהיה שיטת עבודה מועדפת על יצרן הכלי שיהיה הכי קל לעבוד לפיה.
אבל היות ואף אחד מהמאמרים שמצאת לא נכתב ע"י לינוס, זה לא המקרה לפנינו.

 

[TakeCtrl]

באמת מעניין למה הלינוס לא כתב מאמר בעצמו...

הבנאדם כלי ולא היה לו חזון איך ישתמשו בו?
&nbsp
אנחנו רוצים לעבוד עם git כאילו היה svn, למה? כי מעולם לא רצינו לעבוד עם git, אף אחד אצלנו לא עשה סקירה של אוקי, svn עושה לנו צרות בוא נעבור לgit כי זה כלי שיכול לפתור לנו צרות , לא. מה שקרה שקבוצת הצוותים של המוצר המרכזי עברה לgit ואז החליטו אוקי הם עובדים עם git גם אתם תעבוד כי זה עכשיו כלי חברה, לא חשוב שאף אחד מאיתנו לא ממש מבין איך לעבוד עם הדבר זה, לא חשוב כמה ישיבות עוברים עליו, לא חשוב שמכל מה שאני קורא עד עכשיו עבודה עם הרבה remote branches מרובים לא מומלצת (אם הבנתי נכון, שניהם ממליצים לעבוד פחות או יותר עם אותו remote branch ולעשות עליו push כמה שיותר מהר בשביל CI), רק שאצלנו לא עובדים ככה, אנשים יכולים לעבוד על feature בנפרד במשך חודשיים ולא לעשות שום אינגטרציה ולעשות commit למאות קבצים. ואח"כ לספוג קונפליקטים אפשריים. ולעלות על באגים הרבה אחרי כן כי אין לנו מערכת QA אוטומטית שתרים דגלים.
&nbsp
זה אשכרה מצב dilbert.
&nbsp
בנתיים אני בלחץ כי אני שובר את הראש להבין את הLog של interlij ואיך הוא נראה בכל מצב של merge/rebase ושות', והאם יש הבדל בין יצירת branch לפני או אחרי שאתה עושה pull ואם אתה עושה branch בלי Pull איך זה ישפיע ואיך אתה מתאושש מזה, מה ההבדל בין rebase master ל בין rebase origin/master (ואז אתה מגלה אתה בכלל צריך לעשות fetch לפני כן , כלומר מה, צריך לסכנן גם את origin/master וגם master?)
&nbsp
ואז אתה רואה באדום "rebase deletes merge commits" אתה מבין שזה רק עניין של זמן עד שזה יקרה אצלנו..
&nbsp

 

[BravoMan]

אז מצאת מאמרים שלא מכוונים לדרך בה אתם עובדים

ועכשיו אתה בוכה עליהם?
&nbsp
תהיה רציני רגע - אתה רוצה לעבוד עם git כמו שעבדת עם svn?
אז תעשה את זה. מי מפריע לך?
&nbsp
תעזוב מאמרים, תעזוב CL \ טסטים.
&nbsp
שים repo מרכזי אחד, ושכל מפתח יעשה מולו push ו-pull בלי בראנצ'ים ובלי שטויות.
בדיוק כמו שעשית עם svn.
&nbsp
למען האמת, אני באמת לא מצליח לתפוס אותך מחשבתית:
הודעה אחת אתה מתגאה שאתה לוקח מוצר של חברה אחרת, גדולה ומכובדת, ובלי תיעוד ובלי עזרה עושה לו reverse כדי להבין את המימוש, למצוא באגים, להציע תיקון, ואז עוד מסביר להם למה התיקון שהם עשו הוא בעצם לא טוב.
&nbsp
ובהודעה אחרת אתה אומר שכשביקשו ממך ומצוות המתכנתים שלך לעבור למערכת SC חדשה, פתאום כולכם נעמדתם כמו צבי בפנסי המכונית - כפאתם ונכנסתם לפניקה.
&nbsp
WFT?
&nbsp
הרי כבר אמרתי לך - אתה יכול לעשות ניסיונות ולשחק עם git כמה שאתה רוצה, לתרגל כל דבר אל repo פיקטיבי שתיצור רק לצורך בדיקות.
אתה לא תלוי בשרת שלא בשליטתך. אתה לא תלוי בכלום.
&nbsp
אז למה כל הלחץ? הרי מזה שזרקו עליך מוצר סגור מלא באגים שפתאום שובר ממשק שלכם לא נלחצת?

 

[TakeCtrl]

אממ, אז זהו שלא...

אצלנו בSVN, עשו branch על כל גירסה שעמדו להציא (כלומר היו מחליטים באמצע עבודה על גרסה מסויימת "לחתוך" ולהוצי גרסה מצומצמת ואז להתרכז בגרסה הזו, ככה עבדנו על 2-3-4 גרסאות במקביל) , אבל בגלל שזה SVN, הbranch היה מופרד פיזית מהשני, אם התגלו באגים באחד מהם היית יכול לתקן אותם באחד מהם , ולא לדאוג שזה ישפיע על הbranch אחר איכשהו (באגים היו מתוקנים ידנית, בלי patch שהיה מעביר אותם אחד לשני). כך גם שיכולנו גם לפתוח ולהריץ במחשב אצלנו כמה גרסאות במקביל. עד כמה שידוע לי אין לך את הפריבילגיה הזו כאן, הכל repo אחד, אלא אם כן תעשה clone עבור על repo בנפרד ותעבוד רק מול branch אחד.
&nbsp
משחקים אפשר לשחק בלי סוף (מה אתה חושב שעשיתי היום? , אפילו הוצאתי איזשהי הצעה בעלת 9 צעדים לאנשים), אבל כשאתה צריך גם ממש לכתוב ולשחרר גרסאות באותו זמן, זה כמו ללכת מעבר לצוק ולבנות את הגשר שלך באותו הזמן, הייתי צריך לעזור למישהי היום שהייתה צריכה להוציא גרסה ואיכשהו כל קבצי הפרוייקט התנדפו וIDE ראה קבצים רגילים ולא קבצי מקור , קרוב לוודאי שקבצי פרוייקט לא היו ignored אז git חיסל אותם כשעברת בין branch לbranch.
זה גורם לך לאבד את האמון במה שעד עכשיו לקחת בתור מובן מאליו "למה שקוד יילך לאיבוד אם אני עושה לו commit?" מקסימום אם יש באג, אתה הולך להיסטוריה ומגלה איפה זה השתבש, כי אתה רגיל שהיסטוריה נראית באופן כרונולוגי, אבל לפי מה שאני קורא בgit אפילו גם זה לא כל כך אלמנטרי (זו בדיוק אחת "המריבות" בין rebase ל merge)
תוסיף לזה שאתה צריך עכשיו גם למלא זמנים במערכת ניהול חדשה שיש לה בעצמה מושגים הזויים, וכביומיים האלה אני בעצמי הייתי צריך לעשות משהו "אמיתי" (שאני בעצמי הצעתי ). ... אז כן, יש די לחץ.
&nbsp
&nbsp

 

[BravoMan]

מה לא מופרד לך טוב?

הפרדה פיזית או לא פיזית זה פרט מימוש.
אני מנחש שכשעבדתם עם svn לא הייתם שולפים ידנית את הספרייה שהוא יצר, אלא עושים checkout מסודר ל-branch דרך מערכת הניהול עצמה, ולכן איך היא שומרת בפנים את ה-branch לא היה אמור לעניין אתכם.
&nbsp
קיבלתם בעמדת העבודה ספרייה עם גרסת קוד ספציפית, וזה מה שהיה חשוב לכם.
&nbsp
אני לא רואה שום בעיה לעשות את אותו הדבר ב-git.
&nbsp
אם כל גרסה מופרדת ב-branch משלה, מה הבעיה לבצע checkout של branch שונים לספריות שונות במחשב?
למה שיהיו התנגשויות אם אין צורך למזג את ה-branch האלה?
&nbsp
לא ממש ברור לי גם איך בדיוק git התנקש בקבצים של הגברת שעזרת לה.
נניח הכנסת את קבצי הפרויקט ל-repo. נניח יצרת branch חדש.
&nbsp
הקבצים דיין יהיו שם, אלא אם תלך ידנית ובמכוון להסיר אותם מתוך ה-branch ולעשות commit.
&nbsp
קוד אכן לא יכול ללכת לאיבוד אם אתה עושה commit ב-git.
קוד יכול להיעלם מספריית העבודה שלך אם עשית checkout לגרסה שהוא לא קיים בה.
&nbsp
אבל שוב - זה נכון עבור כל מערכת ניהול גרסאות.
&nbsp
לפי הפסקה האחרונה שלך אני מבין שהבעיה האמתית היא שאתם צוות די מקובע, שלא אוהב להרחיב אופקים ופתאום הפילו עליכם מספר טכנולוגיות חדשות במקביל, ועוד ביקשו לשמור או אפילו להגביר את קצב הפיתוח.
&nbsp
זו בעיה ניהולית, וחבל שאתה מוציא תסכול על כלים שהם סה"כ טובים, בגלל הבעיה הזו.
&nbsp
תראה, תחום הפיתוח הוא דינמי מאוד.
זו לא מנטרה, זה משהו שחוויתי על בשרי!
&nbsp
יש מפתחים שנתקעים עם כלי או טכנולוגיה שנים, אפילו עשורים, ולא מסתכלים בכלל מה יש בעולם, ואז כשמנסים לעדכן אותם הם חוטפים שוק.
&nbsp
זה אומר שהם מפתחים רעים ומוגבלים. זה נשמע לא יפה, ואין בכוונתי לקלל, ייתכן מאוד שמפתח כזה עושה עבודה טובה בכלים שיש לו אבל מתישהו יגיע לזה סוף (והרבה לפני שהמפתח יגיע לגיל פרישה).
&nbsp
לפני 12 שנה התחלתי לעבוד בחברה שהיית כולה "Microsoft shop".
כל המערכות, כל הכלים שעבדנו איתם היו מבית MS. צללנו עמוק בתוך הסביבה הזו ושם היית גם כל המומחיות.
אפילו מנוי MSDN היה לחברה (למרות שזו היית חברה קטנה), וכל כמה חודשים היינו מקבלים עוד ארגז CD עם כל טוב שיש לענקית התוכנה להציע.
&nbsp
ואז ב-2007 באה Apple עם ה-iPhone שלה, ושנה אחרי זה Google הוציא את ה-Android הראשון.
&nbsp
במקביל, ובערך באותו הזמן, Asus פתחו במלחמה עם תחום ה-NetBook מבוססי לינוקס.
&nbsp
Microsoft שנרדמה בשמירה עפה מהר מאוד מתחום המובייל, ומצאנו שכל הכלים שלנו, וכל המומחיות שלנו עפים לפח בקצב מסחרר!
&nbsp
למזלי הרב, הכרתי את תחום ה-Linux כשנה לפני, ומאוד התלהבתי.
זה פתח לי את העיניים והראה לי שיש עולם עשיר ומופלא מחוץ לאקווריום של MS.
&nbsp
כך או כך, כל החברה שלנו היית צריכה לעשות שינוי מסלול חד, להכיר המון כלים חדשים, שפות חדשות, מערכות חדשות, ולהתחיל לצבור מומחיות חדשה ומהר.
&nbsp
או לסגור את הבסטה וללכת הבית.
&nbsp
ועשינו את זה בלי בכי כמו שאני רואה פה.
אישית, אני אפילו נהניתי מאוד מהשינוי.
&nbsp
היום, רוב עמדות הפיתוח בחברה הזו מריצות Ubuntu, והיתר הן Mac, כולם עובדים עם Git (ומרוצים ממנו), הדיסקים של MS הלכו למחזור, ואת המכשירים שלה ניתן לראות במוזאון קטן שארגנו.
&nbsp
המצב אצלך הרבה פחות דרסטי!
בסה"כ נתנו לכם 2 כלים חדשים - אחד לניהול משימות ואחד לניהול קוד.
&nbsp
תסתכל על זה בצורה חיובית, ולדעתי חצי מהבעיות שלך כבר יפתרו!

 

[TakeCtrl]

מה שפתח לי את העיניים מעבר לMS וכניסה לjava היה eclipse

פתאום ראיתי סביבת עבודה שמשתווה לvisual studio ברמת הנוחות והגימור, ואז התחלתי לעבוד עםjava באופן רציני.
&nbsp
ייתכן שאינגרטציה עם interlij עםSVN יותר טובה כך שהיא דואגת מראש להכניס קבצי קופיגורציה לרשימה שחורה. כרגע אני לא בטוח בכלום, אבל זה דוגמא למה שחווים, יש לנו קובץ שפשוט מסרב להעלם לא חשוב כמה עושים לו Push וחייבים לעשות force checkout כל פעם שעוברים גרסה, כל מיני ניג'וסים שאתה אמור לדעת אותם כאילו הם מספרים זוכים בלוטו.
&nbsp
אילו היינו באמת מקובעים היינו נשארים עםjava6 , ולא מעדכנים גרסה , אפילו פעם קיבלתי פעם מייל ממנהל מוצר על מתי אנחנו מכניסים java9 שקצת הכניס אותי לשוק (חיובי, אבל בכל זאת אמרתי לו "תרגיע אח שלו" זה עדיין לא ייצא) ,אבל בjava8 הייתי הראשון לאמץ streams כמה שיכולתי ואני מעיף מדי פעם מבט בjava9 על החידושים שכן יכולים להכנס לשם (מלבד מערכת הmodules שהיום כן היום לא נכנסת תלוי באיזה יום), כגון איך אפשר להכניס flow api במקום מה שיש לנו היום.
&nbsp
יש לנו המון מה לשפר במוצר שלנו, אבל המון, יש שם תשתית שעושה אחד לאחד מה שspring עושה, ואפשר להעיף אותה לגמרי, אפשר להכניס DB במקום להתשתמש בXML, אני בעצמי פיתחתי בצד מעין כלי נוסף שאמרו לשמש עזר לבדיקות, הצוות עצמו מאוד פתוח לשינויים כאלה מצד אחד, מצד שני לא נותנים לנו (ואמרתי את זה כבר בעבר) אפילו להכניס DB, והיינו צריכים לעשות מנגנון ניהול נעילות משלנו בxml. חלק לא קטן מזה תלוי בחוסר בדיקות אוטומציה שיכול לגלות בעיות בשינויים מהר.
&nbsp
לא מזמן אפילו בניתי שרת jenkins מחדש ואת כל דרך הjob שלו שיהיו מבוססי פרמטרים במקום job לכל גרסה עשיתי מעין שרת artifacts לעניים דרך IIS (כי לא היה לי זמן ללמוד איך עושים artifactory) , חפרתי איך בונה סקריפטים בgroovy שיראו קבצי
xml ספציפיים כדי שיוכלו לקרוא לגרסה בשמה האמיתי. ואנשים מרוצים ממנו.
&nbsp
הצוות שלנו הורחב לאחרונה לפיתוח מוצרי מובססי Mobile (גם android וגם eggphone).
&nbsp
אז אנחנו לא כל כך מקובעים כמו שזה נראה, אבל כשמכניסים לך רעש מיותר וזה מיותר כי עד היום לא קיבלנו תשובה במה git טוב לנו יותר מsvn ומדוע זה מקבל עדיפות מאשר דברים אחרים מלבד זה שכל החברה עוברת לשם., אלא ככל שאני חופר יותר ויותר ומהתשובות בפגישות אני מקבל את הרושם, גם הצוותים הגדולים יותר לא בדיוק סגורים על עצמם איך עובדים git ורק לאחרונה שינו מודל עבודה, זה מדאיג, הבנאדם שדיברנו איתו עד עכשיו בחברה שנחשב אחראי לgit אמר שהוא שמח ש"אני נכנס לזה" (והוא לא הראשון) יעני אפשר לחשוב שאני הממשלה... עד עכשיו מלבד פגישות שכוללות עצי גרפים לא נתקלתי בשום פרוצדורה מסודרת של צעד אחד צעד , מלבד זו ששלחתי .. שאלתי אותו מה דעתו על זה אמר לי שנראה לו סבבה.
&nbsp
מה שאירוני (חלק 2), שהמוצר שדיברתי עליו בהתחלה הוא בעצם שכתוב ובנייה מחדש של מוצר קודם שיש להם, וזיהיתי בו את כל הtrend שיש היום, החל מבססי נתונים של BigData , דרך Microservics ,עד לפיתוח של node.js ל web, ו java לbackend ממש cutting edge קרוב לוודאי שיש להם הרבה יותר אוטומציה משלנו, אז הנה חברה פי 10 גדולה משלנו עשה סיבוב 180 ולקחה ערימת צוותים ומתנהגת כמו startup ועדיין צריכים אותנו למצוא להם באגים. זה מצחיק, קרוב לוודאי שעדיין ארביץ להם אם לא אקבל קודם התקפת לב מחוסר ברזל, אבל עדיין מצחיק.

 

[BravoMan]

אז אולי תאהב את האירוניה הבאה:

נתקלתי בלא מעט מפתחים שמקללים את Eclipse, בטענה שיש בו המון באגים וקריסות.
&nbsp
הם דווקא אומרים שהוא לא מגיע לקרסוליים של VS, לא מבחינת יכולות השלמת קוד, ולא מבחינת נוחות השימוש.
&nbsp
אישית, אכן נתקלתי פה ושם בבעיות עם Eclipse אבל גם עם VS, ודווקא די חיבבתי אותו.

 

[TakeCtrl]

תאמין לי אני מבין אותם טוב מאוד... גם אני נתקלתי בזה...

עד כדי כך שבחברה הנוכחית כשעבדו עם Intelij די הייתי בסטרס מהמעבר.. אבל גם אני נתקלתי באותן בעיות, הוא שותה זיכרון באופן היסטרי כגון במקרים של שימוש בGWT הוא קופא באיסוף זיכרון..
אבל בכל זאת, משהו בו גרם לי לקליק, אבא שלי לא מסתדר איתו כל כך, (והוא כותב בבית לpython שהוא מעריץ גדול שלה)
אני כיום עובד עם vs 2013 ומבחינת refactor אין מה להשוות, הrefactor של eclipse (וגם של Intelij גרם לי לעבוד עם קוד כאילו זה database או כאילו עבדתי עם magic).

 

[bismark1]

refactor ב-vs לאיזו שפה?

 

[TakeCtrl]

C#

 

[bismark1]

קצת קשה להשוות בין שפות אבל ככלל אין על jetbrains

הבעיה שהכלים שלהם ממכרים.

 

[ipv6]

אני מאד לא מרוצה מאקליפס

הטענות העיקריות שלי אליו זה:
1. קבצים גדולים - הוא מאד מתקשה עם קבצים ארוכים ונתקע. אני מדבר על 5000 שורות ומעלה, C/C++.
2. הממשק שלו (הגדרות) נוראי, לדעתי. המון תפריטים והמון דברים לקנפג. אני אף פעם לא זוכר וצריך לחפור בגוגל כדי למצוא איפה לשנות את מה שאני צריך.
( על זה נאמר apiwtfness ??)
3. ה-Index שלו לא פשוט לא עובד טוב. המון המון פעמים שהוא נתקע לי במצב שגם אם סוגרים את ה-eclipse ופותחים שוב הוא נתקע באותה הנקודה, ככה שצריך למחוק אותו וליצור מחדש או עוד כל מיני patch-ים שמוצאים באינטרנט שפעם עובד ופעם לא.
זה בעיקר קורה לי אחרי rebase שמשתנים לו הרבה קבצים והוא בונה את האינדקס מחדש.

אני אתאיסט במלחמת הדתות של בעד או נגד מיקרוסופט אבל אני זוכר את VS (אומנם גרסאות ישנות יחסית) כהרבה יותר נח והרבה יותר חלק ומהיר.

 

[TakeCtrl]

נכון, הוא באמת כבד, אם כי קרה לי כמה פעמים גם index של

jetbrains נתקע..
&nbsp
לגבי תפריטים וקינפוגים, פה דווקא הגדולה של perspective, ברגע שהתאזנת, את שומר ומייצא אותה..

 

[TakeCtrl]

לפחות יש את זה...(אם כי ראית את זה בטח)

 

[choo]

למה לא פשוט לפתור את הקונפליקטים?

&nbsp
אתה עושה merge או rebase, מתקן את הקונפליקטים שלך, בודק שמתקמפל וממשיך הלאה.
&nbsp
באופן עקרוני, גיט מעודדת אותך לבצע קומיטים קטנים ומחולקים נכון לוגית. אם תיקון באג יוכנס בקומיט נפרד מהוספת פיצ'ר (כי לוגית אין ביניהם קשר) - תוכל גם לבצע git revert אם התיקון נעשה מיותר.
&nbsp
אתה יכול גם לבצע שיכתוב של ההסטוריה אצלך, לפני שמבצעים push, על ידי שימוש ב-git rebase -i ואז לשנות סדר קומיטים, למזג קומיטים, לערוך אותם וכדומה.
&nbsp
ברור שאתה יכול גם לסבך את עצמך כהוגן, אבל נשאלת השאלה - למה אתה משתמש בגיט אם אתה חושב ש-svn עדיפה לך?

 

[user32]

תשובות

באיזה כלי תשתמש לפתרון הקונפליקטים? שים לב שיש גם כמה מצבים: קונפליקט כי מנסים לעשות Pull לפני שעשו קומיט, או כי מנסים לעשות פול אחרי שעשו קומיט. הבעיה זה בעיקר מעבודה מcli. תהרוג אותי, לא מבין איך אפשר למזג שני קבצים בCLI. אולי אם אתה מאשפי הVI לסוגיו (ואני לא).

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

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

 

[יבגניי34]

git config --global merge.tool bc3

 

[ipv6]

beyond compare עולה כסף

ולא מותקנת by default על כל הפצה.
אפשר באותה מידה לשים meld/tkdiff שלדעתי כן באות עם חלק מההפצות.

 

[choo]

בקיצור אתה בוכה על הבחירות העתידיות שלך

&nbsp
לא רוצה לעשות merge ב-cli? מכיר גוגל? גיט יכול להכניס אותך לכל כלי שאתה אוהב לבצע איתו merge גרפי. לא כזה קשה.
&nbsp
לגבי האלגוריתמאי שלא יודע לעבוד - למיטב זכרוני, לסדר דבר רוחבי כזה ידרוש עבודה שחורה של תיקוני קונפליקטים בכל כלי בקרת תצורה סטנדרטי (גם svn ו-cvs), מהסיבה הפשוטה - בכולם תיקון הקונפליקטים בנוי מעל ל-context diff - ולכן אם יש קונפליקט - זה יקרה בכל תוכנה מקובלת.
&nbsp
אלא מה - יש תוכנות שמנסות לעשות לך את ה-merge באופן אוטומטי. בפועל זה עובד, עד שזה לא עובד (אתה מקבל merge שגוי בצורה שקטה וכלל לא יודע שהיתה בעיה - ומגלה את זה או בצורה של שגיאת קומפילציה - במקרה הטוב - או בצורה של שגיאת ריצה לא ברורה - במקרה הרע).
&nbsp
ואגב, ב-pull אין שום קונפליקט - זה משנה רק את התוכן של העותק של ה-remote branch אצלך - זה לא משנה את הבראנצ'ים שבהם אתה עובד בפועל. אם אתה מתעקש לבצע "קיצורי דרך" שמפריעים לך - אתה יכול פשוט לבחור לא לעשות קיצורי דרך כאלו. אצלי הקונפליקטים תמיד מגיעים רק כשאני בוחר לבצע merge או rebase לבראנץ' המקומי שלי, ואני לא רואה שום סיבה *טובה* לעבוד בצורה אחרת. את האחריות לתיקון הקונפליקטים משאירים למפתחים, ולא למישהו מרכזי - ואז גם אנשים לומדים יותר לעבוד עם הקוד של אנשים אחרים, וגם זה מעודד אנשים לבצע שינויים קטנים במקום שינויי ענק. בעבר (לפני מספר שנים) עבדנו בצוות בצורה שבה מנהל ה-repo מבצע מיזוגים בין הגרסאות השונות בעצמו. הפסקנו עם זה והאחריות עברה למפתחים.