Dne Ätvrtek 16 Srpen 2012 17:18:45 Klaus Ethgen napsal(a): > > when merging branches to master, use --no-ff in the git merge command, > > so there will be an explicit merge commit. When one merges master to > > a branch, checks that it still works, and then merges back to master, > > often the merge back to master is a fast-forward merge and this is > > boggling when going through the history. (I am running a large > > private project where we use this rule, and it really helps; one can > > 'git log --first-parent' and see all the direct master commits and > > merge commits between releases, etc.) > > --no-ff is sometimes a good idea, sometimes not. I think that should be > used where it is reasonable. For example I might cherry-pick several > commits fixing small thinks into a temp branch. As long as nobody did > did something in master a ff might be reasonable. In other cases where > there is a new feature --no-ff is the best way. >
In my work project we do a rebase each time before pushing to master, I am not used to other methods. Each commit contain logically connected things - for example adding a variable in one file and using it in another. But merge commits break this rule - they contains random changes together. So my feeling is that with merge commits the history would be harder to review and debug but I have no practical experiences... Vladimir ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Geeqie-devel mailing list Geeqie-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geeqie-devel
