tag:blogger.com,1999:blog-3615332969083650973.post1670800003306377252..comments2024-03-23T07:59:04.047-04:00Comments on sysadvent: Day 3 - 14 Tips for Git Giddiness in 2014Jordan Sisselhttp://www.blogger.com/profile/13694925032675599790noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-3615332969083650973.post-11748212831117558042013-12-05T02:17:21.670-05:002013-12-05T02:17:21.670-05:00@Frederik:
I think as Git evolves, it will encomp...@Frederik:<br /><br />I think as Git evolves, it will encompass the distinction between codelines that are "official," and "feature" or "developer" codelines that are able to be rewritten and tidied up until they are merged into the official codelines.<br /><br />In those cases, the using a properly configured repository manager (org tip #3) ensures that engineers cannot rebase "official" codelines, but CAN rewrite, tidy up, and respond to code review feedback their own codelines before they are merged.<br /><br />In my opinion, there's a lot of bad advice floating around about rebase because it is so dangerous; but with tooling around it (Git Flow's git flow feature rebase, and git repository permissions), it's an invaluable feature.<br /><br />-preedpreedhttps://www.blogger.com/profile/13823755330697633744noreply@blogger.comtag:blogger.com,1999:blog-3615332969083650973.post-26908302946320631562013-12-04T16:31:12.051-05:002013-12-04T16:31:12.051-05:00There are some good points raised in this post. I ...There are some good points raised in this post. I personally just don't agree with the rebase approach. In my team we decided not to use rebase on anything that has been pushed in - ever. As mentioned in the above post itself, it rewrites history, so it can be very dangerous to use if you don't use it right. And from a history/audit/review perspective I think rebase is just too fragile.Anonymoushttps://www.blogger.com/profile/04677637878627824692noreply@blogger.com