khasinski

4 ms·

1.
by khasinski 10y ago
Yes, but I would prefer a coffee
2.
by khasinski 13y ago
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 ago and only yesterda
3.
by khasinski 13y ago
You're right. What I had on my mind writing the previous post - don't push broken commits. :)
4.
by khasinski 13y ago
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.
5.
by khasinski 13y ago
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 workflow. Having dat
6.
by khasinski 13y ago
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, --no-ff before you push
7.
by khasinski 13y ago
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 branch or remove the
8.
by khasinski 13y ago
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 feature release saved.
9.
by khasinski 13y ago
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 ;)
10.
by khasinski 13y ago
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 want to be up to date
11.
by khasinski 13y ago
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.
12.
by khasinski 13y ago
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 local branch git pull -