Простая последовательность команд GIT

Question

Я прочитал документацию и неплохо поработал в googled, но нет реальных простых шагов, чтобы иметь возможность совершать локальные изменения в github. Я составил следующие шаги, и я просто хочу убедиться, что вы поступаете правильно. Если я изменил файл foo.java локально:

1. статус мерзавец -s                   // покажет мне, что foo.java изменилось

2. мерзавец добавить foo.java         // добавит его в мой местный репо

3. Git совершающие -m "мои изменения"           // обязательство местного репо

4. мерзавец тег "v1.1"             // создать тег

5. git push -tags               // наконец, переместите локальную фиксацию на дистанционное репо с новым тегом. это потребует вашего пароля. если нет тега не установлен, как в шаге 4, а затем просто

мерзавец толчок

достаточно. правильно?

Я просто пытаюсь убедиться, что эти основные шаги для большинства случаев использования - это то, что требуется для использования github. Я новичок в github, и эти шаги работают для меня, но я хочу убедиться, что я не делаю никакой фундаментальной ошибки. Прокомментируйте, если есть какие-либо недостающие шаги. Опять же, я обеспокоен самым общим повседневным использованием (например, я действительно не беспокоюсь о филиалах и т. Д., Которые я буду изучать на основе потребностей). Заранее спасибо.

Answer 1

Ваши шаги в порядке. Немного опишите комментарий:

Замечания о шагах (2) и (3) - это не лучший способ подумать о том, что происходит, я не верю.

2.git add foo.java  //will add it to my local repo 
3.git commit -m "my changes"  //commit to the local repo 

шаг, который «добавляет» файл в локальное хранилище является git-commit. Вот почему он называется commit; вы совершите изменений в репозитории. git-add foo добавляет foo в промежуточная область, не к самому репо.

Ваш git хранилище имеет три «зоны», working, staging и repository, изображенные здесь (изображение взято из Pro Git book):

внесении изменений и работу в творчески названием «рабочий каталог ».

Когда вы внесли некоторые изменения, вы хотите подготовиться к совершению фиксации. Здесь начинается «зона постановки». Вы «сценируете» изменения, которые хотите совершить, и когда вы будете довольны тем, как будет выглядеть фиксация, вы передаете «промежуточную область» в «репозиторий». [Примечание: на страницах man этот staging area в основном относится к index].

Это позволяет вам проявлять большую гибкость. Вы можете выполнить все изменения с момента последнего фиксации, или вы можете создавать отдельные файлы, или вы можете создавать части файлов. Вы можете добавлять и удалять файлы из промежуточной области без потери изменений или испортить историю репозиториев. Вот что делают команды git add и git rm; они добавляют от working directory к staging area, но они не добавляют непосредственно в repository. (Надеюсь, что изображение поможет сделать различия четкими).

Ваши действия в порядке. Если вы хотите больше узнать о ветвях, совершении, манипулировании фиксациями и ветвями и о многом, я бы рекомендовал прочитать Pro Git book - у него есть целая куча хороших фотографий и языка, достаточно простых, чтобы я мог это понять;)

Answer 2

После (3), вы должны быть в состоянии назвать git push origin master, который будет толкать ваш текущий master филиал в Github

Answer 3

Я думаю, что этого достаточно для очень основного использования. Я просто хотел бы добавить два комментария:

• Это всегда хорошая вещь, чтобы проверить, что вы добавляете в промежуточной области (это то, что вы делаете с git add): либо использовать git diff, или сделать a git add --patch, который начнет интерактивную процедуру, позволяющую вам решить, принимать или отклонять каждый hunk измененного вами кода. Если вы перепутали что-либо на этой фазе, вы всегда можете вернуть git reset HEAD, чтобы получить изменения в рабочей копии (то есть вы просто отмените добавление)
• Возможно, вы захотите сделать шаги 2 и 3 вместе, выпустив git commit -a -m 'your message'.