GIT commit strategy

GIT commit strategy

[Vadim K.]

Hello all,

    Imagine developer A has changed files f1 and f2, then made commit and 
push to the server
    Developer B has changed files f2 and f3 and made local commit.

    Next B wants to publish changes to the server and make pull to resolve 
conflicts at f2.  After pulling from the server it has all 3 files - f1, f2 
and f3 to commit before push. But B did not changed f1 and actually can 
"ban" this change if he commits only f2 and f3 - files that were changed by 
him. In latter case after pushing to the server GIT will restore previous 
version of the f1, even if it has more recent one !! It does not seem to be 
very logical.

    Question: is it possible to show to the developer only files, that he 
changes? Like in SVN - after updating from the server developer must resolve 
conflicts (if any) and only commits changes that he has made. By the way - 
in a case of non-conflicting files (let me say A changes f1, B changes f2) 
GIT makes commit automatically and does not show to the B, that f1 was 
changed and need to be re-commited. B only need to push the change back.

Thank you,

Vadim. 

Re: GIT commit strategy

[Michael Witten]

2011/8/16 Vadim K. <klug@hot.ee>:
> Hello all,
>
>   Imagine developer A has changed files f1 and f2, then made commit and push
> to the server
>   Developer B has changed files f2 and f3 and made local commit.
>
>   Next B wants to publish changes to the server and make pull to resolve
> conflicts at f2.  After pulling from the server it has all 3 files - f1, f2
> and f3 to commit before push. But B did not changed f1 and actually can
> "ban" this change if he commits only f2 and f3 - files that were changed by
> him. In latter case after pushing to the server GIT will restore previous
> version of the f1, even if it has more recent one !! It does not seem to be
> very logical.
>
>   Question: is it possible to show to the developer only files, that he
> changes? Like in SVN - after updating from the server developer must resolve
> conflicts (if any) and only commits changes that he has made. By the way -
> in a case of non-conflicting files (let me say A changes f1, B changes f2)
> GIT makes commit automatically and does not show to the B, that f1 was
> changed and need to be re-commited. B only need to push the change back.

It is difficult to understand exactly what you have written here, but
I feel that git already does what you want, so I don't understand why
you are confused.

Please provide a concrete example (with git commands, expected
results, actual results, etc.) so that we can understand each other.