Yes, but I would prefer a coffee
With "Please, oh please use git pull --rebase" I didn't mean to preach but to convince some of the people I code with to maintain at least basics of a clean git history, thus the 'please' in title. I wrote it some time…
You're right. What I had on my mind writing the previous post - don't push broken commits. :)
No, it does not. CI never builds those broken commits because they never go outside of authors personal computer. Commit often, push when it's done and only push commits that work.
Why would someone take one of the most important features of git (local history) and throw most of it away by abandoning ability to edit it? If you pushed a broken commit push another fixing it, just like in merge-based…
Exactly. Keep remote history clean, keep local history dirty. Commit broken code, commit experimental features, do whatever it takes for you to write your code. Squash, rebase interactively, rearrange, amend, merge,…
Yes, --no-ff merge after a rebase gives a clear indication that's a feature merged from a feature branch. It's easy to cherry-pick it to another branch (for example for a backport to an old version), easy to bisect this…
Yes, I did. If you're using continuous delivery or at least continuous integration system you can revert the build, bisect easily the history in a matter of minutes (for a use case missed by all the tests) and have a…
Yes, but I used the title for people to actually start using rebase. Caring about history beyond avoiding useless merges and broken commits is another step I'd like at least my co-workers to take ;)
From my experience it is common for a group of developers co-working on some feature to share codebase very often. Also in an actively developed project there are likely to be many new commits every single day, and you…
You nailed it. Commit history is for people to read. Check out git flow, you might like it. It could add even more structure and readability to your codebase history.
OP here, I do prefer feature branches (especially git flow: https://coderwall.com/p/d1pkgg ), but for day to day 'agile' development in a small team we don't use them often. YMMV. But for pulling changes working on…
Yes, but I would prefer a coffee
With "Please, oh please use git pull --rebase" I didn't mean to preach but to convince some of the people I code with to maintain at least basics of a clean git history, thus the 'please' in title. I wrote it some time…
You're right. What I had on my mind writing the previous post - don't push broken commits. :)
No, it does not. CI never builds those broken commits because they never go outside of authors personal computer. Commit often, push when it's done and only push commits that work.
Why would someone take one of the most important features of git (local history) and throw most of it away by abandoning ability to edit it? If you pushed a broken commit push another fixing it, just like in merge-based…
Exactly. Keep remote history clean, keep local history dirty. Commit broken code, commit experimental features, do whatever it takes for you to write your code. Squash, rebase interactively, rearrange, amend, merge,…
Yes, --no-ff merge after a rebase gives a clear indication that's a feature merged from a feature branch. It's easy to cherry-pick it to another branch (for example for a backport to an old version), easy to bisect this…
Yes, I did. If you're using continuous delivery or at least continuous integration system you can revert the build, bisect easily the history in a matter of minutes (for a use case missed by all the tests) and have a…
Yes, but I used the title for people to actually start using rebase. Caring about history beyond avoiding useless merges and broken commits is another step I'd like at least my co-workers to take ;)
From my experience it is common for a group of developers co-working on some feature to share codebase very often. Also in an actively developed project there are likely to be many new commits every single day, and you…
You nailed it. Commit history is for people to read. Check out git flow, you might like it. It could add even more structure and readability to your codebase history.
OP here, I do prefer feature branches (especially git flow: https://coderwall.com/p/d1pkgg ), but for day to day 'agile' development in a small team we don't use them often. YMMV. But for pulling changes working on…