[вернуться назад]

Git rebase vs git push

19 Июнь, 2013

When several developers work on the same part of code there often could be conflicts. These conflicts have to be resolved manually while merging. It is very boring and useless procedure.

Most common way to avoid this — make branches. But what if our development process is stressed and we have to merge couple times a day to load testers with work? In this case we could avoid conflicts and merge mostly automatically with git rebase.

How it works?

Git rebase puts your local commits into temporary area and then resets to the last commit on upstrean (remote repository). Then it applies local commits one by one. This makes local changes to overwrite all differences in remote repository if any. This is dangerous part of such operation. so be careful and apply changes made by most experienced programmer last. 🙂  But if local changes in some file are wrong you could reset it to right commit very quickly.

Another problem is that your commit log history will be changed. But if you do merging once a day or more this is not a big problem from my point. That’s why I tell my programmers to make

git fetch; git rebase; git push

fetch updates your index with remote updates w/o merging.
rebase tries to apply local commits on top of remote ones
push writes the result to remote repo

instead of straightforward git push. Since using git push in concurrent development environment could lead to many merge conflicts.

P.S. To understand more about this read git man pages. (git rebase —help)

Онлайн заявка

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