it-swarm.com.ru

Git для начинающих: полное практическое руководство

Хорошо, увидев этот пост от PJ Hyett , я решил пропустить до конца и перейти к Git .

Так что мне нужно руководство для начинающих практическое Git. "Начинающий" определяется как тот, кто знает, как обращаться со своим компилятором, до некоторого уровня понимает, что такое Makefile , и коснулся управления исходным кодом, не понимая его очень хорошо.

Термин "практический" определяется как этот человек, который не хочет вдаваться в подробности относительно того, что Git делает в фоновом режиме, и даже не заботится (или не знает) о том, что он распространяется. Ваши ответы могут указывать на возможные варианты, но постарайтесь найти новичка, который хочет сохранить "главный" репозиторий на "сервере", резервное копирование и безопасность которого, и рассматривать свой локальный репозиторий как просто "клиентский" ресурс.

Так:

Установка/настройка

Работа с кодом

Пометка, ветвление, релизы, базовые показатели

Другой

  • Опишите и сошлитесь на хороший графический интерфейс, IDE плагин и т.д., Который делает Git ресурсом не для командной строки, но, пожалуйста, перечислите его ограничения и преимущества.
    • msysgit - Кроссплатформенность, включенная в Git
    • gitk - Программа просмотра истории кроссплатформенности, включенная в Git
    • gitnub - Mac OS X
    • gitx - Просмотрщик Mac OS X
    • smartgit - кроссплатформенный, коммерческий, бета
    • tig - графический интерфейс консоли для Linux
    • qgit - GUI для Windows, Linux
    • Git Extensions - пакет для Windows, включает дружественный графический интерфейс
  • Любые другие общие задачи, которые должен знать новичок?
  • Как эффективно работать с репозиторием Subversion, установленным в качестве источника управления исходным кодом?

Другие ссылки для начинающих в Git

Копаться в Git

Я буду время от времени просматривать записи и "приводить их в порядок", чтобы они выглядели единообразно, чтобы было легко просматривать список - легко проследить за простым "заголовком" - кратким объяснением - списком инструкций - уловками и дополнительная информация "шаблон. Я также сошлюсь на записи из списка выше, так что их легко найти позже.

854
Adam Davis

Как вы создаете новый проект/репозиторий?

Git-репозиторий - это просто каталог, содержащий специальный каталог .git.

Это отличается от "централизованных" систем контроля версий (таких как Subversion), где "хранилище" размещается на удаленном сервере, который вы checkout помещаете в каталог "рабочая копия". С git ваша рабочая копия является хранилищем.

Просто запустите git init в каталоге, который содержит файлы, которые вы хотите отслеживать.

Например,

cd ~/code/project001/
git init

Это создаст .git (скрытую) папку в текущем каталоге.

Чтобы создать новый проект, запустите git init с дополнительным аргументом (имя создаваемого каталога):

git init project002

(This is equivalent to: mkdir project002 && cd project002 && git init)

Чтобы проверить, находится ли текущий текущий путь в репозитории git, просто запустите git status - если это не репозиторий, он выдаст сообщение "fatal: Not the git repository"

Вы также можете перечислить каталог .git и проверить, что он содержит файлы/каталоги, подобные следующим:

$ ls .git
HEAD         config       hooks/       objects/
branches/    description  info/        refs/

Если по какой-либо причине вы хотите "отменить" git-репозиторий (вы хотите прекратить использовать git для отслеживания этого проекта). Просто удалите каталог .git на базовом уровне хранилища.

cd ~/code/project001/
rm -rf .git/

Внимание: Это уничтожит всю историю изменений, все ваши теги, все , что сделал git. Он не будет касаться "текущих" файлов (файлов, которые вы можете видеть в данный момент), но предыдущие изменения, удаленные файлы и т.д. Будут невосстановимыми!

118
dbr

GUI для git


Git GUI

В комплекте с git - Запустите git gui из командной строки, и установщик Windows msysgit добавит его в меню Пуск.

Git GUI может делать большую часть того, что вам нужно делать с Git. Включая изменения на этапе, настройку git и репозиториев, Push-изменения, создание/извлечение/удаление веток, слияние и многое другое.

Одна из моих любимых функций - это ярлыки "stage line" и "stage hunk" в контекстном меню, которые позволяют вам фиксировать определенные части файла. Вы можете добиться того же с помощью git add -i, но я считаю, что его проще использовать.

Это не самое красивое приложение, но оно работает практически на всех платформах (основываясь на Tcl/Tk)

скриншоты | скринкаст


GitK

Также включен с мерзавцем. Это средство просмотра истории git, позволяющее визуализировать историю репозитория (включая ветви, когда они создаются и объединяются). Вы можете просматривать и искать коммиты.

Хорошо сочетается с Git-Gui.


Gitnub

Приложение Mac OS X. В основном эквивалент git log, но имеет некоторую интеграцию с github (например, "Сетевое представление").

Выглядит красиво и подходит для Mac OS X. Вы можете искать репозитории. Самым большим критиком Gitnub является то, что он показывает историю линейно (по одной ветке за раз) - он не визуализирует ветвления и слияния, что может быть важно для git, хотя это запланированное улучшение.

Скачать ссылки, журнал изменений и скриншоты | Git репозиторий


GitX

Намеревается быть "клоном GITK для OS X".

Он может визуализировать историю нелинейного ветвления, выполнять коммиты, просматривать и искать коммиты, а также имеет некоторые другие приятные функции, такие как возможность "быстрого просмотра" любого файла в любой ревизии (нажмите пробел в представлении списка файлов), экспорт любого файла. (с помощью перетаскивания).

Он гораздо лучше интегрирован в OS X, чем git-gui/gitk, и быстр и стабилен даже с исключительно большими репозиториями.

Исходный репозиторий git pieter не обновлялся в последнее время (более года на момент написания). Более активно поддерживаемая ветвь доступна по адресу brotherbard/gitx - она ​​добавляет "боковую панель, извлечение, извлечение, Push, добавление удаленного, объединение, cherry-pick, rebase, clone, clone to"

Скачать | скриншоты | Git репозиторий | братбард вилка | Laullon Fork


SmartGit

С домашней страницы:

SmartGit является интерфейсом для распределенной системы контроля версий Git и работает в Windows, Mac OS X и Linux. SmartGit предназначен для разработчиков, которые предпочитают графический интерфейс пользователя клиенту командной строки, чтобы быть еще более продуктивным с Git - самой мощной на сегодняшний день DVCS.

Вы можете скачать его с их веб-сайт .

Скачать


TortoiseGit

TortoiseSVN Git версия для пользователей Windows.

Он портирует TortoiseSVN на TortoiseGit. Последний выпуск 1.2.1.0. Этот выпуск может выполнять обычные задачи, такие как фиксация, показ журнала, изменение двух версий, создание ветки и тега, создание патча и так далее. Смотрите ReleaseNotes для деталей. Добро пожаловать, чтобы внести свой вклад в этот проект.

Скачать


QGit

QGit - это средство просмотра графического интерфейса пользователя git, построенное на Qt/C++.

С помощью qgit вы сможете просматривать историю изменений, просматривать содержимое патчей и измененные файлы, графически следуя различным веткам разработки.

Скачать


gitg

gitg - это средство просмотра репозитория git, ориентированное на gtk +/GNOME. Одна из его основных задач - обеспечить более унифицированный пользовательский интерфейс для интерфейсов git на нескольких рабочих столах. Это делается не для написания кроссплатформенного приложения, а путем тесного сотрудничества с аналогичными клиентами для других операционных систем (например, GitX для OS X).

Характеристики

  • Просмотрите историю изменений.
  • Обработка больших репозиториев (загрузка репозитория linux, 17000+ ревизий, менее чем за 1 секунду).
  • Зафиксируйте изменения.
  • Стадия/неугодные отдельные куски.
  • Отменить изменения.
  • Показать разноцветные различия изменений в ревизиях.
  • Просмотрите дерево для данной ревизии.
  • Экспортировать части дерева данной ревизии.
  • Укажите любой refspec, который может понять команда, такая как 'git log', для построения истории.
  • Показать и переключаться между ветвями в истории просмотра.

Загрузить: релизы или источник


Gitbox

Gitbox - это графический интерфейс Mac OS X для системы контроля версий Git. В одном окне вы видите ветки, историю и статус рабочего каталога.

Повседневные операции просты: сценические и нестандартные изменения с флажком. Зафиксируйте, вытяните, объедините и нажмите одним нажатием. Дважды щелкните изменение, чтобы отобразить разницу с FileMerge.app.

Скачать


Gity

На веб-сайте Gity не так много информации, но на скриншотах он выглядит как многофункциональный OS X git gui с открытым исходным кодом.

Скачать или источник


Meld

Meld - инструмент визуального сравнения и слияния. Вы можете сравнить два или три файла и редактировать их на месте (различия обновляются динамически). Вы можете сравнить две или три папки и запустить сравнение файлов. Вы можете просматривать и просматривать рабочую копию из популярных систем контроля версий, таких как CVS, Subversion, Bazaar-ng и Mercurial [ и Git ].

Загрузки


катана

Git GUI для OSX от Стива Декорте.

С первого взгляда посмотрите, в каких удаленных ветвях есть изменения для извлечения, а в локальных репозиториях - в Push. Поддерживаются такие операции, как добавление, фиксация, push, pull, tag и reset, а также визуальные различия и визуальный просмотр истории проекта, которая выделяет локальные изменения и дополнения.

Бесплатно за 1 репозиторий, $ 25 за больше.

Скачать


Sprout (ранее GitMac)

Ориентирован на то, чтобы сделать Git простым в использовании. Имеет встроенный пользовательский интерфейс Какао (Mac-like), быстрый просмотр репозитория, клонирование, Push/Pull, ветвление/слияние, визуальные различия, удаленные ветки, легкий доступ к терминалу и многое другое.

Делая наиболее часто используемые действия Git интуитивно понятными и простыми для выполнения, Sprout (ранее GitMac) делает Git удобным для пользователя. Совместимый с большинством рабочих процессов Git, Sprout отлично подходит для дизайнеров и разработчиков, для совместной работы в команде, а также для опытных и начинающих пользователей.

Скачать | сайт


башня

Многофункциональный графический интерфейс Git для Mac OSX. 30-дневная бесплатная пробная версия, 59 долларов США за однопользовательскую лицензию.

Скачать | сайт


EGit

EGit является поставщиком Eclipse Team для системы контроля версий Git. Git - это распределенный SCM, что означает, что у каждого разработчика есть полная копия всей истории каждой ревизии кода, что делает запросы к истории очень быстрыми и универсальными.

Проект EGit реализует инструментарий Eclipse поверх реализации Git для JGit Java.

Скачать | сайт


Git Extensions

Open Source для Windows - устанавливает все необходимое для работы с Git в одном пакете, прост в использовании.

Git Extensions - это инструментарий, позволяющий сделать работу с Git в Windows более интуитивной. Расширение Shell будет интегрировано в Windows Explorer и представляет контекстное меню для файлов и каталогов. Существует также плагин Visual Studio для использования Git из Visual Studio.

Скачать

Большое спасибо dbr за то, что подробно рассказал о git gui.


SourceTree

SourceTree является бесплатным Mac-клиентом для Git, Mercurial и SVN. Созданный Atlassian, разработчиками BitBucket, он одинаково хорошо работает с любой системой VC, которая позволяет вам освоить один инструмент для использования со всеми вашими проектами, однако они контролируются версиями. Функционально и БЕСПЛАТНО.

Экспертно-готовый и функциональный пакет для начинающих и опытных пользователей:

Просмотр исходящих и входящих изменений. Вишня между ветками. Обработка патчей, ребейс, тайник/полка и многое другое.

Скачать | сайт


110
dylanfm

Ну, несмотря на то, что вы просили, чтобы мы не "просто" связывали с другими ресурсами, это довольно глупо, когда уже существует выросший (и растущий) ресурс сообщества, который действительно довольно хорош: Git Community Book , Серьезно, эти 20 с лишним вопросов в вопросе будут совсем не краткими и последовательными Книга сообщества Git доступна как в формате HTML, так и PDF, и содержит ответы на многие ваши вопросы с четкими, хорошо отформатированными и рецензированными ответами, а также в формате, позволяющем сразу перейти к вашей проблеме.

Увы, если мой пост действительно расстроит вас, я его удалю. Просто скажи так.

59
Pat Notz

Как настроить его для игнорирования файлов:

Возможность заставить git игнорировать файлы, которые вы не хотите отслеживать, очень полезна.

Чтобы игнорировать файл или набор файлов, вы предоставляете шаблон. Синтаксис шаблона для git довольно простой, но мощный. Это применимо ко всем трем различным файлам, которые я упомяну ниже.

  • Пустая строка игнорирует файлы, она обычно используется в качестве разделителя.
  • Строки, начинающиеся с # , служат комментариями.
  • Префикс ! является необязательным и отменяет шаблон. Любой совпадающий шаблон, который соответствует, переопределит шаблоны с более низким приоритетом.
  • Поддерживает расширенные выражения и подстановочные знаки
    • Пример: шаблон: *. [Oa] будет игнорировать все файлы в хранилище, заканчивающиеся на .o или .a (объектные и архивные файлы)
  • Если шаблон имеет каталог, заканчивающийся косой чертой, git будет соответствовать только этому каталогу и путям под ним. Это исключает обычные файлы и символические ссылки из матча.
  • Начальная косая черта будет соответствовать всем файлам с таким путем.
    • Пример: шаблон /*. C будет соответствовать файлу foo.c но не bar/awesome.c

Отличный пример из страницы gitignore (5) :

$ git status
[...]
# Untracked files:
[...]
#       Documentation/foo.html
#       Documentation/gitignore.html
#       file.o
#       lib.a
#       src/internal.o
[...]
$ cat .git/info/exclude
  # ignore objects and archives, anywhere in the tree.
  *.[oa]
$ cat Documentation/.gitignore
# ignore generated html files,
*.html
# except foo.html which is maintained by hand
!foo.html
$ git status
[...]
# Untracked files:
[...]
#       Documentation/foo.html
[...]

Обычно есть три разных способа игнорировать неотслеживаемые файлы.

1) Игнорировать для всех пользователей репозитория:

Добавьте файл с именем . Gitignore в корень вашей рабочей копии.

Отредактируйте . Gitignore , чтобы соответствовать вашим предпочтениям, для которых файлы следует/не следует игнорировать.

git add .gitignore 

и совершить, когда вы закончите.

2) Игнорировать только вашу копию репозитория:

Добавьте/отредактируйте файл $ GIT_DIR/info/exclude в вашей рабочей копии с вашими предпочтительными шаблонами.

Пример: моя рабочая копия ~/src/project1, поэтому я бы отредактировал ~/src/project1/.git/info/exclude

Вы сделали!

3) Игнорировать во всех ситуациях в вашей системе:

Глобальные шаблоны игнорирования для вашей системы могут находиться в файле с именем, которое вы когда-либо пожелаете.

Мой лично называется ~/.gitglobalignore

Затем я могу сообщить git об этом файле, отредактировав мой ~/.gitconfig файл следующей строкой:

core.excludesfile = ~/.gitglobalignore

Вы сделали!

Я считаю, что справочная страница gitignore является лучшим источником дополнительной информации.

56
Brian Gianforcaro

Как вы 'помечаете' определенный набор ревизий?

Как вы "помечаете" "тег" или "выпускаете" определенный набор ревизий для определенного набора файлов, чтобы вы всегда могли получить его позже?

Использование команды git tag.

Чтобы просто "пометить" текущую ревизию, вы просто запустите ..

git tag -a thetagname
git tag -a 0.1
git tag -a 2.6.1-rc1 -m 'Released on 01/02/03'

Чтобы получить список текущих тегов, просто запустите git tag без аргументов или -l (строчная буква L):

$ git tag -a thetagname # and enter a message, or use -m 'My tag annotation'
$ git tag -l
thetagname

Чтобы удалить тег, используйте флаг -d:

$ git tag -d thetagname 
Deleted tag 'thetagname'
$ git tag
[no output]

Чтобы пометить определенный (предыдущий) коммит, вы просто делаете ..

git tag [tag name] [revision SHA1 hash]

Например:

git tag 1.1.1 81b15a68c6c3e71f72e766931df4e6499990385b

Примечание: по умолчанию git создает "легкий" тег (в основном ссылка на конкретную ревизию). "Правильный" способ - использовать флаг -a. Это запустит ваш редактор с запросом сообщения тега (идентично запросу сообщения фиксации, вы также можете использовать флаг -m для предоставления сообщения тега в командной строке). Использование аннотированного тега создает объект со своим собственным идентификатором, датой, тегом (автор) и, необязательно, подписью GPG (используя тег -s). Подробнее об этом см. этот пост

git tag mytagwithmsg -a -m 'This is a tag, with message'

И для вывода списка тегов с аннотациями используйте флаг -n1, чтобы показать 1 строку каждого сообщения тега (-n245, чтобы показать первые 245 строк каждой аннотации и т.д.):

$ git tag -l -n1
mytagwithmsg    This is a tag, with message

Для получения дополнительной информации см. Страница руководства git-tag (1)

47
dbr

Пример рабочего процесса с GIT.

Git чрезвычайно гибок и хорошо адаптируется к любому рабочему процессу, но отсутствие принудительного применения определенного рабочего процесса может иметь отрицательный эффект, затрудняя понимание того, что вы можете сделать с помощью git, помимо линейного рабочего процесса "резервного копирования", и насколько полезными могут быть, например, ветвления. ,.

Это сообщение в блоге хорошо объясняет очень простой, но эффективный рабочий процесс, который действительно легко настроить с помощью git.

цитата из поста блога: мы считаем Origin/master основной веткой, где исходный код HEAD всегда отражает состояние готовности к работе:

Рабочий процесс стал достаточно популярным, чтобы создать проект, который реализует этот рабочий процесс: git-flow

Хорошая иллюстрация простого рабочего процесса, в котором вы вносите все свои изменения в разработку, и только Push to master, когда код находится в рабочем состоянии:

simple workflow

Теперь предположим, что вы хотите работать над новой функцией или над рефакторингом модуля. Вы можете создать новую ветвь, которую мы могли бы назвать "функциональной" веткой, что займет некоторое время и может привести к поломке кода. Как только ваша функция станет "достаточно стабильной" и вы захотите "приблизить" ее к производству, вы включите свою ветку функций в разработку. Когда после слияния все ошибки устранены, и ваш код успешно прошел все тесты, вы проталкиваете свои изменения в master.

Во время всего этого процесса вы обнаружите ужасную ошибку безопасности, которая должна быть немедленно исправлена. У вас может быть ветвь под названием "Исправления", которая вносит изменения, которые быстрее возвращаются в рабочий процесс, чем обычная ветвь "разработки".

Здесь у вас есть иллюстрация того, как может выглядеть этот рабочий процесс/исправление/разработка/производство (хорошо объяснено в сообщении в блоге, и я повторяю, сообщение в блоге объясняет весь процесс гораздо более подробно и намного лучше, чем я) ,.

Git workflow example

46
ashwoods

Вот копия поста PJ Hyett, так как он больше не доступен:

Git не сложно

23 ноября 2008 г.

Когда мы говорим людям, почему они должны использовать Git вместо Subversion, мы говорим: "Git делает Subversion лучше, чем Subversion, но он делает гораздо больше".

"Больше" состоит из множества вещей, которые делают Git действительно блестящим, но это может быть довольно подавляющим для тех, кто прибывает из других SCM, таких как Subversion.

Тем не менее, ничто не мешает вам использовать Git так же, как вы используете Subversion, пока вы делаете переход.

Предполагая, что вы установили необходимое программное обеспечение и имеете где-нибудь удаленный репозиторий, вот как вы можете получить код и отправить изменения обратно с помощью Subversion:

$ svn checkout svn://foo.googlecode.com/svn/trunk foo
# make your changes
$ svn commit -m "my first commit"

И как бы вы сделали это в Git:

$ git clone [email protected]:pjhyett/foo.git
# make your changes
$ git commit -a -m "my first commit"
$ git Push

Еще одна команда, чтобы это произошло в Git. Эта дополнительная команда имеет большие последствия, но для целей этого поста, это все, о чем мы говорим, одна дополнительная команда.

Видите, это действительно не так сложно.

Обновление: Я не буду упоминать, что эквивалент обновления вашей локальной копии в Subversion по сравнению с Git - svn update и git pull соответственно. Только одна команда в обоих случаях.

39
Adam Davis

Как установить Git

В Windows:

Установить msysgit

Есть несколько загрузок:

  • Git: Используйте это, если вам не нужен один из других вариантов ниже.
  • PortableGit: Используйте это, если вы хотите запустить Git на ПК без установки на этом компьютере (например, запустить Git с USB-накопителя)
  • msysGit: Используйте это, если вы хотите разрабатывать сам Git. Если вы просто хотите использовать Git для вашего исходного кода, но не хотите редактировать исходный код Git , вы не это не нужно.

При этом также устанавливается оболочка Cygwin bash, поэтому вы можете использовать git в более удобной оболочке (чем cmd.exe), а также включать git-gui (доступный с помощью команды git gui или из меню Start > All Programs > Git)

Mac OS X

Используйте git-osx-installer , или вы также можете установить из исходного кода

Через менеджер пакетов

Установите git, используя свой собственный менеджер пакетов. Например, в Debian (или Ubuntu):

apt-get install git-core

Или в Mac OS X через MacPorts :

Sudo port install git-core+bash_completion+doc

... или финк:

fink install git

… Или Доморощенный :

brew install git

В дистрибутивах на основе Red Hat, таких как Fedora:

yum install git

В Cygwin пакет Git находится в разделе "devel"

Из источника (Mac OS X/Linux/BSD/и т.д.)

В Mac OS X, если у вас установлены Developer Tools, вы можете очень легко скомпилировать Git из исходного кода. Загрузите последнюю версию Git как .tar.bz или .tar.gz из http://git-scm.com/ и распакуйте ее (дважды щелкните в Finder)

На Linux/BSD/и т.д. это должно быть примерно так же. Например, в Debian (и Ubuntu) вам необходимо установить пакет build-essential через apt.

Затем в терминале cd туда, куда вы распаковали файлы (должен работать cd ~/Downloads/git*/), а затем запустите ..

./configure && make && Sudo make install

Это установит Git в место по умолчанию (/usr/local - поэтому git будет в /usr/local/bin/git)

Он предложит вам ввести свой пароль (для Sudo), это значит, что он может записывать в каталог /usr/local/, к которому может получить доступ только пользователь "root", поэтому требуется Sudo!

Если вы хотите установить его где-то отдельно (чтобы файлы Git не смешивались с другими инструментами), используйте --prefix с командой configure:

./configure --prefix=/usr/local/gitpath
make
Sudo make install

Это установит двоичный файл git в /usr/local/bin/gitpath/bin/git - поэтому вам не нужно вводить его каждый раз, вы должны добавить его в свой $PATH, добавив следующую строку в свой ~/.profile:

export PATH="${PATH}:/usr/local/bin/gitpath/bin/"

Если у вас нет доступа к Sudo, вы можете использовать --prefix=/Users/myusername/bin и установить в свой домашний каталог. Не забудьте добавить ~/bin/ к $PATH

Сценарий x-git-update-to-latest-version автоматизирует многое из этого:

Этот скрипт обновляет мой локальный клон git-репо (локально по адресу ~/work/track/git), а затем настраивает, устанавливает (по адресу /usr/local/git-git describe) и обновляет символическую ссылку /usr/local/git.

Таким образом, у меня может быть /usr/local/git/bin в моем PATH, и я всегда использую последнюю версию.

Последняя версия этого скрипта также устанавливает страницы руководства. Вам нужно настроить свое MANPATH, чтобы включить каталог /usr/local/git/share/man.

33
dbr

Git Reset

Скажем, вы делаете тягу, объединяете ее с вашим кодом и решаете, что вам это не нравится. Используйте git-log или tig и найдите хеш, куда вы хотите вернуться (вероятно, ваш последний коммит перед извлечением/объединением), скопируйте хеш и выполните:

# Revert to a previous commit by hash:
git-reset --hard <hash>

Вместо хеша вы можете использовать HEAD ^ в качестве ярлыка для предыдущего коммита.

# Revert to previous commit:
git-reset --hard HEAD^
32
Dean Rather

Как настроить общий командный репозиторий?

Как настроить нормальное хранилище описано здесь - но как настроить командное хранилище, которое каждый может вытащить и толкать от и до?

Использование общей файловой системы NFS

Предполагая, что ваша команда уже имеет, например, членство в общей группе, которое можно использовать.

mkdir /your/share/folder/project.git
cd /your/share/folder/project.git
newgrp yourteamgroup # if necessary
git init --bare --shared

Чтобы начать использовать этот репозиторий, проще всего начать с локального репозитория, который вы уже использовали:

cd your/local/workspace/project
git remote add Origin /your/share/folder/project.git
git Push Origin master

Другие могут теперь клонировать это и начать работать:

cd your/local/workspace
git clone /your/share/folder/project.git

Использование SSH

Настройте учетную запись пользователя на целевом сервере. Используете ли вы учетную запись без пароля, учетную запись с паролем или используете authorized_keys, действительно зависит от вашего требуемого уровня безопасности. Посмотрите Настройка Git через SSH для получения дополнительной информации.

Если все разработчики используют одну и ту же учетную запись для доступа к этому общему репозиторию, вам не нужно использовать параметр --shared, как указано выше.

После запуска хранилища таким же образом, как описано выше, вы выполняете начальный Push следующим образом:

cd your/local/workspace/project
git remote add Origin [email protected]:/path/to/project.git
git Push Origin master

Видите сходство с вышесказанным? Кроме того, может произойти только то, что SSH запрашивает пароль, если у учетной записи есть пароль. Если вы получаете эту подсказку для учетной записи без пароля, сервер SSH, вероятно, отключил PermitEmptyPasswords.

Клонирование теперь выглядит так:

cd your/local/workspace
git clone [email protected]:/path/to/project.git
31
Asgeir S. Nilsen

git status ваш друг, используйте его часто. Хорошо для ответов на такие вопросы, как:

  • Что эта команда только что сделала?
  • На какой я ветке?
  • Какие изменения я собираюсь совершить, и я что-нибудь забыл?
  • Был ли я в центре прошлого, когда работал над этим проектом (дни, недели или месяцы назад)?

В отличие, скажем, svn status, git status запускается практически мгновенно даже в больших проектах. Я часто находил это обнадеживающим, когда учил git использовать его часто, чтобы убедиться, что моя ментальная модель происходящего была точной. Сейчас я в основном использую его, чтобы напомнить себе, что я изменил со времени моего последнего коммита.

Очевидно, это гораздо полезнее, если ваш .gitignore разумно настроен.

28
Peter Burns

Зафиксировать изменения

После того, как вы отредактировали файл, вам нужно зафиксировать свои изменения в git. Когда вы выполняете эту команду, она запрашивает сообщение о коммите - просто текст, который сообщает всем, что вы изменили.

$ git commit source/main.c

Зафиксирует файл main.c в каталоге ./source/

$ git commit -a # the -a flag pulls in all modified files

сохранит все измененные файлы (но не новые, они должны быть добавлены в индекс с помощью git-add). Если вы хотите зафиксировать только определенные файлы, вам нужно сначала поставить их с помощью git-add, а затем зафиксировать без флага -a.

Фиксация изменяет только ваш локальный репозиторий, но не удаленные репозитории. Если вы хотите отправить коммиты в удаленный репозиторий, вам нужно сделать Push.

$ git Push <remote> <branch> # Push new commits to the <branch> on the <remote> repository

Для кого-то из CVS или SVN это изменение, поскольку фиксация в центральном репозитории теперь требует двух шагов.

27
Adam Davis

Как вы ветвитесь?

Ветвь по умолчанию в репозитории git называется master.

Для создания новой ветки используйте

git branch <branch-name>

Чтобы увидеть список всех веток в текущем репозитории, введите

git branch

Если вы хотите переключиться на другую ветку, вы можете использовать

git checkout <branch-name>

Создать новую ветку и перейти на нее за один шаг

git checkout -b <branch-name>

Чтобы удалить ветку, используйте

git branch -d <branch-name>

Чтобы создать ветку с изменениями из текущей ветки, выполните

git stash
git stash branch <branch-name>
27
Markus Dulghier

Получение последней версии кода

$ git pull <remote> <branch> # fetches the code and merges it into 
                             # your working directory
$ git fetch <remote> <branch> # fetches the code but does not merge
                              # it into your working directory

$ git pull --tag <remote> <branch> # same as above but fetch tags as well
$ git fetch --tag <remote> <branch> # you get the idea

Это в значительной степени охватывает каждый случай получения последней копии кода из удаленного хранилища.

21
Jeremy Wall

Pro Git бесплатная книга определенно моя любимая, особенно для начинающих.

20
aldux

Git Magic это все, что вам когда-либо понадобится. Гарантировано или ваши деньги обратно!

18
Andrew

Я также нашел Git Internals очень полезным. Он написан Скоттом Чаконом (автором Pro Git и сопровождающим Git Community Book). Что мне нравится в Git Internals, так это то, что он фокусируется сначала на концепциях, а затем на командах , и, поскольку он составляет ~ 100 маленьких страниц, он быстро усваивается.

16
Jordan

Как вы сливаете ветви?

Если вы хотите объединить ветку (например, от master до release), убедитесь, что ваша текущая ветвь является целевой ветвью, в которую вы хотите слиться (используйте git branch или git status, чтобы увидеть текущую ветку).

Тогда используйте

git merge master

(где master - имя ветви, которую вы хотите объединить с текущей веткой).

Если есть какие-либо конфликты, вы можете использовать

git diff

чтобы увидеть ожидающие конфликты, вы должны разрешить.

16
Markus Dulghier

Как вы видите историю изменений в файле?

git log -- filename
13
Pierre-Antoine LaFayette

Как отследить удаленные ветки

Предполагая, что существует удаленный репозиторий, из которого вы клонировали свой локальный репозиторий, а также предполагая, что в этом удаленном репозитории есть ветвь с именем 'some_branch', вот как это отследить локально:

# list remote branches
git branch -r

# start tracking one remote branch
git branch --track some_branch Origin/some_branch

# change to the branch locally
git checkout some_branch

# make changes and commit them locally
....

# Push your changes to the remote repository:
git Push
12
innaM

Хорошая статья для понимания того, как работает Git: Притча о Git . Очень рекомендуется!

11
EricSchaefer

Как вы сравниваете две ревизии файла или ваш текущий файл и предыдущую ревизию?

Команда сравнения - git diff.

Для сравнения 2 ревизий файла:

$ git diff <commit1> <commit2> <file_name>

Различает commit1 против commit2; если вы измените порядок, то файлы будут отображаться наоборот, что может не соответствовать вашим ожиданиям ...

Чтобы сравнить текущий промежуточный файл с хранилищем:

$ git diff --staged <file_name>

Чтобы сравнить текущий неподготовленный файл с хранилищем:

$ git diff <file_name>
10
kret

Почему еще один Howto? В сети есть действительно хорошие, такие как git guide , что идеально для начала. Он имеет хорошие ссылки, включая git book , в который можно внести свой вклад (размещенный на git hub) и который идеально подходит для этой коллективной задачи.

На stackoverflow я бы очень хотел увидеть ваши любимые трюки!

Мой, который я обнаружил только недавно, это git stash, объясненный здесь , который позволяет сохранить текущую работу и перейти в другую ветку

Правка: как и в предыдущем посте, если вы действительно предпочитаете формат stackoverlow с постами в вики, я удалю этот ответ

9
Piotr Lesnicki

Консольный интерфейс - Tig

Правка:

apt-get install tig

Использование

Находясь в репозитории git, введите "tig", чтобы просмотреть интерактивный журнал, нажмите "enter" в любом журнале, чтобы увидеть больше информации о нем. час для справки, в которой перечислены основные функции.

Пустяки

"Tig" - это "Git" задом наперед.

9
Dean Rather

Как удалить ветку в удаленном репозитории?

Выполните Push на вашем пульте, используя : перед именем ветви

git Push Origin :mybranchname

Origin имя вашего удаленного и mybranchname имя ветви, которая будет удалена

http://help.github.com/remotes/

8
Felipe Sabino

Как создать ветку в удаленном репозитории?

Предполагая, что вы клонировали свой удаленный репозиторий из какого-то одного удаленного репозитория.

# create a new branch locally
git branch name_of_branch
git checkout name_of_branch
# edit/add/remove files    
# ... 
# Commit your changes locally
git add fileName
git commit -m Message
# Push changes and new branch to remote repository:
git Push Origin name_of_branch:name_of_branch
8
innaM

Я начал с официального учебник по Git . Я думаю, что это достаточно практично для начинающих (я был и все еще являюсь новичком, по вашему определению! Я с трудом разбираюсь в make-файлах, я лишь немного играл с Apache Subversion и т.д.).

8
hasen

Проверка кода

Сначала перейдите в пустой каталог, используйте "git init", чтобы сделать его хранилищем, а затем клонируйте удаленный репозиторий в свой.

git clone [email protected]:/dir/to/repo

Откуда вы изначально клонировали, откуда по умолчанию будет тянуть git pull.

7
Dean Rather

Нажмите и потяните изменения

В упрощенном виде просто выполните git Push и git pull. Изменения объединяются, и если есть конфликт, git сообщит вам, и вы можете решить его вручную.

Когда вы впервые отправляете Push в удаленный репозиторий, вам нужно сделать git Push Origin master (master - главная ветвь). С этого момента вы просто делаете git Push.

Нажмите теги с git Push --tags.

7
dylanfm
7
gngrwzrd

WRT хорошие графические интерфейсы/интерфейсы, вы также можете проверить qgit , который является кроссплатформенным (Linux/Win32) средством просмотра репозитория для Git и может также использоваться как интерфейс высокого уровня для наиболее распространенного Git операции, фактически это может быть легко улучшено с помощью так называемых "настраиваемых действий", так что пользователи могут предоставлять настраиваемые действия.

5
none

Что такое ребазинг?

Обоснование объяснения взято из книги Прагматическое руководство по Git - Travis Swicegood

Глава III

16 Переписывая историю, перебазируя

Перебазирование коммитов - это единственная концепция в Git, которая не имеет аналогов в традиционном мире контроля версий. Используя git rebase, вы можете переписать историю репозитория различными способами. Это одна из самых мощных команд в Git, что делает его одним из самых опасных.

rebase берет серию коммитов (обычно ветвь) и воспроизводит их поверх другого коммита (обычно последний коммит в другой ветке). Изменения в родительском коммите, поэтому все идентификаторы коммитов пересчитываются. Это может вызвать проблемы у других разработчиков, у которых есть ваш код, потому что идентификаторы не совпадают.

С git rebase есть простое правило: используйте его столько, сколько хотите на локальных коммитах. Как только вы поделились изменениями с другим разработчиком, головная боль, как правило, не стоит проблем.

5
Felipe Sabino

Ресурс : Обязательно посмотрите Gitcasts Скотта Чакона , особенно Railsconf Обсуждение.

Github это круто, а также есть некоторые полезные руководства .

5
dylanfm

Серьезно добавьте ссылку, указанную в ответ Тима в сообщении о переполнении стека Настройка Git Server с Msysgit в Windows .

Он безупречно рассказал мне, как настроить Git на Windows с помощью msysgit , и это невероятно подробная статья.

5
Jake

Я нашел этот пост очень полезным для начала. Мне все еще нужно прочитать книгу и другие ресурсы, но пост был полезен, как говорится в заголовке, "концептуальное понимание git". Я также рекомендую пройти курс Git & GitHub, предлагаемый по адресу RubyLearning .

4
tundal45

Еще один пункт, который я действительно считаю, должен быть в этом списке, вероятно, очень полезен для начинающих:

Не паникуйте

Что, если я сделал несколько коммитов, а затем сделал что-то страшное, например, может быть, что-то перебазировать, и теперь что-то - или даже все - кажется, потеряно? (Похоже, что Rebase - это то, что привлекает большинство людей в первый раз, поэтому я концентрируюсь на этом. Хотя git rebase --abort очень помогает, иногда вы обнаружите, что вы испортили редактирование, например, во время интерактивной перебазировки, и позволяете перебазируй финиш, и теперь ты хочешь вернуть свои старые вещи. А потом есть такие вещи, как filter-branch...)

Один из ключевых принципов git заключается в том, что он никогда не удаляет все, что вы зафиксировали. ("Что, никогда?" "Нет, никогда!" "Что, никогда?" "Ну, вряд ли когда-либо!") Если вы не запускали git gc, он все еще там. Это может занять некоторое время, чтобы найти вашу предыдущую работу, но если вы выполнили несколько успешных git commits ранее, то, например, даже ваша явно разрушенная серия коммитов из-за трагической ошибки rebase все еще там, обычно в течение по крайней мере месяца (технически, пока не истечет срок действия "reflogs").

Важно помнить, что имя каждой ветви помечает или указывает на "фиксацию". Это смешные цифры, такие как 7cc5272. Многие вещи, которые вы делаете, такие как добавление нового коммита в ветку, заставляют имя ветки указывать на новый, новый коммит-ID. Каждый коммит-идентификатор имеет ссылку, указывающую на некоторые предыдущие коммит-идентификаторы, и именно это фактически составляет "ветку", полную коммитов.

Запись rebase говорит о "переписывании истории", и такие команды, как git filter-branch, также "переписывают историю", но они делают это не путем уничтожения предыдущей истории, а путем добавления новой истории. Как только новая история появится, git "переместит метки вокруг" так, чтобы она похоже история изменилась. Если вы находитесь в своей ветке fix-nasty-bug и делаете git rebase, и вам удается что-то разрушить, ярлык fix-nasty-bug теперь ссылается на обломки, но исходные версии все еще там. В частности, Rebase создает временную (неподвижную, не ветвящуюся) метку с надписью ORIG_HEAD, которая позволяет вам их найти. Команда filter-branch также сохраняет все исходные имена. В некоторых случаях не может быть очевидного имени, но коммиты всегда можно найти. Если необходимо, найдите себе "гит-гуру" и объясните, что вы сделали, что привело к обломкам.

(Команда git reflog show также может помочь в поиске идентификаторов коммитов.)

Если вы нашли то, что, по вашему мнению, является частью или все ваши предыдущие работы, попробуйте:

git log <commit-ID>   # ORIG_HEAD after a bad rebase, for instance
git show <commit-ID>  # or some long SHA1 value you can still see in a window

Если это выглядит правильно или полезно, введите имя:

git branch recover-my-stuff ORIG_HEAD

и все снова возвращается! Фактически, теперь и ваш плохой ребаз, и ваша оригинальная работа находятся в вашем git-репо "навсегда" (или, по крайней мере, до тех пор, пока вы не удалите имена веток и пусть пройдет несколько месяцев, и тогда они получат сборщиком мусора). Вы можете поместить столько имен в столько восстановленных коммитов, сколько захотите. (Имена ветвей практически бесплатны, за исключением того, что они загромождают вывод git branch, и, конечно, они также предотвращают сборку мусора коммитами. Вы также можете, или вместо этого, размещать теги на определенных идентификаторах коммитов, если вы предпочитаете их.)

4
torek

Очень хороший пост о слиянии с конфликтами - GitGuys: Слияние с конфликтом - конфликты и разрешения

Блог действительно великолепен - нагляден, понятен и понятен. Определенно стоит проверить.

0
rdamborsky