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

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

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

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

Так:

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

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

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

Другой

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

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

Копаться в Git

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

Источник

37 ответов

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

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 - если это не репозиторий, он сообщит "роковое: не репозиторий git"

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

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

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

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

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

Источник

GUI для git

Git GUI

В комплекте с git- Run 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

Намеревается стать "клоном гитка для OS X".

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

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

Оригинальная версия git-репозитория недавно не обновлялась (более года на момент написания). Более активно поддерживаемая ветвь доступна в https://github.com/brotherbard/gitx - она ​​добавляет "боковую панель, извлечение, извлечение, толчок, добавление удаленного, объединение, выбор вишни, ребазирование, клонирование, клонирование в"

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

Загрузки

Katana

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

С первого взгляда посмотрите, в какие удаленные ветви нужно вносить изменения, а в локальные репозитории нужно вносить изменения. Поддерживаются git-ops add, commit, push, pull, tag и reset, а также визуальные различия и визуальный просмотр истории проекта, которая выделяет локальные изменения и дополнения.

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

Скачать

Росток (ранее 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

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

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

Скачать

Большое спасибо dbr за разработку git gui.

SourceTree

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

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

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

Скачать | Веб-сайт

Источник

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

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

Источник

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

Возможность заставить 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 является лучшим источником дополнительной информации.

Источник

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

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

С использованием 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)

Источник

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

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

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

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

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

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

простой рабочий процесс

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

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

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

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

Источник

Вот копия поста 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 git@github.com:pjhyett/foo.git
# make your changes
$ git commit -a -m "my first commit"
$ git push

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

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

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

Источник

Как установить 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 каталог.

Источник

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^
Источник

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

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

Использование общей файловой системы 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 user@server:/path/to/project.git
git push origin master

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

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

cd your/local/workspace
git clone user@server:/path/to/project.git
Источник

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

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

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

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

Источник

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

Ветвь по умолчанию в репозитории 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>
Источник

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

После того, как вы отредактировали файл, вам нужно зафиксировать свои изменения в 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 это изменение, поскольку для фиксации в центральном репозитории теперь требуется два шага.

Источник

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

$ 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

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

Источник

Книга Pro Git, безусловно, моя любимая, особенно для начинающих.

Источник

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

Источник

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

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

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

git merge master

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

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

git diff

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

Источник

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

Источник

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

git log -- filename
Источник

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

Предполагая, что существует удаленный репозиторий, из которого вы клонировали свой локальный репозиторий, а также предполагая, что в этом удаленном репозитории есть ветвь с именем '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
Источник

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

Источник

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

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

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

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

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

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

$ git diff --staged <file_name>

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

$ git diff <file_name>
Источник

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

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

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

РЕДАКТИРОВАТЬ: как и в предыдущем посте, если вы действительно предпочитаете формат stackoverlow с постами в вики, я удалю этот ответ

Источник

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

Монтаж:

apt-get install tig

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

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

пустяки

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

Источник

Как я могу создать ветку в удаленном хранилище?

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

# 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
Источник

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

Источник

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

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

git push origin :mybranchname

являющийся origin название вашего пульта и mybranchname название ветви, которая должна быть удалена

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

Источник

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

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

git clone user@host.com:/dir/to/repo

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

Источник

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

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

Когда вы впервые отправляете в удаленный репозиторий, вам нужно сделать git push origin master (мастер является основной ветвью). С тех пор вы просто делаете git push,

Нажмите теги с git push --tags,

Источник

Gity: http://macendeavor.com/gity

Источник
Другие вопросы по тегам