Reputation: 37806
When I work on git repositories by myself, there is no reason to ever pull before pushing.
When I work with others, it is recommended that I perform a pull before attempting to push-- well, either a pull, or a checkout, and then get the changes merged in.
Either way, I can not push by normal means, until I am up-to-date with the master, so it is a good habit to pull before pushing everytime(so I've been told).
90% of the time I pull, it's either already up-to-date or a fast-forward.
Is there a git push
-like command that automatically does a pull
first, and only halts the push when there are actual merge conflicts?
I suppose I could make an alias, but I wanted to first check if there was an already built-in command for it.
Upvotes: 1
Views: 596
Reputation: 534925
it is recommended that I perform a pull before attempting to push
Then it is recommended wrong. Just push. The act of pushing asks whether it is possible to push. If there's a reason why you can't push, you won't be able to push. Then you can worry about what to do.
Upvotes: 3
Reputation: 59811
There is nothing that does exactly what you and I think it would also encourage bad work-flow habits, because you end up pushing code that is not tested. Just because something merges cleanly, it still could be horribly broken.
git push
is already going to reject if you are not up-to-date with the remote. I will usually fetch the changes, review them, rebase my unpushed changes on top of them, and then go ahead.
If you find that you have too many commits coming in to do that (usually the case when everybody hammers commits on top of master), I would suggest switching to a branching based workflow. This isolates changes to their features, keeps history clean, and gives you a single integration step.
Upvotes: 2
Reputation: 6410
I use a "done" alias that stashes my uncommitted changes, switches to master, pulls from remote, merges my current branch to master, pushes to remote, switches back to my branch and rebases against master.
Upvotes: 0