| 1 |
I realize that this is subject to lots of different opinions and that |
| 2 |
my input doesn't carry much weight - At least I thought it's a topic |
| 3 |
that should be brought up (again?) |
| 4 |
--------- |
| 5 |
To start.... I hate git.. I have used it for years now and the |
| 6 |
multitude of ways that are possible to accomplish nearly the same |
| 7 |
thing are *annoying* at best.. With that rant out of the way on to the |
| 8 |
point.. |
| 9 |
--------- |
| 10 |
I super don't like "merge" workflows. |
| 11 |
1) "merge commits" are confusing at best and normal tools don't |
| 12 |
display and work with them as you'd always expect |
| 13 |
|
| 14 |
2) merge commits lead to multiple parents, which breaks a clean and |
| 15 |
simple to follow linear history |
| 16 |
--------- |
| 17 |
|
| 18 |
What I personally prefer is a rebase workflow. |
| 19 |
The downsides |
| 20 |
1) Requires to you rebase before pushing. Which can be slightly more |
| 21 |
work than just a lazy resolution of the conflicting "merge commit" |
| 22 |
(depending on if you flatten your commits) |
| 23 |
|
| 24 |
2) May not be the most popular git work-flow. |
| 25 |
|
| 26 |
3) Due to #2 from above - may have detractors and or less people who |
| 27 |
are familiar with it. |
| 28 |
-------------- |
| 29 |
I'm of the mindset that if you're going to keep something under |
| 30 |
revision - the history should be clear and clean. Linear is the only |
| 31 |
way to fly for that. For those using cvs or svn - that's what they'll |
| 32 |
be familiar with and probably expect to find in a git log. You can |
| 33 |
start with forcing rebase and keep a clean history - if one day it |
| 34 |
proves too problematic you can switch over to "merging" - the other |
| 35 |
way isn't really possible to do cleanly, depending on your tools.. |
| 36 |
|
| 37 |
Thanks for the minute |
Archives