Pull-Commit-Push or Commit-Pull-Push?

Question

Which is preferable over the other and why? If I pull before commit, do the changes that other developers made merge with what I am currently working on? If so, that means this one is more preferable?

Answer 1

It's better to commit first. Pulling without commiting may make your work overwritten. With a local commit, conflicts will be shown and prompted for manual merging when pulling, giving you a better control over your work.

Answer 2

I prefer commit-pull-push. Because in the other, risk is that if the pull does some stuff you really don't want and then you have a very hard time separating it from the work you've already done.

Answer 3

It's also really about how much responsibility you take. If you start with commit, you can say that you are selfish because you don't care about other people's work, how your code will interact with them. Whatever, just get your work in so you can go home.

In comparison, if you pull first and commit afterwards, you have the opportunity to test the code before you commit it to git. So together you can test how everyone else's work and yours will work together.

Of course stash and merge and conflict resolve, you need all of those. But I would recommend to any developer taking responsibility to pull before commit, test your code in local, and if everything is ok, then commit - push. Let's not make the work of our colleagues unnecessarily difficult. Don't have any state in git that could turn out to be bad. Of course, such a situation can happen, but it is best to do everything possible to reduce the chance of it happening.

In summary, in my opinion the correct order is:

pull - (test) - commit - push