You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@iotdb.apache.org by "RUI, LEI" <10...@qq.com> on 2019/07/10 14:52:48 UTC

What Is a Good Git Workflow?

Hi all,


I think it is worthwhile to spend some time discussing and hoping to reach a consensus on what a good Git workflow should be.


Here is the thing. The branch 'feature_async_close_tsfile' that I have recently been working on with others was merged into the master branch a few days ago. When I try to examine the Git history of some code, I find that the squash merge was used and thus all commit history on the branch 'feature_async_close_tsfile' is squashed into a single commit.


I understand that squash merge keeps the master branch history clean and easy to follow. However, is it too clean for a NOT lightweight feature branch like 'feature_async_close_tsfile'?


Is squash merge a standard practice in any situation? Should we make each develop branch small enough so that it can be squashed comfortably before merged to the master branch?


If the develop branch is inevitably large, in order to make the code history as simple as possible but not simpler, would rebase merge be a better choice, compared with merge and squash merge?


Apart from the final merge choice, I think it is as important that an individual looks closely at his/her Git workflow to keep the commit history both clean and meaningful.


Sincerely,
Lei Rui

Re: What Is a Good Git Workflow?

Posted by Xiangdong Huang <sa...@gmail.com>.

Hi,

Now "do not squash commits" is dominant...

If so, I think we'd better to avoid commit incomplete codes (e.g., I need
to change the developing environment from my laptop to my company's PC, so
I have to commit current changes and leave a commit log like "temporary
commit"...) or squash these commits before you submit a PR.

Best.
-----------------------------------
Xiangdong Huang
School of Software, Tsinghua University

 黄向东
清华大学 软件学院


Justin Mclean <ju...@classsoftware.com> 于2019年7月11日周四 下午7:34写道：

> Hi,
>
> I also dislike squash commits, you can learn a lot more from more fine
> gained commits, you can also do a lot of very use analysis on commits, for
> instance see teh book “Your code as a Crime Scene” which include analysis
> of version control history to see were bugs are likely to be. But then I’m
> not an active committer here so that’s just a general opinion. Is there a
> specific reason why hey might be useful to this project?
>
> Thanks,
> Justin

Re: What Is a Good Git Workflow?

Posted by Justin Mclean <ju...@classsoftware.com>.

Hi, 

I also dislike squash commits, you can learn a lot more from more fine gained commits, you can also do a lot of very use analysis on commits, for instance see teh book “Your code as a Crime Scene” which include analysis of version control history to see were bugs are likely to be. But then I’m not an active committer here so that’s just a general opinion. Is there a specific reason why hey might be useful to this project?

Thanks,
Justin

Re: What Is a Good Git Workflow?

Posted by 江天 <jt...@163.com>.

I prefer not to squash, too. In my opinion, commit logs give reasons of everything you have done (even when you just fixed a typo) so it does not make sense to delete any of them. 

If someone wants a straight-forward conclusion of this branch or PR, I would suggest the committer(s) conclude it in the mail list or on confluence. I think this helps those who wish to know about commits better than searching the commit history.

Well, actually I doubt anyone would look into the commit logs carefully since they are seldom easy to understand if you are not the committer.

Tian Jiang

Re: What Is a Good Git Workflow?

Posted by Christofer Dutz <ch...@c-ware.de>.

And one really important thing why I too hate squash commits:

Usually I commit in a pretty fine-grained. The reason for this is that if I change a line of code and someone uses git blame to see WHY I changed that line, I usually want to give that person the pointer to why I did it.
If you squash the commits, you'll just get a Huge commit message (or a really small one) and all the good information is lost in the masses.

Chris

Am 11.07.19, 07:46 schrieb "Julian Feinauer" <j....@pragmaticminds.de>:

    Hi,
    
    thats an excellent queston!
    I dislike squash commits for several reasons.
    First, history gets lost and second it changes authorship of the commit which is really bad as credits for the code should go to the author.
    
    For PLC4X we have no special rule but usually do not squash at all but we merge most of the branches ourselves.
    
    In Apache Calcite every PR should be squashed beforehand and then gets only merged without a squash.
    I think this is a good rule of thumb. 
    If there are specific reasons why a squash is not necessary / bad then one can state that as comment for the reviewer.
    
    I personally like to squash my branches from time to time to keep the history clear and without those "nearly finished" commits : )
    But if a branch has a good and clean commit history there is no need to throw that away.
    
    But generally I at least DISLIKE squash commits for the reasons stated above.
    
    Julian
    
    Am 11.07.19, 02:33 schrieb "Xiangdong Huang" <sa...@gmail.com>:
    
        Hi,
        
        I also think that squashing all commits into one is not so good for the
        branch `feature_async_close_tsfile`...
        
        Maybe a choice is that let committers squash their commit history to
        guarantee all the commits are meaningful.
        
        Best,
        
        -----------------------------------
        Xiangdong Huang
        School of Software, Tsinghua University
        
         黄向东
        清华大学 软件学院
        
        
        RUI, LEI <10...@qq.com> 于2019年7月10日周三 下午10:53写道：
        
        > Hi all,
        >
        >
        > I think it is worthwhile to spend some time discussing and hoping to reach
        > a consensus on what a good Git workflow should be.
        >
        >
        > Here is the thing. The branch 'feature_async_close_tsfile' that I have
        > recently been working on with others was merged into the master branch a
        > few days ago. When I try to examine the Git history of some code, I find
        > that the squash merge was used and thus all commit history on the branch
        > 'feature_async_close_tsfile' is squashed into a single commit.
        >
        >
        > I understand that squash merge keeps the master branch history clean and
        > easy to follow. However, is it too clean for a NOT lightweight feature
        > branch like 'feature_async_close_tsfile'?
        >
        >
        > Is squash merge a standard practice in any situation? Should we make each
        > develop branch small enough so that it can be squashed comfortably before
        > merged to the master branch?
        >
        >
        > If the develop branch is inevitably large, in order to make the code
        > history as simple as possible but not simpler, would rebase merge be a
        > better choice, compared with merge and squash merge?
        >
        >
        > Apart from the final merge choice, I think it is as important that an
        > individual looks closely at his/her Git workflow to keep the commit history
        > both clean and meaningful.
        >
        >
        > Sincerely,
        > Lei Rui

Re: What Is a Good Git Workflow?

Posted by Julian Feinauer <j....@pragmaticminds.de>.

Hi,

thats an excellent queston!
I dislike squash commits for several reasons.
First, history gets lost and second it changes authorship of the commit which is really bad as credits for the code should go to the author.

For PLC4X we have no special rule but usually do not squash at all but we merge most of the branches ourselves.

In Apache Calcite every PR should be squashed beforehand and then gets only merged without a squash.
I think this is a good rule of thumb. 
If there are specific reasons why a squash is not necessary / bad then one can state that as comment for the reviewer.

I personally like to squash my branches from time to time to keep the history clear and without those "nearly finished" commits : )
But if a branch has a good and clean commit history there is no need to throw that away.

But generally I at least DISLIKE squash commits for the reasons stated above.

Julian

Am 11.07.19, 02:33 schrieb "Xiangdong Huang" <sa...@gmail.com>:

    Hi,
    
    I also think that squashing all commits into one is not so good for the
    branch `feature_async_close_tsfile`...
    
    Maybe a choice is that let committers squash their commit history to
    guarantee all the commits are meaningful.
    
    Best,
    
    -----------------------------------
    Xiangdong Huang
    School of Software, Tsinghua University
    
     黄向东
    清华大学 软件学院
    
    
    RUI, LEI <10...@qq.com> 于2019年7月10日周三 下午10:53写道：
    
    > Hi all,
    >
    >
    > I think it is worthwhile to spend some time discussing and hoping to reach
    > a consensus on what a good Git workflow should be.
    >
    >
    > Here is the thing. The branch 'feature_async_close_tsfile' that I have
    > recently been working on with others was merged into the master branch a
    > few days ago. When I try to examine the Git history of some code, I find
    > that the squash merge was used and thus all commit history on the branch
    > 'feature_async_close_tsfile' is squashed into a single commit.
    >
    >
    > I understand that squash merge keeps the master branch history clean and
    > easy to follow. However, is it too clean for a NOT lightweight feature
    > branch like 'feature_async_close_tsfile'?
    >
    >
    > Is squash merge a standard practice in any situation? Should we make each
    > develop branch small enough so that it can be squashed comfortably before
    > merged to the master branch?
    >
    >
    > If the develop branch is inevitably large, in order to make the code
    > history as simple as possible but not simpler, would rebase merge be a
    > better choice, compared with merge and squash merge?
    >
    >
    > Apart from the final merge choice, I think it is as important that an
    > individual looks closely at his/her Git workflow to keep the commit history
    > both clean and meaningful.
    >
    >
    > Sincerely,
    > Lei Rui

Re: What Is a Good Git Workflow?

Posted by Xiangdong Huang <sa...@gmail.com>.

Hi,

I also think that squashing all commits into one is not so good for the
branch `feature_async_close_tsfile`...

Maybe a choice is that let committers squash their commit history to
guarantee all the commits are meaningful.

Best,

-----------------------------------
Xiangdong Huang
School of Software, Tsinghua University

 黄向东
清华大学 软件学院


RUI, LEI <10...@qq.com> 于2019年7月10日周三 下午10:53写道：

> Hi all,
>
>
> I think it is worthwhile to spend some time discussing and hoping to reach
> a consensus on what a good Git workflow should be.
>
>
> Here is the thing. The branch 'feature_async_close_tsfile' that I have
> recently been working on with others was merged into the master branch a
> few days ago. When I try to examine the Git history of some code, I find
> that the squash merge was used and thus all commit history on the branch
> 'feature_async_close_tsfile' is squashed into a single commit.
>
>
> I understand that squash merge keeps the master branch history clean and
> easy to follow. However, is it too clean for a NOT lightweight feature
> branch like 'feature_async_close_tsfile'?
>
>
> Is squash merge a standard practice in any situation? Should we make each
> develop branch small enough so that it can be squashed comfortably before
> merged to the master branch?
>
>
> If the develop branch is inevitably large, in order to make the code
> history as simple as possible but not simpler, would rebase merge be a
> better choice, compared with merge and squash merge?
>
>
> Apart from the final merge choice, I think it is as important that an
> individual looks closely at his/her Git workflow to keep the commit history
> both clean and meaningful.
>
>
> Sincerely,
> Lei Rui