[Project-managers] Git and github

[Tobias Achterberg]

Am 24.05.2014 14:26, schrieb Brad Bell:
> On 5/14/2014 5:32 AM, Tobias Achterberg wrote:
>> This is not really a valid question in the git context.
>>
>> Suppose that at some point you start with a plain linear history of master:
>>
>>                master
>>                  |
>>                  v
>>   A -> B -> C -> D
>>
>> Note that the branch "master" is just a pointer to some commit, in this case D.
>>
>> Now developer 2 forks off a branch and starts doing parallel development to developer 1 (who is
>> committing something to the master branch):
>>
>>                          master
>>                            |
>>                            v
>>   A -> B -> C -> D -> E -> F
>>                  |
>>                  |
>>                  +-> G -> H -> I
> ... snip ..
>
> Suppose that G and H are only partially functional and I is completely functional.
>
> I now want to replace master by the following history
>      A -> B -> C -> D -> E -> F -> I
> In a way so that I can recover A, B,  C, D, E, F, or I depending on which version of the master I
> want by date.
>
> This is very easy to do in subversion, but I have not been able to figure out how to do it in git ?

Let's assume that you have created and edited the branch G->H->I locally, so that nobody else 
"knows" these commits (you have never pushed them into some other repository). This should be the 
typical situation.

Once you have pushed your local branch G->H->I to some other repository you should no longer mess 
around with this and basically have to live with the fact that there are some intermediate states (G 
and H) that do not work properly. I would recommend to avoid this situation for states that do not 
even compile (have syntax errors) or that fail (like segfaults) for many inputs. Other partly 
working things are just fine to push.

But if you insist on keeping G and H hidden you can (as long as you did not yet share those commits 
with others) easily turn your local branch into D->I. This can be done using the "git reset" or "git 
commit --amend" commands. Finally, you would merge your "I" commit into master to get

                            master
                               |
                               v
A -> B -> C -> D -> E -> F -> J
                |              ^
                |              |
                +-> I ---------+

with a merge commit J.

To get to a linear history (which you would need for an svn repository), you could use "git rebase" 
on the commit I. But this is *really* not what you want to do in the git world. And this is the 
reason why I would not use things like gitsvn and work in both worlds in parallel.


Tobias