12 תכונות מדהימות של GitHub

במשך חיי, אני לא יכול לחשוב על שום מבוא, אז...

קוד עריכת מספר 1 ב-GitHub.com

אתחיל ממה שלדעתי כולם כבר יודעים (למרות שבאופן אישי לא היה לי מושג על זה לפני שבוע). בעת צפייה בכל קובץ טקסט ב-GitHub, בכל מאגר, אתה יכול לראות עיפרון קטן בצד ימין למעלה. אם תלחץ עליו, תוכל לערוך את הקובץ הזה. לאחר השלמתו, לחץ על הצעת שינוי קובץ ו-GitHub תיצור בקשת מזלג ו-Pull. מדהים, לא? הוא יוצר את המזלג בעצמו! אין צורך להתפצל ולהעלות את הקוד לעצמך, לבצע שינויים מקומיים ולשלוח אותו בחזרה ל-GitHub עם Pull Request. מאוד נוח אם אתה צריך לבצע עריכות מינימליות. לא ממש בקשת משיכה אמיתית

#2 הוספת תמונות

תיאורי בעיות אינם מוגבלים להערות טקסט בלבד. האם ידעת שאתה יכול להדביק תמונות ישירות מהלוח? לאחר ההדבקה, תראה אותו הועלה (לענן, ללא ספק) והפך לסימון להצגת התמונה. מְעוּדָן!

#3 עיצוב קוד

אם אתה צריך לכתוב גוש קוד, התחל עם שלושה סימנים לאחור ו-GitHub ינסה לנחש באיזו שפת תכנות אתה כותב. אבל אם אתה מפרסם קטע קוד בשפת תכנות כמו Vue, Typescript או JSX, אתה יכול לציין במפורש את השפה כך שהדגשת התחביר תהיה נכונה. שימו לב ל- ``` jsx בשורה הראשונה: ...הבטחת תצוגה נכונה של קטע הקוד: (זה חל גם על Gist, אגב. אם תציין סיומת .jsf עבור תמצית, תחביר JSF יודגש). הנה רשימה של כל התחבירים הנתמכים .

#4 סגירת בעיות באמצעות "מילים קסם" בבקשות משיכה

נניח שאתה יוצר Pull Request שמתקן בעיה מס' 234. אתה יכול להכניס את הטקסט "מתקן בעיה מס' 234" לתיאור הבקשה שלך (או בכל מקום בכל הערת בקשת שינוי). לאחר מכן, מיזוג ה-Pull Request יסגור את הבעיה "אוטומטית". מגניב, לא? הנה מידע נוסף על כך בתיעוד .

#5 קישור לתגובות

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

#6 קישור קוד

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

#7 שימוש בכתובת GitHub כשורה פקודה

ניווט דרך GitHub באמצעות ממשק המשתמש מאורגן בצורה נוחה מאוד. אבל לפעמים, כדי להגיע למיקום מסוים, זה מהיר יותר פשוט להקליד אותו בכתובת האתר. לדוגמה, אם אני רוצה ללכת לסניף שאני עובד עליו ולראות איך הוא משתווה למאסטר, אני יכול פשוט להקליד /compare/branchname אחרי שם המאגר. זה יעביר אותי לדף ההבדל של אותו סניף: אבל אלו הבדלים מהענף הראשי, אבל אם עבדתי עם ענף האינטגרציה בעבר, אני יכול להזין /compare/integration-branch...my-branch בכתובת האתר לאוהבי מקשי קיצור: CTRL+L או CMD+L מזיזים את הסמן לשורת ה-URL (לפחות בדפדפני Chrome ו-Firefox). זה, בשילוב עם השלמה אוטומטית של דפדפן, הופך את הניווט בין הסניפים להרבה יותר קל. טיפ מקצועי: השתמש בחצים כדי לנווט בין הצעות ההשלמה האוטומטית של Chrome, והקש SHIFT+DELETE כדי להסיר פריטים מההיסטוריה (לדוגמה, לאחר מיזוג סניף). (אני לא יודע אם יהיה קל יותר לקרוא את מקשי הקיצור האלה אם אשים בהם רווח, כמו SHIFT + DELETE. אבל מבחינה טכנית "+" הוא לא חלק מהם, אז אני לא אוהב את האפשרות הזו. זה בגלל דברים כאלה אני לא ישנה בלילה, רונדה.)

#8 צור רשימות לבעיות

האם אתה רוצה תיבת סימון בתיאור הבעיה שלך? והאם אתה רוצה שסרגל נחמד כמו "2 מתוך 5" יופיע כשאתה מציג בעיה מהרשימה? אין בעיה! אתה יכול ליצור תיבות סימון אינטראקטיביות באמצעות התחביר הבא:

• [ ] רוחב מסך (מספר שלם)
• [x] תמיכה בעובדי שירות
• [x] תמיכה באחזור
• [ ] תמיכה ב-CSS flexbox
• [ ] אלמנטים מותאמים אישית

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

#9 לוחות פרויקט ב-GitHub

לפרויקטים גדולים תמיד השתמשתי בג'ירה. ולפרוייקטים האישיים שלי, תמיד השתמשתי בטרלו. אני מאוד אוהב את שני הכלים האלה. כשנודע לי לפני מספר שבועות ש-GitHub מציע אפשרות משלו, ממש בלשונית Projects של המאגר, חשבתי שזה הגיוני לשכפל את סט המשימות שאני כבר עובד איתן ב-Trello. אין כאן שום דבר מצחיק. ועכשיו אותו דבר בפרויקט GitHub: בהדרגה העיניים שלך יתרגלו לתמונה בעלת הניגודיות הנמוכה למען המהירות, הוספתי את כל האמור לעיל כהערות, כלומר הן אינן בעיות GitHub "אמיתיות". אבל הכוח של ניהול הנושאים ב-GitHub טמון באינטגרציה שלו עם שאר המאגר – אז כנראה שעדיף להוסיף בעיות קיימות מהמאגר ללוח המחוונים. לחץ על הוסף כרטיסים בפינה השמאלית העליונה ומצא את מה שתרצה להוסיף. כאן שימושי תחביר חיפוש מיוחד : לדוגמה, הקלד is:pr is:open ותוכל לגרור כל Request Pull Open לחלונית, או label:bug אם אתה צריך לתקן שגיאות כלשהן. אתה יכול גם להמיר הערות קיימות לבעיות. ולבסוף, מטופס הבעיה הקיים, הוסף אותו לפרויקט בפאנל הימני. זה ייכנס לרשימת הטריאג' של פאנל הפרויקט הזה, כך שתוכל לבחור באיזו עמודה להכניס אותו כאשר התיאור של "משימה" נמצא באותו מאגר כמו הקוד שמיישם את המשימה הזו, זה מאוד (מאוד) נוח. המשמעות היא ששנים רבות מהיום, תוכל להפעיל git blame על שורת קוד ולהבין את מכלול הבעיה שהובילה לשורה הזו, מבלי שתצטרך לעקוב אחר הכל ב-Jira/Trello/במקומות אחרים.

פגמים

בשלושת השבועות האחרונים התנסיתי לעשות הכל ב-GitHub במקום ב-Jira (בפרויקט קטן, סוג של סגנון Kanban) ולאהוב את זה. אבל אני לא יכול לדמיין את זה עבור פרויקט Scrum שבו יש להעריך ולחשב כראוי את מהירות הפיתוח וכדומה. החדשות הטובות הן שלפרויקטים של GitHub יש כל כך מעט "תכונות מיוחדות" שמעבר למערכת אחרת לא ייקח הרבה זמן. אז נסה את זה ותראה כמה אתה אוהב את זה. אני לא יודע כמה זה חשוב, אבל שמעתי על ZenHub ופתחתי אותו בפעם הראשונה לפני 10 דקות. זה בעצם הרחבה של GitHub שבה אתה יכול לדרג בעיות וליצור "אפוסים" ותלות. יש גרפים של מהירות פיתוח ושחיקה; זה נראה כאילו זה פשוט דבר מדהים. קריאה נוספת: תיעוד GitHub על פרויקטים.

#10 Gwiki

עבור קבוצה לא מובנית של דפים - כמו ויקיפדיה - ה-GitHub Wiki (שאני פשוט אקרא Gwiki מעתה ואילך) הוא נהדר. עבור סט מובנה של דפים - למשל, כמו התיעוד שלך - לא כל כך. אין דרך לציין ש"הדף הזה הוא ילד של אותו אחד"; אין דברים נוחים כמו "המדור הבא" וכפתורי "הקטע הקודם". הנזל וגרטל בהחלט ילכו כאן לאיבוד, כי גם כאן אין "פירורי לחם" (מפעילי ניפוי באגים מיוחדים - בערך תרגום). (הערת המחבר: קראת את הסיפור הזה? זה פשוט לא אנושי. שני בריונים צעירים הורגים זקנה רעבה ומסכנה, שורפים אותה בחיים בתנור משלה . וכמובן, משאירים בלגן מוחלט שאף אחד לא יוכל להבין. אני חושב שבגלל זה אנשים צעירים בימינו הם כל כך רגישים לעזאזל - סיפורים שקוראים לילדים לפני השינה בימים אלה אינם אכזריים מספיק!) ממשיכים הלאה - כדי לנסות את Gwiki באמת, נכנסתי כמה דפים מ-NodeJS כדפי ויקי, ואז יצרתי התאמה אישית סרגל צד כדי לדמות את המבנה בפועל של האתר. סרגל צד זה קיים תמיד, למרות שהעמוד הנוכחי אינו מודגש. הקישורים יצטרכו להישמר באופן ידני, אבל בסך הכל הכל עובד בסדר. אם אתה רוצה, אתה יכול להסתכל : זה בקושי יכול להתחרות במשהו כמו GitBook (שנעשה בו שימוש בתיעוד Redux ) או אתר אינטרנט מותאם אישית. אבל זה כבר 80% ממנו והכל בסדר במאגר שלך. אני רק מעריץ של זה. אני מציע שאם צמחת מהקובץ הבודד README.md ואתה זקוק למספר דפים שונים עבור מדריכי משתמש או תיעוד מפורט יותר, הגיוני להישאר עם Gwiki. אם חוסר המבנה/ניווט מפריע לכם, עברו למשהו אחר.

#11 דפי GitHub

אולי אתה כבר יודע שניתן להשתמש בדפי GitHub כדי לארח אתר סטטי. ואם לא ידעת, אז אתה יודע עכשיו. עם זאת, חלק זה מוקדש לנושא ספציפי יותר: שימוש ב- Jekyll ליצירת אתר אינטרנט. בצורתו הפשוטה ביותר, GitHub Pages + Jekyll יכולים לעבד את הקובץ README.md באמצעות ערכת נושא יפה. לדוגמה, תסתכל בדף ה-readme שלי מ- about-github : אם תלחץ על לשונית ההגדרות של אתר GitHub זה, הפעל את דפי GitHub ובחר את ערכת הנושא Jekyll... אז נקבל עמוד בסגנון של נושא Jekyll : לאחר מכן תוכל ליצור אתר סטטי שלם המבוסס בעיקר על קבצי סימון הניתנים לעריכה, ובעצם להפוך את GitHub ל-CMS. למרות שלמעשה לא השתמשתי בזה, כך נבנים אתרים באמצעות מסגרת Bootstrap באמצעות React, כך שאין בזה שום דבר נורא. אני מציין שרובי חייב לפעול על המחשב המקומי (משתמשי Windows כאן יחליפו מבטים מבינים וילכו לכיוון השני, משתמשי macOS יגידו: "מה הבעיה, לאן אתה הולך? רובי היא פלטפורמה אוניברסלית! יש גם GEMS מערכת ניהול חבילות!") (ראוי גם לציין ש"תוכן או התנהגות אגרסיביים או מאיימים" אסור בדפי GitHub, כך שלא תוכל לפרסם שם את הגרסה שלך לסיפור הנזל וגרטל).

דעתי

ככל שהסתכלתי יותר על השילוב של GitHub Pages + Jekyll (עבור מאמר זה), כך חשבתי שכל הרעיון מריח מוזר. הרעיון של "ליצור אתר משלך במינימום מאמץ" הוא נהדר. אבל כדי לעבוד על זה אתה עדיין צריך את הגרסה הנוכחית במחשב המקומי. ולמשהו כל כך "פשוט" יש יותר מדי פקודות שורת פקודה. רפרפתי על שבעת הדפים בסעיף תחילת העבודה והרגשתי שהדבר הפשוט בו הוא אני . ואפילו לא הבנתי את התחביר הפשוט עבור העמוד הראשי או את היסודות של "מנגנון תבניות פשוט המבוסס על השפה הנוזלית". אני מעדיף לכתוב אתר בעצמי! למען האמת, אני קצת מופתע שפייסבוק משתמשת בזה לתיעוד של React, כאשר הם יכלו כנראה לבנות את דפי מערכת העזרה שלהם באמצעות React ולעבד מראש כקובצי HTML סטטיים בכל יום . כל מה שהם צריכים לעשות הוא למצוא דרך לקבל קבצי סימון קיימים כאילו הם מגיעים מה-CMS. מה אם...

#12 שימוש ב-GitHub כ-CMS

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

class Markdown extends React.Component {
    constructor(props) {
      super(props);

      // Конечно, вам нужно заменить это на свой URL
      this.baseUrl = 'https://raw.githubusercontent.com/davidgilbertson/about-github/master/text-snippets';

      this.state = {
        markdown: '',
      };
    }

    componentDidMount() {
      fetch(`${this.baseUrl}/${this.props.url}`)
        .then(response => response.text())
        .then((markdown) => {
          this.setState({markdown});
        });
    }

    render() {
      return (
        <div dangerouslySetInnerHTML={{__html: marked(this.state.markdown)}} />
      );
    }
}

(אני משתמש בחבילה המסומנת npm כאן כדי לנתח סימון ב-HTML) כתובת ה-URL מצביעה על מאגר הדוגמה שלי, המכיל קבצי סימון בספריית /text-snippets . (אתה יכול גם להשתמש ב-GitHub API כדי להביא תוכן , אבל אני בספק אם תצטרך את זה.) אתה יכול להשתמש ברכיב כמו זה:

const Page = () => (
  <div className="page">
    <div className="about-us">
      <Markdown url="about-us.md" />
    </div>

    <div className="disclaimer">
      <p>A very important disclaimer:</p>

      <Markdown url="disclaimers/home-page-disclaimer.md" />
    </div>
  </div>
);

אז עכשיו GitHub פועלת כמו, באופן מסוים, CMS שלך עבור קטעי טקסט שאתה רוצה לארח. הדוגמה לעיל מאחזרת את הסימון רק לאחר שהרכיב נטען בדפדפן. אם אתה צריך אתר סטטי, תצטרך לרנדר אותו בשרת. חדשות טובות! אין שום דבר שמונע ממך לאחזר את כל קבצי הסימון בשרת (באמצעות כל אסטרטגיית מטמון שתרצה). אם תחליט ללכת בדרך זו, הגיוני להשתמש ב- GitHub API כדי לקבל רשימה של כל קבצי הסימון בספרייה. בונוס - כלי עזר GitHub! אני משתמש בתוסף Octotree Chrome כבר די הרבה זמן וממליץ לך עליה. לא בלי הסתייגויות, אבל אני עדיין ממליץ על זה. הוא מציג חלונית משמאל עם תצוגת עץ של המאגר שבו אתה גולש. ומהסרטון הזה למדתי על octobox , שגם הוא נראה לי כלי טוב מאוד עד כה. זוהי תיבת הדואר הנכנס עבור בעיות GitHub שלך. זה כל מה שאתה צריך לדעת עליו. אם כבר מדברים על צבעים, צילמתי את כל צילומי המסך לעיל בעיצוב קל כדי לא להפחיד אותך. אבל אם אני מעדיף צבעים כהים בכל השאר, אז למה להשלים עם GitHub חיוור מוות? כאן השתמשתי בשילוב של התוסף Stylish עבור דפדפן כרום (שיכול להחיל ערכות נושא על כל אתר אינטרנט) וסגנון GitHub Dark . בתור התחלה, ערכת הנושא האפלה של כלי המפתחים של GitHub (מובנית, אתה רק צריך להפעיל אותו) ו- Atom One Dark עבור Chrome.

Bitbucket

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

סיכום

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