From 0499772a4b34baaa6207017370bf1c4ee39a88b9 Mon Sep 17 00:00:00 2001
From: Andrii Bida простий посібник з git для початківців. нічого складного ;)
+ Аби створити новий репозиторій git, слід відкрити
+ Створіть робочу копію локального репозиторію командою
+ Локальний git-репозиторій складається з трьох "дерев".
+ Щоб підготувати зміни (додати їх до Індексу), виконайте
+ Щоб надіслати зміни до віддаленного репозиторію, виконайте
+ Гілки використовують для розробки функціоналу відокремленно від решти. Гілка master використовується за промовчанням щойно ви створили репозиторій. Інші гілки використовуються для розробки, а після завершення зливаються у master.
+
+ Щоб створити нову гілку з назвою "feature_x"
+ Щоб оновити локальний репозиторій, виконайте команду:
+ Теги слід використовувати для позначення моменту випуску версії. Це популярна практика, що також використовується в SVN.
+ Створити новий тег с іменем 1.0.0 можна командою
+ Якщо ви зробили щось не те
+ Якщо ж ви бажаєте скасувати всі локальні зміни та комміти, отримайте останні зміни з сервера
+ і вкажіть на них локальну гілку таким чином:
+ вбудований в git графічний інтерфейс:
+
+ git - the simple guide
+
+
+
+
встановлення
+
+
+
+ створення нового репозиторію
+
+ папку, де ви хочете його розмістити, і виконати команду
+ git init
+
+ отримання репозиторію
+
+ git clone /місцезнаходження/репозиторію
+ або ж, при використанні віддаленного сервера,
+ git clone юзер@хост:/місцезнаходження/репозиторію
+ робочий процес
+
+ Робоча директорія
(Working Directory) містить власне файли.
+ Індекс
(Index), або область підготовленних файлів (Staging Area),
+ містить інформацію щодо змін, які мають увійти до наступного комміту.
+ HEAD
вказує на останній зробленний комміт.
+
+
додання і комміт
+
+ git add <ім'я_файла>
+ git add *
+ Це перший крок в базовому робочому процесі. Щоб зробити комміт підготовленних змін (затвердити зміни), слід виконати
+ git commit -m "Опис комміту"
+ Тепер зміни затверджено в локальному репозиторії, на них вказує HEAD; але ці зміни ще не торкнулися віддаленного репозиторію.
+ надсилання змін
+
+ git push origin master
+ Можна замінити master будь-якою іншою гілкою,
до якої ви хочете надіслати зміни.
+
+ Якщо репозиторій не було клоновано, і ви бажаєте підключити свій репозиторій до віддаленного, виконайте:
+ git remote add origin <адреса_сервера>
+ Тепер ви маєте можливість надсилати ваші зміни
до віддаленного репозиторію.
+
+ розгалуження
+
+
і перемкнутися на неї, виконайте команду
+ git checkout -b feature_x
+ перемкнутися назад на master:
+ git checkout master
+ усунути гілку:
+ git branch -d feature_x
+ Гілка не доступна іншим, допоки ви
не надішлете її до віддаленного сервера командою
+ git push origin <ім'я_гілки>
+ оновлення і злиття
+
+ git pull
+ котра отримає зміни у віддаленному репозиторії
і виконає злиття з поточною гілкою.
+ Щоб злити іншу гілку з поточною (наприклад, master),
виконайте команду
+ git merge <ім'я_гілки>
+ У будь-якому з двох випадків, git намагатиметься автоматично злити зміни. На жаль, це не завжди можливо, і в такому повстає конфлікт.
+ Ви маєте усунути виниклі конфлікти, власноруч відредагував файли, що позначив git. Після редагування, треба помітити їх як злиті:
+ git add <ім'я_файла>
+ Перед злиттям можна попередньо оглянути зміни:
+ git diff <ім'я_гілки> <ім'я_іншої_гілки>
+ теги
+
+ git tag 1.0.0 1b2e1d63ff
+ 1b2e1d63ff — це перші десять символів унікального ідентифікатора комміту, з яким будет пов'язаний тег.
+ Аби проглянути ідентифікатори коммітів, виконайте
+ git log
+ В якості ідентифікатора можна використовувати меншу кількість символів, але з умовою, що такий ідентифікатор лишиться унікальним.
+ заміщення локальних змін
+
— чого, звісно, ніколи не трапляється ;) —
можна замінити локальні зміни командою
+ git checkout -- <ім'я_файла>
+ Це замінить зміни в робочій директорії на поточний зміст вказівника HEAD.
+ Зміни, попередньо додані до Індексу, разом з новими файлами, залишаться недоторканими.
+
+ git fetch origin
+ git reset --hard origin/master
+ корисні речі
+
+ gitk
+ використовувати кольорове виведення в терміналі:
+ git config color.ui true
+ виводити лог однорядковими коммітами:
+ git config format.pretty oneline
+ інтерактивне додання до індексу:
+ git add -i
+ корисні лінки
+ графічні інтерфейси
+
+
+
+ посібники
+
+
+
git - Der einfache Einstieg
русский,
türkçe,
+ українська,
မြန်မာ,
日本語,
中文,
한국어
- 日本語, 中文, 한국어
Feedback auf github
git push origin master
git remote add origin <адреса_сервера>
Щоб створити нову гілку з назвою "feature_x"
і перемкнутися на неї, виконайте команду
git checkout -b feature_x
- перемкнутися назад на master:
+ перемкнутися назад на master
git checkout master
- усунути гілку:
- git branch -d feature_x
+ усунути гілку
+ git branch -d feature_x
Гілка не доступна іншим, допоки ви
не надішлете її до віддаленного сервера командою
git push origin <ім'я_гілки>
git merge <ім'я_гілки>
git add <ім'я_файла>
- Теги слід використовувати для позначення моменту випуску версії. Це популярна практика, що також використовується в SVN.
+ Теги слід використовувати для позначення моменту випуску версії. Це популярна практика, що також існує в SVN.
Створити новий тег с іменем 1.0.0 можна командою
git tag 1.0.0 1b2e1d63ff
- 1b2e1d63ff — це перші десять символів унікального ідентифікатора комміту, з яким будет пов'язаний тег.
+ 1b2e1d63ff — це перші десять символів унікального ідентифікатора комміту, з яким буде пов'язаний тег.
Аби проглянути ідентифікатори коммітів, виконайте
git log
В якості ідентифікатора можна використовувати меншу кількість символів, але з умовою, що такий ідентифікатор лишиться унікальним.
коментарі
+ + + +