oh the Irony (קצת ארוך

[TakeCtrl]

פה אני לא סגור שהבנתי כל כך..

כי קשה לי מאוד להבין את הכיוונים בפקודות, במיוחד בinterlij שם כשאתה יושב על branch (כלומר מה שעשית עליו checkout) ואתה עושה "rebase onto origin/master" זה נשמע כאילו אתה משנה את origin/master, כשבפועל (אם אני מבין נכון) את מביא את כל העידכונים מmaster אליך ובהנחה שאין קונפליקטים, מתחיל להפעיל את הקומיטים שלך מהרגע האחרון (אני מניח) שעשית merge/rebase/הסתרכנת עם master.
&nbsp
יש אצלנו אחד שנתקל די הרבה פעמים בבעיות של shelve כי הוא צריך לעבור בין ענף לענף בלי שהספיק לעשות commit ואז כל השינויים שלו "נעלמים" שזה מאוד מלחיץ ..
&nbsp

 

[TakeCtrl]

מה שחסר לי במיוחד זה לראות בפועל את הבדל בהיסטוריה

בצורה אמיתית (ולא כל מיני ציורים משונים) בין rebase לבין merge.

 

[choo]

rebase מהווה שיכתוב ההסטוריה. merge לא

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

 

[TakeCtrl]

האם יכול להיות שID של אותו commit יהיה ב2 branch ?

כשאתה אומר ישלב קומיטים זה אומר ממש מעתיק אותם קומיטים אם אותו ID
&nbsp
ומה קרוה כאשר בזמן הrebase יש קונפליקט בין branch A (שלי) לבין branchB (נגידMASTER) אני מניח שהוא ייצור קומיט merge חדש ,האם הוא יכניס אותו אחרון לאחר שהוא ניגן כבר את כל הקומיטים הקודמים שלי?
אגב, האם מה שקראת קומיט של merge באמת נקרא רשמית merge commit, כלומר commit שנוצר רק כאשר פותרים קונפליקטים? כי עדיין מדאיג אותי מה שקראתי ש rebase משמיד merge commits.
&nbsp
&nbsp
&nbsp
הקטע פה שאני לא סגור איך כל ההיסטוריה הזו בנוייה או מוצגת, כי בsvn סה"כ היית רואה היסטוריה לינארית, סידרה של קבצים ששונו עם איזה שינויים שהיו לפני כן. כאן עושים עניין גדול מאיך שrebase ו Merge גורמים לזה להראות אחרת , כאשר הmerge הקלאסי מוצג בהיסטוריה של branch שלך עם היסטוריה שלקוחה מbranch של master, ואילו בrebase זה מוצג כאילו אתה עשית את השינוי שנעשה בmaster (כאילו הסתכלת בmaster ידנית השווית בין הקבצים ועשית copy pasta ואז commit ואז נראה בbranch שהנוסחה המבריקה שמישהו חשב עליה בmaster נכתבה על ידך בעצם, כרגע אני סתם מנחש ממה שקראתי עד כה).
ואז נגיד שאחרי הrebase שינית בקטנה את אותו הקובץ עם push.
ואז כשחזרת לmaster ואתה עושה הפעם Merge, (שוב לאותו קובץ עם הנוסחה) מה אמור לקרות? הרי הקובץ שונה בbranch שלך, ע"י קומיט "חדש" שלא מופיע בmaster איך זה ייראה?
&nbsp
&nbsp

 

[choo]

בזמן ריבייס, אתה מתקן כל קומיט בנפרד

&nbsp
גיט מנגן את הקומיט הראשון שלך מעל לתוכן של המאסטר. אם יש קונפליקט, הוא עוצר ומאפשר לך לתקן את הקומיט. התיקון נכנס לתוך העותק החדש של הקומיט הזה. אז אתה עושה rebase --continue וזה ממשיך ככה עם כל קומיט נוסף. לא ייוצר אף merge commit - משום שאתה מתקן (=משכתב) כל קומיט *שלך* בנפרד.
&nbsp
מעבר לזה, ריבייס *לא נוגע* בקומיטים שהיו כבר למעלה בבראנץ' שאליו אתה עושה ריבייס.
&nbsp
לגבי merge - אכן נוצא קומיט חדש אחד בלבד שבו מתוקנים כל הקונפליקטים בין כל הקומיטים שנכנסים למרג', והוא יופיע בשם merge commit בפלט של git log
&nbsp
לגבי המקרה שתארת פה - לא הצלחתי להבין מה בדיוק סדר הפעולות שתאה מתאר (נתת שתי אפשרויות שונות ואז הוספת כמה פעולות נוספות - ולא ברור לאלו משתי האפשרויות התכוונת). אנא הסבר שוב.

 

[TakeCtrl]

כמו שפירטתי מקודם רק עם תוספת קטנה (סעיף 2.2)

&nbsp
1. ליצור branch לכל feature (כולל remote, כי יכולים לעבוד על זה חודשים)
2. לעשות fetch, ולאחר מכן מכן rebase עם הmaster בremote
2.2 לשנות קובץ ולעשות commit push
3. אחרי שהעסק עובד לעשות checkout לorigin/master
4. לעשות הפעם merge עם הbranch המרוחק
5. לוודא שוב שזה עובד ואז push
&nbsp
איך ההיסטוריה תיראה? בעיקרון אני מנסה לחשוב על מצבים שמתכנתים (כמו שתמיד יקרה) ישכחו/לא יעשו את כל סדר הפעולות.

 

[choo]

קח את מה שרשמתי - וחבר את הדברים

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

 

[selalerer]

רק ככה הערה צידית לדיון שלכם: מעולם לא טרחתי לעשות rebase.

עבדתי על branch, כשסיימתי עשיתי pull ל-master בכדי לקבל את הקוד האחרון ואז עשיתי merge מה-branch ל-master. אם היו קונפליקטים הייתי מטפל בהם ידנית, מריץ בדיקות ועושה push ל-master.
&nbsp
אני לא ממש רואה איך rebase פה חוסך לך את העבודה, הרי תיתקל באותם קונפליקטים שתיתקל בהם ב-merge.

 

[TakeCtrl]

ה-rebase מעולם לא נועד לחסוך לי עבודה... זה בגלל ההיסטוריה..

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

 

[TakeCtrl]

אחראי git = פרופסור devops? כי נראה לי בהתחשב בעובדה

שאני שזה שבניתי את שרת הjenkins שלנו וירקתי דם בלנסות ערימת Plugins כדי לשלוף מgit , לעשות Jobs לפי פרמטרים , ואז הקמתי IIS רק כדי לשמור artifacts התפקיד המלהיב הזה ייפול עלי ...
ואם יש משהו שאני מסריח בו זה עבודה שחוזרת על עצמה...כמו שאני עומד לבנות סוללה לאופניים החשמליים שלי וכמות המחקר והציוד שאני משקיע בנושא (קונה רתכות שונות, מזמין BMS לפי פרמטרים, הרכבת CNC ) גורמת לבוני סוללות מסויימים עצבנות כאילו אני עומד להיות תחרות עבורם, גם כאן אני כל הזמן אנסה לחפש כלים וחידושים לייעל את הנושא. ברגע שראיתי מספר מאמרים סותרים על זרימת עבודה בgit האינסטינקט שלי אמר שבטוח שיש כלים לזה , לכן ניסיתי ללכת ישירות על gitflow כי יש לו Plugins ל jetbrains (נפסל כי הוא מכריח אותך ליצור origin/develop), הצרה היא אני לא מכיר כל כך הרבה כלי flow לעבוד איתו (ועוד פחות שעושים אינגרציה עם IDE וזה מאוד חשוב לי).

 

[user32]

למה לא השתמשת בArtifactory?

במקום IIS ששומר artifacts. מוצר אופן סורס מעולה וגאווה ישראלית ונתנייתית בפרט

 

[TakeCtrl]

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

אחרי כל הבלגן שחוויתי בהקמת jenkins חדש , במיוחד שזה לא היה משהו רשמי במיוחד הייתי די בלחץ (האמת, כל דבר שהוא devops אצלנו לא בדיוק נחשב משימה רשמית עם תקציב, בישיבת סטטוס שבועית אמרתי לאנשים שהם יכולים לרפד כל משימה שלי פי 2.5 על הזמן שאני אשרוף בלסייע לאנשים בGIT , לא בטוח שלקחו אותי ברצינות..).
אילו הייתי אני בעבודה הקודמת קרוב לוודאי שהייתי בוחר לעשות את הדבר "הנכון" מתעכב יותר וחוטף צעקות על "מה אני מתעסק בשטויות במקום לעבוד" מאז למדתי להוריד את הראש

 

[choo]

יש אצלנו צוות שמשתמש ב-bitbucket בתור פרונטאנד לגיט

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

 

[TakeCtrl]

הgit שלנו נמצא כרגע בשרת

gitlab יש לו מאמר משלו על flow...

 

[יבגניי34]

BTW this gem is a must read for anyone using git

http://stevelosh.com/blog/2013/04/git-koans/

 

[BravoMan]

איפה בדיוק האירוניה פה?

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

 

[TakeCtrl]

האמת, (ושוב הקטע של תשקורת בולט) ממש לא באתי להגיד

שאני מקצוען, די הפוך ,כי אנשים אצלנו בעבר אמרו לנו שהמתכנים שם ברמה מאוד נמוכה. ואתה רואה לפעמים גם בהתנהלות שלהם וגם בעובדה שלא כל כך היינו צריכים להתאמץ למצוא אצלם באגים, אני מדבר אפילו עם מקרים של יום יומיים אחרי שקיבלנו מהם מוצר ... והם די יודעים את זה כי הם התחילו להגיע אלינו בבקשות של לנסות דברים אחרים במוצר שלא קשורים ישירות למה שאנחנו עושים וכולם יודעים שהם פשוט רוצים להתחלק על הזקן שלנו.
מקרים אחרים הייתי צריך ממש להגיש להם קוד הכי מינימלי אפילו אחרי שהצגתי פירוט צעד אחר צעד כדי להוכיח משהו ואז כשאמרו שפתרו את זה פשוט הגדלתי delay בשנייה אחת והראתי שלא (וכל הקוד והבעיה היו מבוססים על השהייה מסויימת) אני לא חושב שזה הופך אותי למקצוען במיוחד. וגם היום אם היו שואלים אותי אותם שאלות באותו ראיון בטוח שהייתי קורס לא חשוב כמה ניסיון הצטבר לי מאז (ואותו ראיון לא היה הראשון שלי)
ובגלל כל זה העסק נראה לי די הזוי ואירוני כי מחברה כזו הייתי מצפה למשהו הרבה יותר חלק.
&nbsp
וכמו שאמרתי גם אני מסכים עם User, אכן פסלתי את עצמי ואם להגיד שאני לא יודע סיבוכיות פוסל אותי so be it. אני לא חשוב שאי פעם אגיע לרמה כזו. יש לי brain freeze בתחומים מסויימים.
&nbsp
האמת, לגבי ראיון ראשון אני לא יודע איך הייתי מתנהג, מבחינתי העסק זה של פיתוח התחיל די במקרה בצבא, כמעט בטעות ושם עבדתי רק בדבר אחד בלבד, לכן בראיון הראשון שלי קפצתי על העבודה הראשונה ואפילו שהשכר היה 5000 , כי פשוט שמחתי שיש לי אחת כזו, נשארתי שם בערך 8-9 שנים, כשהשכר גדל ל9000. אצלי לעבור עבודה דורש משהו די טראומתי.

 

[choo]

אתה מתגאה בבורותך כמו שמירי רגב מתגאה שלא קראה צ'כוב

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

 

[Lhuna1]

"לא חושב שאי פעם אגיע לרמה כזו"

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

 

[AnarchistPhilosopher]

מה כ"כ קשה ב"מדע טילים"?

&nbsp