תחילת העבודה עם Git: מדריך מפורט למתחילים

במקום הקדמה

שלום מהנדס תוכנה בכיר לעתיד. היום נדבר על מערכת בקרת הגרסאות, כלומר Git (נקרא כ-GIT, ולא JIT, כפי שזה עשוי להיראות מהדקדוק האנגלי). כן, כן, אני יודע שיש גם Mercurial, SVN... אבל בואו נהיה כנים: הזמן שלהם כבר עבר, ואני לא מתכוון לבזבז עליהם את זמנכם היקר. כדי שתבינו את החשיבות של הכרת Git בזמננו, אני אגיד כך: בלי ידע/הבנה של זה, אין לכם מה לעשות בתכנות. אבל היופי הוא שכדי לעבוד כל הזמן אתה לא צריך לשמור את כל הפקודות והאפשרויות בראש. אתה צריך לדעת סט פקודות שיעזור לך להבין כל מה שקורה.

Git Basics

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

התקנת Git

בוא נתקין את Git במחשב שלך. אני מבין שלכל אחד יש מערכת הפעלה שונה, אז אני אנסה לתאר עבור כמה מקרים.

התקנה עבור Windows

כרגיל, עליך להוריד את קובץ ה-exe ולהפעיל אותו. הכל פשוט כאן: לחץ על הקישור הראשון של גוגל , התקן וזהו. לעבודה נשתמש בקונסולת bash שהם מספקים. כדי לעבוד על Windows, אתה צריך להפעיל את Git Bash. כך זה נראה בתפריט ההתחלה: וזו כבר קונסולה שאפשר לעבוד בה. כדי לא ללכת לתיקיה עם הפרוייקט בכל פעם לפתוח שם git, אפשר ללחוץ לחיצה ימנית בתיקייה כדי לפתוח את המסוף עם הנתיב שאנחנו צריכים:

התקנה עבור לינוקס

בדרך כלל git כבר מותקן ונכלל בהפצות לינוקס, מכיוון שזהו כלי שנכתב במקור לפיתוח ליבת לינוקס. אבל יש מצבים שזה לא שם. כדי לבדוק זאת, עליך לפתוח מסוף ולהקליד: git --version. אם יש תשובה ברורה, אין צורך להתקין כלום. פתח מסוף והתקן. אני עובד על אובונטו, אז אני יכול להגיד לך מה לכתוב עבורו: sudo apt-get install git. וזהו: עכשיו אתה יכול להשתמש ב-Git בכל מסוף.

התקנה על macOS

גם כאן, קודם כל צריך לבדוק אם Git כבר קיים (ראה למעלה, כמו בלינוקס). אם לא, הדרך הקלה ביותר היא להוריד את הגרסה העדכנית ביותר. אם XCode מותקן, Git בהחלט יותקן אוטומטית.

הגדרת Git

ל-git יש הגדרת משתמש שממנה תתבצע העבודה. זה דבר סביר והכרחי, כי כאשר נוצר commit, Git לוקח בדיוק את המידע הזה עבור שדה Author. כדי להגדיר שם משתמש וסיסמה לכל הפרויקטים, עליך להזין את הפקודות הבאות:

git config --global user.name ”Ivan Ivanov”
git config --global user.email ivan.ivanov@gmail.com

אם יש צורך לשנות את המחבר עבור פרויקט ספציפי (לפרויקט אישי, למשל), אתה יכול להסיר --global, וזה יעבוד:

git config user.name ”Ivan Ivanov”
git config user.email ivan.ivanov@gmail.com

קצת תיאוריה...

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

• מאגר git;
• להתחייב (להתחייב);
• ענף;
• לְמַזֵג;
• קונפליקטים;
• מְשׁוֹך;
• לִדחוֹף;
• כיצד להתעלם מקבצים מסוימים (.gitignore).

וכולי.

מדינות ב-Git

לגיטה יש כמה מצבים שצריך להבין ולזכור:

• ללא מעקב;
• שונה;
• מוכן (מבוים);
• מְחוּיָב.

מה זה אומר?

אלו הם המצבים שבהם נמצאים הקבצים מהקוד שלנו. כלומר, מסלול החיים שלהם נראה בדרך כלל כך:

1. קובץ שנוצר ולא נוסף למאגר יהיה במצב ללא מעקב.
2. אנו עורכים שינויים בקבצים שכבר נוספו למאגר Git - הם במצב שונה.
3. מתוך הקבצים ששינינו, אנו בוחרים רק את אלו (או את כולם) שאנו צריכים (לדוגמה, איננו צריכים מחלקות קומפילציה), והמחלקות הללו עם שינויים נכנסות למצב המבויים.
4. commit נוצר מהקבצים המוכנים מהמצב המבויים ונכנס למאגר Git. לאחר מכן, המצב המבויים ריק. אבל השינוי עשוי עדיין להכיל משהו.

זה נראה כך (תמונה מהמסמך הרשמי, אז אתה יכול לסמוך עליה)):

מהי התחייבות

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

• מזהה התחייבות ייחודי שבאמצעותו תוכל למצוא אותו;
• שם המחבר שיצר אותו;
• תאריך יצירת התחייבות;
• הערה שמתארת ​​את מה שנעשה במהלך ההתחייבות הזו.

כך זה נראה:

מה זה סניף

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

תחילת העבודה עם Git

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

עבודה עם Git במאגר מקומי

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

git init

פעולה זו תיצור תיקיית ‎.git במיקום שבו ממוקמת המסוף. .git היא תיקיה שמאחסנת את כל המידע על מאגר Git. אין צורך למחוק אותו ;) לאחר מכן, קבצים מתווספים לפרויקט זה, והסטטוס שלהם הופך ללא מעקב. כדי לראות מה מצב העבודה הנוכחי, כתוב:

git status

אנחנו בסניף המאסטר, ועד שנעבור למשנהו, הכל יישאר כך. כך תוכלו לראות אילו קבצים שונו אך עדיין לא נוספו למצב המבויים. כדי להוסיף אותם למצב המבוים, עליך לכתוב git add. עשויות להיות כאן מספר אפשרויות, למשל:

• git add -A - הוסף את כל הקבצים מהמצב המבוים;
• git add . - הוסף את כל הקבצים מהתיקייה הזו ואת כל הקבצים הפנימיים. בעצם זהה לקודם;
• git add <שם קובץ> - מוסיף רק קובץ ספציפי. כאן אתה יכול להשתמש בביטויים רגולריים כדי להוסיף לפי תבנית כלשהי. לדוגמה, git add *.java: זה אומר שאתה צריך להוסיף רק קבצים עם סיומת java.

ברור ששתי האפשרויות הראשונות פשוטות, אבל עם התוספת זה יהיה יותר מעניין, אז אנחנו כותבים:

git add *.txt

כדי לבדוק את המצב, אנו משתמשים בפקודה שאנו כבר מכירים:

git status

מכאן אנו יכולים לראות שהביטוי הרגולרי עבד כהלכה, וכעת test_resource.txt נמצא במצב מבוים. ולבסוף, השלב האחרון (עם מאגר מקומי, עם מרוחק יהיה אחד נוסף ;)) - commit ויצירת commit חדש:

git commit -m “all txt files were added to the project”

לאחר מכן, ישנה פקודה מצוינת להסתכל על היסטוריית המחויבות של סניף. בואו נשתמש בו:

git log

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

git status

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

git status

כאן אתה יכול לראות בבירור את ההבדל בין שני המצבים - ללא מעקב ושונה. GitTest.java נמצא במצב ללא מעקב ו-test_resource.txt במצב שונה. כעת, כאשר יש כבר קבצים במצב שונה, אנו יכולים להסתכל על השינויים שבוצעו בהם. ניתן לעשות זאת באמצעות הפקודה:

git diff

כלומר, אתה יכול לראות כאן בבירור שהוספתי את Hello World! לקובץ הטקסט שלנו. הוסף שינויים לקובץ הטקסט ובצע:

git add test_resource.txt
git commit -m “added hello word! to test_resource.txt”

כדי להסתכל על כל ההתחייבויות, כתוב:

git log

כפי שאתה יכול לראות, יש כבר שני התחייבויות. באותו אופן אנו מוסיפים GitTest.java. עכשיו אין הערות, רק פקודות:

git add GitTest.java
git commit -m “added GitTest.java”
git status

עבודה עם .gitignore

ברור שאנחנו רוצים לאחסן רק את קוד המקור ולא שום דבר אחר במאגר. מה עוד יכול להיות? לכל הפחות, מחלקות ו/או קבצים הידור היוצרים סביבות פיתוח. כדי ש-Git יתעלם מהם, יש קובץ מיוחד שצריך ליצור. אנו עושים זאת: אנו יוצרים קובץ בשורש הפרויקט בשם .gitignore, ובקובץ זה כל שורה תהיה דפוס להתעלם ממנו. בדוגמה זו, git ignore ייראה כך:

```
*.class
target/
*.iml
.idea/
```

בואו נסתכל עכשיו:

• השורה הראשונה היא להתעלם מכל הקבצים עם סיומת .class;
• השורה השנייה היא להתעלם מתיקיית היעד וכל מה שהיא מכילה;
• השורה השלישית היא להתעלם מכל הקבצים עם סיומת .iml;
• השורה הרביעית היא להתעלם מתיקיית .idea.

בואו ננסה את זה עם דוגמה. כדי לראות איך זה עובד, הוסף את המחלקה GitTest.class המהידור לפרויקט וראה את סטטוס הפרויקט:

git status

ברור שאנחנו לא רוצים בטעות (אם אנחנו משתמשים ב-git add -A) להוסיף מחלקה מהודרת לפרויקט. כדי לעשות זאת, צור קובץ .gitignore והוסף את כל מה שתואר קודם לכן: עכשיו בואו נוסיף git ignore לפרויקט עם commit חדש:

git add .gitignore
git commit -m “added .gitignore file”

ועכשיו רגע האמת: יש לנו מחלקה מהידור GitTest.class במצב לא מעקב, שלא רצינו להוסיף למאגר Git. זה המקום שבו git ignore אמור לעבוד:

git status

הכל ברור) תתעלם +1)

עבודה עם סניפים וכדומה

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

git branch -a

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

• ליצור סניף חדש על סמך זה שאנחנו נמצאים בו (99% מהמקרים);
• ליצור סניף על סמך מחויבות ספציפית (1%).

צור סניף על סמך התחייבות ספציפית

אנו נסתמך על מזהה ההתחייבות הייחודי. כדי למצוא אותו, אנו כותבים:

git log

הדגשתי את ההתחייבות עם התגובה "הוספת שלום עולם...". יש לזה מזהה ייחודי - "6c44e53d06228f888f2f454d3cb8c1c976dd73f8". אני רוצה ליצור ענף פיתוח החל מההתחייבות הזו. בשביל זה אכתוב:

git checkout -b development 6c44e53d06228f888f2f454d3cb8c1c976dd73f8

נוצר סניף שמכיל רק את שני ה-commits הראשונים מהענף הראשי. כדי לבדוק זאת, קודם כל נוודא שעברנו לסניף אחר ונבדוק את מספר ההתחייבויות עליו:

git status
git log

וזה נכון: התברר שיש לנו שני מחויבים. אגב, נקודה מעניינת: עדיין אין קובץ .gitignore בענף הזה, אז הקובץ הקומפילד שלנו (GitTest.class) מודגש כעת במצב הבלתי מעקב. כעת נוכל לשנות את הסניפים שלנו שוב על ידי כתיבה:

git branch -a

ניתן לראות שיש שני ענפים - מאסטר ופיתוח - ועכשיו אנחנו בפיתוח.

צור סניף על סמך הענף הנוכחי

הדרך השנייה ליצור ענף היא לבנות על אחר. אני רוצה ליצור סניף המבוסס על ענף המאסטר, אז אני צריך לעבור אליו קודם, והשלב הבא הוא ליצור אחד חדש. בואו נראה:

• git checkout master - מעבר לסניף המאסטר;
• סטטוס git - בדוק אם הוא נמצא במאסטר.

כאן אתה יכול לראות שעברנו לסניף המאסטר, git ignore כבר עובד כאן, והמחלקה הקומפילית כבר לא מופיעה כבלתי מועברת. כעת אנו יוצרים סניף חדש המבוסס על ענף המאסטר:

git checkout -b feature/update-txt-files

אם יש לך ספק שהענף הזה לא יהיה זהה למאסטר, אתה יכול לבדוק זאת בקלות על ידי כתיבת git log והסתכלות על כל ה-commits. צריכים להיות ארבעה מהם.

לפתור קונפליקטים

לפני שנבין מהו קונפליקט, עלינו לדבר על מיזוג (מיזוג) של ענף אחד לאחר. תמונה זו יכולה להראות את התהליך כאשר ענף אחד מתמזג לאחר: כלומר, יש סניף ראשי. בשלב מסוים נוצר ממנו משני, שבו מתרחשים שינויים. לאחר סיום העבודה, עליך למזג ענף אחד לאחר. לא אתאר מאפיינים שונים: אני רוצה להעביר רק הבנה במסגרת מאמר זה, ואת הפרטים תגלו בעצמכם במידת הצורך. אז, בדוגמה שלנו, יצרנו את ענף feature/update-txt-files. כפי שכתוב בשם הסניף, נעדכן את הטקסט. כעת עליך ליצור commit חדש לעניין זה:

git add *.txt 
git commit -m “updated txt files”
git log

כעת, אם ברצוננו למזג את ענף ה- feature/update-txt-files ל-master, עלינו לעבור אל master ולכתוב git merge feature/update-txt-files:

git checkout master
git merge feature/update-txt-files
git log

כתוצאה מכך, כעת לסניף המאסטר יש גם commit שהתווסף לקבצי feature/update-txt. פונקציונליות זו מתווספת כדי שתוכל למחוק את ענף התכונה. לשם כך אנו כותבים:

git branch -D feature/update-txt-files

עד כאן זה ברור, נכון? בואו נסבך את המצב: עכשיו נניח שאנחנו צריכים לשנות שוב את קובץ ה-txt. אבל עכשיו גם הקובץ הזה ישתנה באשף. כלומר, זה ישתנה במקביל, ו-Git לא יוכל להבין מה צריך לעשות במצב בו נרצה למזג קוד חדש לסניף המאסטר. ללכת! אנו יוצרים סניף חדש המבוסס על מאסטר, מבצעים שינויים ב-text_resource.txt ויוצרים התחייבות לעניין זה:

git checkout -b feature/add-header
... делаем изменения в файле

git add *.txt
git commit -m “added header to txt”

עבור אל הענף הראשי ועדכן גם את קובץ הטקסט הזה באותה שורה כמו ענף הפיצ'רים:

git checkout master
… обновor test_resource.txt

git add test_resource.txt
git commit -m “added master header to txt”

ועכשיו הרגע המעניין ביותר: אתה צריך למזג שינויים מענף הפיצ'ר/add-header למאסטר. אנחנו בסניף המאסטר, אז כל מה שאנחנו צריכים לעשות זה לכתוב:

git merge feature/add-header

אבל נקבל תוצאה עם קונפליקט בקובץ test_resource.txt: וכאן אנחנו יכולים לראות ש-Git לא יכול היה להחליט באופן עצמאי איך למזג את הקוד הזה ואומר שצריך קודם לפתור את הקונפליקט, ורק אז לבצע commit. אוקי, בואו נפתח את הקובץ המכיל את הקונפליקט בעורך טקסט ונראה: כדי להבין מה git עשה כאן, צריך לזכור מה כתבנו איפה ולהשוות:

1. בין "<<<<<<< HEAD" ו-"=======" הם השינויים המאסטר שהיו בשורה זו בענף המאסטר.
2. בין “=======” ו->>>>>>> feature/add-header” ישנם שינויים שהיו בענף feature/add-header.

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

git status

היינו משוכנעים שמדובר במקרה שונה, חריג. בוא נמשיך:

git add *.txt

בתיאור תשימו לב שהם מציעים רק לכתוב git commit. אנחנו מקשיבים וכותבים:

git commit

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

עבודה עם מאגרים מרוחקים

השלב האחרון הוא להבין עוד כמה פקודות שדרושות לעבודה עם מאגר מרוחק. כפי שכבר אמרתי, מאגר מרוחק הוא מקום שבו המאגר מאוחסן וממנו ניתן לשכפל אותו. אילו סוגי מאגרים מרוחקים קיימים? יש המון דוגמאות:

• GitHub הוא המאגר הגדול ביותר עבור מאגרים ופיתוח שיתופי. כבר תיארתי את זה במאמרים קודמים.
  הירשם לחשבון Github שלי . אני מרבה להציג שם את עבודותיי בתחומים שאני לומד במהלך עבודתי.

• GitLab הוא כלי מחזור חיים מבוסס קוד פתוח של DevOps המספק מערכת ניהול מאגר קודים עבור Git עם wiki משלה, מערכת מעקב אחר בעיות , צינור CI/CD ותכונות אחרות. לאחר הידיעה שמיקרוסופט קנתה את GitHub, כמה מפתחים שכפלו את עבודתם ב-GitLab.
  

• BitBucket הוא שירות אינטרנט לאירוח פרויקטים ופיתוח שיתופי, המבוסס על מערכות בקרת גרסאות Mercurial ו-Git. פעם היה לו יתרון גדול על GitHub בכך שהיו לו מאגרים פרטיים בחינם. בשנה שעברה, GitHub גם הפך את התכונה הזו לזמינה לכולם בחינם.

• וכולי…

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

git clone https://github.com/romankh3/git-demo

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

git pull

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

git add test_resource.txt
git commit -m “prepated txt for pushing”

ועכשיו הפקודה לדחוף את זה למאגר המרוחק:

git push

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

קישורים שימושיים

• המסמך הרשמי על Git הוא ברוסית . אני ממליץ עליו כמדריך עזר.
• Git