oh the Irony (קצת ארוך

[ipv6]

ניתן לעשות git reset לקובץ בודד

תקבל את הקובץ הזה באיזו גרסה שאתה רוצה.
https://www.atlassian.com/git/tutorials/resetting-checking-out-and-reverting

 

[יבגניי34]

התשובה לצרות שלך פשוטה, זריזה, 2 אותיות ויש כוכב על שמה.

 

[selalerer]

יש דבר אחד נורא ב-git: התיעוד.

במקום להסביר לך את השימוש בכלי במובנים של מה אתה רוצה לעשות הוא מסביר לך מה הכלי עושה פנימית, אלגוריתמים ומתמטיקה. מגוחך.
&nbsp
מצד שני, google פתוח ותשובות לרוב ב-stack overflow דיי מסדרות אותך. עם הנסיון גם לומדים לסנן את התשובות של כל הנודניקים שמדברים באותה השפה של התיעוד ולהשתמש רק בפעולות פשוטות שעובדות.
&nbsp
באמת תמיד השתמשתי ב-command line ואישית אני מעדיף את זה. אני אף לא סומך על pluginים של IDE שלא יפשלו. גם ב-svn לא הייתי מתקין plugin ל-IDE ובד"כ משתמש ב-tortoise (שאני מניח שזה כמו ה-command line של Windows

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

 

[choo]

יש למבנה התעוד סיבה טובה - הבנה של האינטרנלז תעזור לך להשתמש

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

 

[selalerer]

לא רוצה מדריך למשתמש, רוצה user friendly reference

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

 

[user32]

 

[יבגניי34]

סליחה ידידי למה לא פשוט לאמר שלגיט יש api גרוע?

ה"וויכוח" הזה משול לדיון האם השמש זורחת במערב אם לאו.
לגיט יש api נוראי, לא קונסיסטנטי, שלא תוכנן לעולם המודרני. והתיעוד שלו - גרוע.

פתח SO קרא שאלות נפוצות על גיט. מפתחים מנוסים מתקשים לבצע את הפעולות הטריוויליות ביותר. ראה שירשור זה כהוכחה. אין לזה שום הצדקה מלבד שהכלי הזה לא תוכנן ל״טיפשות ההמונים״.

hg כן תוכנן לעולם המודרני, ולכן לכל צוות שאין לו סיבה מהותית לעבוד עם גיט, אני תמיד אמליץ לעבוד עם hg.

 

[TakeCtrl]

מה שמצחיק זה כלי שנוצר לאחרונה לכן זה עוד יותר גרוע

שזה "לא תוכנן" לעולם המודרני ..

 

[ipv6]

SO זאת קרקע פוריה ל"חפירות"

הרבה שאלות פשוטות מקבלות שם מענה ארוך ומפורט, *זה* לאו דווקא מעיד על תיעוד\מנשק רע.

https://stackoverflow.com/questions...-an-item-given-a-list-containing-it-in-python

גם list פיית'וני זה לא אובייקט ידידותי? התיעוד שלו גרוע?

 

[יבגניי34]

דומני שלא הבנת על מה מדובר

https://stackoverflow.com/questions/tagged/mercurial

diff

https://stackoverflow.com/questions/tagged/git

diff

https://stackoverflow.com/questions/tagged/python

Now *that* is a fine measure of the apiwtfness of a tool.

 

[ipv6]

קישרת לשאלות ה&חדשות& ביותר ב3 הנושאים.

בהודעה הקודמת דיברת על הנפוצות.
ואשמח אם תסביר מה הראת בדיוק עם הלינקים וה-diffים שלך.
שהשאלות על Git הרבה יותר פשוט מהשאלות על HG\פיית'ון? זה לא ממש נראה ככה.
השאלות על HG ו-GIT יחסית דומות במורכבות.
אחת התשובות הכי נפוצות על HG היא מדריך מפורט למתחיל. לשיטתך, אם HG כל כך פשוטה, למה צריך הודעה כל ארוכה ב-SO שתסביר איך להשתשמש?

אני מסכים שאיתך שהתיעוד הוא רע אבל לא חושב שSO שכמות שאלות ב-SO זה מדד כלשהוא.

 

[user32]

 

[user32]

גיט זה כלי עזר. אמצעי, לא מטרה

שאני לא אשמע כמו המתכנת השטחי הזה שלא מתעמק בעבודה שלו, אבל עם כל הכבוד, גיט נועד לעזור לי לנהל גרסאות ולסנכרן בין המפתחים. אני לא רוצה ללמוד את הinternals שלו כמו שאני לא לומד את הקוד של הIDE שאני משתמש בו, ולא את המימושים של npm, maven, ואפילו וירטואליזציה של מכונות אני יודע מאוד במעורפל איך זה עובד מאחורי הקלעים.

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

 

[TakeCtrl]

git זה כלי מחורבן , נקודה...

הבנתי את זה עוד מהתיאור הראשוני שלו ולכן לא רציתי להכנס אליו ...
&nbsp
השימוש דומה לשימוש של אדמינים של linux (ורואים מאיפה זה מגיע) כיום git מונע מאיתנו לשחרר גרסה בגלל שקובץ אחד יש בupper lower case,ולא חשוב כמה תתאמץ הקובץ הזה נשאר, וrebase נופל, ועכשיו אתה צריך לחפור ולהבין איך את עושה rebase בלי commit אחד (שבכלל מוחק לך קובץ) ועוד יותר גרוע שאתה מתקשה להסביר לאחרים מה הבעיה.

 

[יבגניי34]

לא. זה כלי מעולה שאף אחד בחברה שלך לא טרח ללמוד ולחשוב עליו

לדוגמה, בעבודה משותפת על fs שיש להן גישה שונה ל case sensitivity, אפשר לשקול לשים core.ignorecase=true ב gitattributes.

אצלך לא עשו את זה, ולא חשבו על זה, וזה לא כשלון של גיט אלא של מקום העבודה ה״מחורבן״ שלך.

 

[TakeCtrl]

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

(פשרה)..

מה נראה לך שאין בעיות של case senstive בsvn? שם לפחות קל לפתור... ב.git יש לי commit מחורבן שתקוע לי כמו עצם בגרון שאני צריך לחפור בSO כדי להבין איך אני מדלג מעליו... עם Reset או rebase אינטרקטיבי... לפחות עכשיו שלב אחד השולם בmerge.. עכשיו הcommit הנ"ל תקוע בbranch המקומי.. וצריך לדגל מעליו כדי להעביר אותו לbranch ..
&nbsp
וכן, אתה צודק בקשר לחשיבה מראש..
&nbsp
ותודה שהזכרת לי אני צריך לשנות את ignore case חזרה לברירת מחדל שלו בתחנה שעבדתי עליה קודם

 

[ipv6]

אתה צודק

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

אולי לא תבין את כל מה שקורה מתחת לרגליים אבל זה לא באמת נדרש..

 

[user32]

מסכים

התחלתי כבר להתלבש על הנושא יותר ברצינות.

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

 

[TakeCtrl]

*בדיוק* מה שקורה אצלי עכשיו..

אתמול טחנתי עם המתכנתת על למה git מסרב לעשות rebase בגלל אותו קובץ דפוק. (עד שהצלחתי לגרום לו לדלג על הזבל, והיום יש לי מסע הרפתקאות על עושים rebase בvisual studio 2013 כי, אעפס הגרסה הזו לא תומכת...
&nbsp
בגדול הנוהל שהמלצתי לעשות עם git
1. ליצור branch לכל feature (כולל remote, כי יכולים לעבוד על זה חודשים)
2. לעשות fetch, ולאחר מכן מכן rebase עם הmaster בremote
3. אחרי שהעסק עובד לעשות checkout לorigin/master
4. לעשות הפעם merge עם הbranch המרוחק
5. לוודא שוב שזה עובד ואז push
&nbsp
מלבד העובדה שrebase יכול להיות בעייתי עם הbranch משותף, קרוב לוודאי שיש ויהיו הרבה בעיות עם מה שאמרתי ...בגדול הלכתי חלקית לפי זה..
(https://www.derekgourlay.com/blog/git-when-to-merge-vs-when-to-rebase/)
&nbsp
אבל אין לי זמן להתעמק עם זה, אני צריך לתלוש מהפרוייקט שלנו איזה embedded tomcat מעצבן ולהשתמש במקומו בwebserver של com.sun, זה + jax annotation צריך לספק כל מה שצריכים(רעיון שלי) , נמאס לי שמקבלים תלונות על בעיות security רק בגלל שסורקים את tomcat ונכנסים ללחץ מבעיות גרסה שלו (משהו לגבי Protocol ejp שבכלל לא מופעל אצלנו) . וגם בגדול זה overkill למשהו שסה"כ צריך לספק העברת קבצים בhttp

 

[ipv6]

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

אני אישית עובד טיפ טיפה שונה.
כשאני מסיים פיצ'ר אני עושה rebase -i מעל הברנץ' שאני הולך לדחוף אליו ומקבץ את כל הקומיטים שלי לקומיט בודד (על ידי fixup בזמן ה-rebase)
אחר כך אני דוחף את הקומיט הבודד הזה הזה לברנץ' המרוחק.

git fetch origin
git rebase -i origin/ipv6-branch
git push origin HEAD:ipv6-branch

ipv6-branch is my remote branch. Obviously it can be "master" branch.