Git *

Добро пожаловать в GitHub Reflog — еженедельную хронику замечательных репозиториев GitHub и активности сообщества. Предыдущие выпуски доступны в Архиве Reflog.

На этой неделе выпущен альфа-релиз плагина для подключения GitHub к Mylyn для Eclipse. Если вы не знакомы с проектом Mylyn — это набор плагинов, добавляющих ​​поддержку работы с системами управления задачами, системами сборки и инструментами ревизии кода внутри Eclipse IDE.

C «Запросами на пулл 2.0» стало легче, чем когда-либо, делать проверку кода и принимать патчи. Мы широко используем этот механизм на GitHub, и я люблю его применять в моих открытых проектах.

Взять, к примеру, запрос на пулл по исправлению документации в God:


Традиционно, это слияние запроса на пулл требует множество шагов с помощью командной строки Git. Но больше это не так!

Добро пожаловать в The GitHub Reflog — еженедельную хронику замечательных репозиториев на GitHub и активности открытого сообщества. Предыдущие выпуски вы сможете найти в Архиве Reflog либо в Архиве русскоязычной версии Reflog.

Добро пожаловать в четвертое издание GitHub Reflog — еженедельную хронику замечательных репозиториев на GitHub и активности сообщества. Предыдущие изданиях можно получить в архиве Reflog.

Система управления проектом: последний рубеж. Почти два года назад в этот день, GitHub запустил трекер задач (issue tracker). Некоторые люди его полюбили, некоторые люди возненавидели его, — но давайте не будем обращать внимание на прошлое (мы живем в будущем, так как наше настоящее в прошлом). Давайте поговорим о версии Issues, которые запускаются сегодня.

Парни из EdgeCase создали сайт gitimmersion.com, посетив который вы сможете познать фундаментальные азы Git, там предлагается пройти курс из 52 шагов, в каждом из которых описываются разные аспекты использования Git. Так, переходя от простого к сложному, можно влиться в число активных пользователей этой VCS.

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

Программист Ману Спорни (Manu Sporny) секвенировал свой геном с помощью инструментов 23andme и выложил его в репозиторий под лицензией Creative Commons Public Domain.

Конечно, опубликован не весь геном, а только 966 977 маркеров SNP, то есть тех участков генома, которые отвечают за индивидуальные особенности каждого человека.

Имея программный проект с компилируемым языком программирования возникает задача имея исполняемый файл определить из каких исходных кодов он был собран. В данной статье мы опишем как автоматизировать добавление коммита в исполняемые файлы и как по нему в дальнейшем получить исходный код.

Перевод статьи Vincent Driessen: A successful Git branching model

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



В качестве инструмента управления версиями всего исходного кода она использует Git.

Я давно уже начал писать эту статью, но меня опередили (8.
Основная задумка была объяснить братьям флэшерам как работать с git. В статье я попытался описать свой личный опыт, а не просто перечислить очевидные плюсы git. Поэтому она будет полезна всем.

В первую очередь буду рад дополнениям и исправлениям. И конечно же вопросам.

Что такое git

git — это распределенная система контроля версий. Отличается от SVN отсутствием необходимости в центральном репозитории (который все же хорошо было бы держать) и легкостью работы с ветками (branch). Изначально я решил попробовать его в работе прочитав эту статью, что всем рекомендую.

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

Было время, когда я ничего не знал про VCS, ни что это такое, ни тем более зачем это мне. И верхом своих достижений считал папочку с архивами версий. К моменту осознания необходимости системы контроля версий я уже набил шишек и прочувствовал необходимость такого инструмента. Но борландовский аналог CVS меня не впечатлил. У каждого файла свой номер версии. Как мне получить срез определенного релиза я так и не разобрался. А в это время SVN победоносно шла сквозь умы разработчиков. Черт, это было то, чего мне так не хватало. Прочитав доку и начав работать я просто влюбился в нее. Да, были трудности и определенные неудобства, но куда без них.
Так я и работал бы в SVN, но ничего не стоит на месте. В интернете уже потекли тонкие ручейки новостей про Git. Я не кидаюсь за каждой новой технологией, и прошло уже достаточно много времени, пока мне не прожужжали этим Git’ом все мозги. Мне стало любопытно, я вначале присматривался, примерялся, а потом плюнул и начал новый проект на Git. Мучался с ребятами 2 недели, накачал литературы, написал шпаргалку… ничего, привыкли, … а потом меня поперло.

Теперь меня регулярно просят рассказать про Git и что в нем такого. Уже надоело, поэтому этот пост для тех, кто еще сомневается.

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

Наверняка, каждый из нас сталкивался с ситуацией, когда вместо внятного комментария к коммиту хочется написать очередной «асдфасдф». Что касается меня — так я частенько впадаю в такое состояние.

У меня для вас 2 хороших новости!

1. Хорошие люди придумали для таких целей сайт http://whatthecommit.com/.
2. Под впечатлением от этого проекта я написал шуточный прокси для git'а, который умеет добавлять в ваш коммит случайное сообщение.

Допустим мы храним данные на некотором удалённом сервере в Bare-репозитории.
Если есть сомнения в честности обслуживающего сервер персонала, или мы опасаемся, что кто-то сопрёт наш проект, можно зашифровать избранные секретные файлы, представляющие особо секретные технологии фирмы и тем самым затруднить клонирование проекта.

Я не буду обсуждать согласование описываемого ниже метода с политикой и лицензионным соглашением бесплатных Git-репозиториев (а ля GitHub) — это дело частностей и вашей совести.

В реализации мы всопользуемся .gitattributes, staging, filters (фильтрами) и главой 7.2 Pro Git Book.

При работе с git под windows не покидало ощущение, что чего-то не хватает, не столь комфортно с ним работать как на других системах.
Оказывается, в msysgit по умолчанию отключен цветной вывод.

Вместо предисловия...

Мне давно хотелось отсматривать код примерно как это сделано в meld, но только в консоли, и еще мне хотелось чтобы это все было увязано с системой управления версиями файлов GIT. В общем чтобы все делалось 1 кнопкой не выходя из mc.

Ydiff

Однажды у нас на канале (или это было на траке...) проявился некто Daniel Borca пошумел-пошумел и убежал, видимо не понравилась ему наша бюрократия, но зато оставил он после себя несколько сыроватых патчей, к готовившемуся релизу 4.7.0-pre1 миднайт коммандера. Один из них содержал в себе ydiff.[ch] и zdiff.[ch]… Как оказалось, то что я хотел получить, было давно уже реализовано в древнем форке mc-mp и в последней версии ru-fork. После 2-х дневного «перепиливания» я подключил функцию сравнения файлов к последней версии mc… Полдела было сделано. :)

Я, как и многие программисты, после знаменитого выступления Линуса Торвальдса о Git на Google Talks заинтересовался распределенными системами управления версиями, а в особенно Git.

Я довольно таки свободно читаю на английском, но мне приятнее читать на русском языке, при условии нормального перевода.
Существует замечательная книга «Git Magic» Бена Лина (Ben Lynn).
Благодаря труду многих людей вышел первый черновой вариант этой книги. Всех желающих улучшить перевод — приглашаю под кат.

Уже было несколько статей, где авторы рассказывали о том как скрасить консольные будни с git. В последней приведенной ссылке автор предлагает создавать алиасы, для работы c git, непосредственно в shell. Это не очень хороший способ, хотя бы потому, что, например алиас gc будет конфликтовать с одноименной командой пакета graphviz. git сам прекрасно умеет работать с собственным алиасами.

Недавно знакомый Андрей (совсем недавно перешел на программирование под линукс) хотел создать новую ветку в git-е, но не был уверен в параметрах и хотел посмотреть подсказку. Он выполнил комманду с логичными, как ему показалось, параметрами:

git checkout -b --help

Как думаете что сделала эта комманда? Правильно, создала ветку с именем --help=)

Switched to a new branch '--help'

Ну не проблема, удалим её.

git checkout master
Switched to branch 'master'
git branch -d --help

Но не всё так просто. Результатом последней комманды был вывод помощи по утилите git branch.

Хм. Ладно, попробуем переименовать ветку и затем удалить ее.

git branch -m --help todo_remove

И как вы уже догадались, эта комманда тоже напечатала краткую помощь по использованию git branch.

А вы сходу придумаете как удалить её?

Как избавится от ветки и неожиданое продолжение истории под катом.