-2

If a user commits local changes, and tries to push the changes to a repository that has new changes, the push will fail saying that there are unpulled changes.

But if you try to pull the changes, it will fail because there are uncommited (to the repository) changes in my local repository.

What is the point of letting users commit changes if they will not be able to push them if he doesn't pull first?

Leo
  • 1,174
  • 11
  • 25
  • 2
    judging from your question you fundamentally misunderstand the way GIT works. the idea is that you have *local* version control over the changes you made, before pulling code that may conflict it, so you can always fall back on what you had before you pulled. – Timothy Groote Nov 13 '17 at 13:40
  • 1
    `But if you try to pull ... it will fail` ... No, if you commit your changes and pull, it will usually work, worst case scenario there would be merge conflicts. You might want to hit up a good Git tutorial. – Tim Biegeleisen Nov 13 '17 at 13:41
  • 3
    I think this comes from a very SVN like train of thought, where commit is about the same thing as push. – Timothy Groote Nov 13 '17 at 13:42

1 Answers1

0

Committing changes is something you do locally i.e. in your own local working copy as opposed to any remote branch. Git makes you commit before pulling so that your local, "unregistered" changes are not overwritten by whatever you are pulling from the remote (note that "pulling" means "fetch" + "merge", or download changes and merge them with your local changes). If anything it's wrong or there is any merge conflict, you will be able to solve it thanks to your commit. That's why you can and should commit first, then pull (fetch + merge), and then push.

There are many reasons why several devs shouldn't be pushing to the same branch, but that's a different story I guess.

Edword
  • 80
  • 11