Как начать пользоваться git?

git add .
git commit -m «тут ещё придумай что написать»
git push
то есть, получается так, что работа с git отнимает до 50% от всей работы с кодом

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

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

Большинство нормальных редакторов кода имеют встроенную интеграцию с git.

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

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

и это вот git commit -m «добавлена фича Х» — не получится так сделать. не получится отделить что ты добавил фичу от сотни других минорных внесённых изменений в проект.

не получится отделить

Ну если в гойлове бардак, то не гит в этом виноват.

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

Ну там диффы же. Вряд ли ты полностью перелопатил кучу файлов, чтобы size(диффы) ~ size(сам код). Кстати, освой команду git diff - сам всё увидишь

GitKraken в помощь

1. https://github.com/tpope/vim-fugitive
2. https://github.com/jonas/tig
3. Алиасы

-m неудобен при коммитах, лучше в редакторе набирать.

Lazygit.

то есть, получается так, что работа с git отнимает до 50% от всей работы с кодом.

Нет.

Есть magit в емаксе, есть встроенная поддержка в различных IDE. Команды в терминале будешь набирать только в особо запущенных случаях.

есть тьма всяких git-клиентов. Lazygit, tig, всякие плагины для редакторов, и т.д. и т.п. Лично я пользуюсь sublime merge для простых операций. Всякие интерактивные rebase - только в консоли, но такое редко бывает нужно.

алиасов в баше наделать или как?

такое тоже есть, например https://github.com/joseluisq/gitnow для fish

то есть, получается так, что работа с git отнимает до 50% от всей работы с кодом.

Только первые пол года, потом привыкаешь :)

почему нельзя просто мышкой перетащить файлики куда-нибудь там, и чтобы оно просто само сделало эти add commit push?

В IDE так и работает, все автоматом add.

как вы работаете с git? как всегда иметь перед глазами всю структуру .git каталога чтобы видеть с чем конкретно ты работаешь? вот чтобы захотел, тыкнул в любое место в структуре .git, открылся vim и редактируешь себе ветку.

Так такой проблемы небыло раньше, в том же SVN если нужна была работа в отдельной ветке то выкачиваешь её в отдельный каталог и открываешь в IDE как еще один проект, как видишь с git удобнее.

перед глазами всю структуру .git

Просто чтоб посмотреть все дерево истории я использую либо IDE, либо gitk --all

Все алиасы что у меня есть:

$ cat ~/.gitconfig 
[alias]
	br = branch
	co = checkout
	st = status -sb
	l = log --graph --pretty=format:'%Cred%h%Creset %C(bold blue)<%an>%Creset%C(yellow)%d%Creset %s %Cgreen(%cr)' --abbrev-commit --date=relative

1) git не нужен, используй svn

2) у svn те же проблемы с командной строкой (хотя команд надо меньше вводить), поэтому я себе сделал к нему костыль и положил как ~/bin/ci и когда надо закоммитить пишу просто «ci»:

(это две старые версии, в одной просмотр диффа делается с помощью mcedit, в другой с помощью самописной проги для highlight-а + kess -r, сейчас использую свой просмотрщик сразу с хайлайтом и интерактивным задаванием вопроса коммитить или нет)

#!/bin/sh -e

if [ "q$1" = "q" ]; then
  MESSAGE="commit"
else
  MESSAGE="$1"
fi

#REPOROOT=`pwd`
# svn behaves badly when $REPOROOT contains symlink
REPOROOT=`realpath .`
cd $REPOROOT

/usr/bin/svn add --force .
/usr/bin/svn status "$REPOROOT" | /usr/local/bin/svn-autoremove 2>&1
/usr/bin/svn up "$REPOROOT"

if true; then
  NAME=`mktemp --tmpdir tmp.XXXXXXXX.diff`
  (echo "diff list:" && svn diff ) >> "$NAME"
  mcedit "$NAME"
  rm "$NAME"
else
  (echo "diff list:" && svn diff ) | hldiff | less -r
fi
echo "press ctrl-c to cancel or enter to continue"
read x

echo ">>> Commiting"
/usr/bin/svn ci "$REPOROOT" -m "$MESSAGE"
echo ">>> Commit done"

svn-autoremove.c (написан давным давно и далеко не идеален, но всегда работал корректно)

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <errno.h>
#include <assert.h>
#include <unistd.h>
#include <sys/wait.h>

extern char **environ;

static void del_file(char const * fn) {
  int r, status, wr;
  char * argv[4];
  printf("delete %s\n", fn); fflush(stdout);
  r = fork();
  if(r<0) { fprintf(stderr, "ERROR: fork() error %d (%s)\n", errno, strerror(errno)); return; }
  if(!r) {
    argv[0] = "/usr/bin/svn";
    argv[1] = "delete";
    argv[2] = (char*)fn;
    argv[3] = NULL;
    execve(argv[0], argv, environ);
    _exit(-1);
  }
  while(1) {
    wr = waitpid(r, &status, 0);
    if(wr<0 && errno==EINTR) continue;
    if(wr<0) fprintf(stderr, "ERROR: waitpid() error %d (%s)\n", errno, strerror(errno));
    break;
  }
}

/*
  states:
  0 = just newline, look for "!" symbol next
  1 = no "!", just skip all until next newline
  2 = was "!", skipping until "/"
  3 = saving filename
 */
#define FNMAX 1024
int main(int argc, char * * argv) {
  char buf[1024], fn[FNMAX], c;
  unsigned int state;
  int p, r, fnlen;

  state = 0;
  while(1) {
    r = read(0, buf, sizeof(buf));
    if(!r) return 0;
    if(r<0) return -1;
    for(p=0; p<r; p++) {
      c = buf[p];
      switch(state) {
      case 0:
        if(c=='\n') state=0; else if(c!='!') state=1; else state=2;
        continue;
      case 1:
        if(c=='\n') state=0;
        continue;
      case 2:
        if(c=='\n') state=0;
        else if(c=='/') { state=3; fn[0]='/'; fnlen=1; }
        continue;
      case 3:
        if(c=='\n') {
          assert(fnlen<FNMAX);
          fn[fnlen] = 0;
          del_file(fn);
          state = 0;
          continue;
        }
        if(fnlen>=FNMAX-1) { fprintf(stderr, "ERROR: filename to long, skipping\n"); state=1; continue; }
        fn[fnlen++] = c;
        continue;
      }
    }
  }
}

то есть, получается так, что работа с git отнимает до 50% от всей работы с кодом.

ну бред. ну просто бред

самсебеответил Spoofing

извините, но каждый раз держать открытое окно, каждый раз печатать

git add .

git commit -m «тут ещё придумай что написать»

git push

то есть, получается так, что работа с git отнимает до 50% от всей работы с кодом.

Ты пушишь каждую минуту? Ну и да, используй нормальную IDE, где не нужно ничего писать, а только тыкать кнопочки. Абсолютно надуманная проблема.

бывает куча изменённых мелких файлов с незначительными исправлениями

git add -p, и отдельные коммиты на наборы/группы изменений.

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

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

вот все смеются над вимерами

Кто «все»?

Как начать пользоваться git?

1) git не нужен, используй svn
2) у svn те же проблемы с командной строкой (хотя команд надо меньше вводить), поэтому я себе сделал к нему костыль ...

[какая-то лютая портянка на сях]

ЛОР торт!

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

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

git commit -m «добавлена фича Х» — не получится так сделать

Почему это? Делаешь add нужным правкам, коммитишь фичу/фикс/что там у тебя. Повторяешь по необходимости.

Кто «все»?

Емаксеры, кто ж еще. Все беды от емаксеров.

то есть, получается так, что работа с git отнимает до 50% от всей работы с кодом.

ну бред. ну просто бред

Это ты свое предыдущее высказываение критикуешь? Тогда согласен.

Осиль уже SourceTree и прочие клиенты. Лично я себе не представляю работу без него. Нахер это надо мудохаться в терминале с этими командами, я терминал открываю для гита раза два в месяц, всё остальное прекрасно решается в таких клиентах под Mac/Win, а кто красноглазит в терминале - ССЗБ

Есть такая замечательная команда git commit <file>, пользуйся

Емаксеры, кто ж еще.

Им некогда говорить, а то ещё газ с тормозом перепутают и в аварию попадут.

Начинать работу с гитом в 2022 году уже поздновато. Сегодня это базовое требование от разработчика. И как верно сказали многие - проблема не в инструменте, а в том как он используется. Собирать в один комит несвязанные изменения, комитить каждую строчку или раз в год - все это одинаково плохо. В разработке должен быть порядок. И в первую очередь в голове.

то есть, получается так, что работа с git отнимает до 50% от всей работы с кодом.

Если оно реально столько времени отнимает, то у меня для тебя плохие новости :)

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

Проблема в тебе, а не гите.
А зачем тебе гит?

git-cola. Видишь изменённые файлы, видишь для каждого файла изменённые строчки. Можешь надёргать в коммит построчно только правки, которые к нему относятся. Даже если ты сделал несколько разных по смыслу правок в одном файле.

Есть поле ввода для заголовка/сообщения коммита. Тулза простая, но рутинные операции с гитом сильно облегчает.

Тебя в гугле забаннили? В гит есть алиасы

git config –global alias.acp ‘!f() { git add . && git commit -m «$@» && git push origin HEAD; }; f’

Хочется указать на очевидные интеграции IDE с гитом, но зачем, если пишешь ты макароны на шелле :^)

Sublime Merge

https://wiki.archlinux.org/title/Gitfs :)

вот, это уже больше похоже на правду.

спасибо.

скорее всего, это именно то, что мне нужно.

потому что хороший инструмент тот, на работу которого не обращаешь внимания.

тут ещё придумай что написать

Так это обоснование всей проделанной работы. Через полгода ты будешь искать, что и где менял.

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

commit нельзя совместить с push потому, что… впрочем, вру. Можно. В svn так и сделано. И у этого подхода есть преимущество, он проще и в некотором смысле надёжнее. Зато git позволяет тебе взять локальную репу в путешествие на флешке и коммитить по мере надобности. Когда вернёшься в зону доступности центрального репозитория — сделаешь один push, и не надо помнить содержание всех коммитов. (И это только если рассматривать разработку в одну харю, при коллективной работе с ветками всё ещё интереснее.)

Ежели тебе всенепременно нужна мышка — посмотри интеграцию git в существующие IDE.

Вообще, прочтение ОП оставляет ощущение, что: 1) ты наезжаешь не конкретно на git, а на концепцию VCS в целом; 2) VCS ты пользуешься вынужденно, не видя, какие преимущества он даёт. По доброй воле к VCS приходит программист, который осознал, что самое ценное, что у него есть — это исходники, и история этих исходников ему тоже важна. Если этот программист периодически пакует свои исходники и хранит не только последний архив — он уже готов к принятию VCS, ему осталось только осознать, что с VCS то же самое делается быстрее и в последующем облегчает поиск. Если нет — VCS ему обычно навязывает руководство проекта, и это намного хуже. Такой программист зачастую пытается обойти работу VCS, например, отлаживать код где-то за пределами рабочей копии, а потом руками перед коммитом копировать изменённые файлы, и др.

Нетривиальный момент — когда делать коммиты. Вот тут, конечно, не надо бросаться в крайности. Обычно коммит делается по завершении какого-то связного изменения, которое можно описать в терминах предметной области, добавление новой возможности. Или исправления какой-то конкретной ошибки из багтрекера. Спорный случай — чистка кода, рефакторинг, вот тут возможны варианты. В общем, в некотором роде искусство, которым надо овладеть.

Если же у тебя на команды git уходит столько же время, сколько на написание кода — ты явно что-то делаешь не так. И боюсь, проблема у тебя не в инструментах и не в командной строке.

Берите какой-нибудь VsCode и там будет поддержка Git из коробки. Никаких команд писать не надо.

Да и не только VsCode, по-моему, у большинства IDE в наше время VCS-интеграция есть…

Я пока ничего лучше VsCode в плане интеграции с Git не видел из свободного ПО.

Лол, эт ты еще фильтров и сабмодулей не видел. Вот там ад. А add/commit это норма

Установи gui оболочку для git. Я пользуюсь smartgit. Бесплатная для не коммерческого использования. Всё понятно и наглядно. Есть два основных окна: текущие изменения и дерево коммитов. Я их открываю бок о бок и норм.

я сам не знаю чего я хочу.

Весь пост можно было сократить до этой строчки. А ещё лучше вообще его не писать.

u.sh
#!/bin/sh

git add .
git commit -m update
git push

то есть, получается так, что работа с git отнимает до 50% от всей работы с кодом.
ну бред. ну просто бред

Самокритично.

почему нельзя просто мышкой перетащить файлики куда-нибудь там, и чтобы оно просто само сделало эти add commit push?

Потому что надо понимать какие изменения ты пушишь куда и зачем.

я явно делаю что-то неправильно.

Вот смотри, тебе надо сделать фичу. Ты её делаешь. Потом переделываешь n раз и получается жопа. Тебе надо откатится на 2-3 версии назад. А ты не делал пуш. А ты не делал нормальные коммиты. У тебя вместо понятных итераций мешанина из говна и пустых строк. У тебя все изменения за неделю одним коммитом, ты просрал пару итераций из-за этого и затёр кучу всего. Ты просто не можешь откатиться на версию m. Вот и думай зачем тебе нужен гит, как правильно с ним работать и почему это важно.

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

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

потому что хороший инструмент тот, на работу которого не обращаешь внимания.

Угу. Удачи потом восстановить рабочий снапшот кода из того поноса, который останется после гитфс.
Прикол коммита в том, что он после него у тебя консистентное состояние кода, Карл. Коснистентное. А в гитфс у тебя на 3 сохранения каждого файла по коммиту, которые никак не связанный лочически. В результате выйти на консистентное состояние кодовой базы просто нетривиально, ты будешь сидеть, откатывать файлы по одному, пытаться их мержить и виноват будет опять гит.

Забыл добавить в первый абзац: и на один commit у тебя может прийтись несколько add-ов, а может и ни одного add-а, если ты правил только уже существующие файлы. Я это опять-таки к тому, что дело в том, что это В ПРИНЦИПЕ разные действия, а не в том, что командная строка, консоль и т.д. И ты должен понимать, какое действие ты выполняешь.

Ну и возможно, тебе вместо написания этой портянки следовало просто вбить в яндекс «интеграция vim и git», там много интересного, вот такая, например, статья с хабра.

Я работаю в Qt Creator, там интеграция с git есть из коробки. Однако я всё равно время от времени ловлю себя на том, что норовлю делать коммиты из konsole — коммит это ритуал, который я хочу проводить без посредников, с полным пониманием того, что я делаю. Хотя в Qt Creator интеграция сделана довольно удобно, вызываешь пункт меню, тебе вываливают список изменённых файлов, можно убрать ненужные, можно по каждому файлу отдельно посмотреть diff, тут же задать комментарий для коммита. Add при создании исходных файлов средствами IDE делается автоматически. Да в принципе, в большинстве современных IDE примерно так же, КМК.

если в гойлове бардак, то не гит в этом виноват

Подпишусь под каждым словом.

Spoofing, одно изменение (не важно в скольких файлах, не важно каких объёмов — это одно изменение для решения одной задачи/проблемы) — один коммит.

Лорчую!

одно изменение (не важно в скольких файлах, не важно каких объёмов — это одно изменение для решения одной задачи/проблемы) — один коммит.

+100500

git commit -m update

Расстрелять.

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