149

What is the right way?

git add foo.js
git commit foo.js -m "commit"
git pull
git push

Or

git pull
git add foo.js
git commit foo.js -m "commit"
git push

Or

git add foo.js
git pull
git commit foo.js -m "commit"
git push

UPD:

I forgot to mention that in this case I use git add to stage a tracked and modified file. Not to include a brand new file to repository. Does this changes an order of commands?

Green
  • 28,742
  • 61
  • 158
  • 247
  • Related question: http://stackoverflow.com/questions/813822/how-to-make-git-merge-handle-uncommitted-changes-to-my-working-tree – leo9r Apr 11 '16 at 23:06

6 Answers6

171

I think that the best way to do this is:

Stash your local changes:

git stash

Update the branch to the latest code

git pull

Merge your local changes into the latest code:

git stash apply

Add, commit and push your changes

git add
git commit
git push

In my experience this is the path to least resistance with Git (on the command line anyway).

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
johnjo
  • 1,785
  • 1
  • 11
  • 11
  • 7
    Can you explain *why* this is better? What problems does this avoid? In particular, why is this better than a simple commit > pull > push? (I feel like this could be the best answer, but doesn't have enough information right now to even be considered a good answer.) – dallin Jul 28 '18 at 20:14
  • 17
    Perhaps this was too anecdotal but I always found this approach (on the command line rather than with something like sourcetree) far easier. Doing a commit and then pull, while working in a large team, always lead to large merge conflicts as git wasn't very good at merging my changes to a file with the incoming. By stashing, it allowed me to pull the new changes and then use the updated code as a base for adding my changes to. Dealing with the conflicts was easier as they were clearer to me (as my changes were now the conflicts). In hindsight, may be it was just easier for my situation. – johnjo Jul 30 '18 at 11:04
  • 3
    So it sounds like kind of a "How do you eat an elephant? One bite at a time" kind of thing. i.e. Breaking the process into a few more steps to simplify the merges to have fewer and possibly clearer changes. Makes sense. – dallin Jul 31 '18 at 13:58
  • 1
    Is git add necessary here ? If all the files are already added to staging! – Sharp Edge Nov 19 '19 at 14:20
  • What about if you're not using `git stash`? – Aaron Franke Nov 26 '19 at 01:31
  • 2
    @AaronFranke then start using `git stash`. – Slbox Jun 15 '22 at 01:04
  • Should a git stash clear be done after the push? – Simon Chemnitz-Thomsen Aug 29 '22 at 07:45
91

pull = fetch + merge.

You need to commit what you have done before merging.

So pull after commit.

Arnaud Denoyelle
  • 29,980
  • 16
  • 92
  • 148
  • 11
    Would this mean you end up making an extra commit for each commit you make and make the repo sloppy? Also your initial commit message ends up followed by a merge comment each time. If so I'd be inclined to use the stash method mentioned below by @johnjo. – MondayPaper May 04 '16 at 20:02
  • 6
    @DanielM Yes, there is an extra commit for the merge (with an explicit default commit message). This is quite a good thing though because it allows you to checkout your last commit or your colleague's last commit or the merge commit. If you want to avoid it and if you want to place your commits after your colleague's commits, you can `rebase` instead of `merge`. You can do it with either `git commit && git rebase` or `git pull --rebase`. – Arnaud Denoyelle Nov 20 '16 at 00:20
  • Thanks for the tip, @Arnaud. After reading many different SO questions, this comment made it. My preferred option when colleagues are working on different files is to `git pull` after staging my changes, as I find it the most natural. Though I realize many different workflows work (stash is nice too), so it is probably a matter of taste. – nephewtom Apr 21 '17 at 18:39
61

I'd suggest pulling from the remote branch as often as possible in order to minimise large merges and possible conflicts.

Having said that, I would go with the first option:

git add foo.js
git commit foo.js -m "commit"
git pull
git push

Commit your changes before pulling so that your commits are merged with the remote changes during the pull. This may result in conflicts which you can begin to deal with knowing that your code is already committed should anything go wrong and you have to abort the merge for whatever reason.

I'm sure someone will disagree with me though, I don't think there's any correct way to do this merge flow, only what works best for people.

Jasarien
  • 58,279
  • 31
  • 157
  • 188
  • 1
    Could you please see my update to the question? I forgot to explain what for `git add` is used exactly in my example. – Green Aug 30 '13 at 10:41
  • 1
    Shouldn't make any difference whether it was a new file or a tracked/modified file. Still commit and then pull. – Jasarien Aug 30 '13 at 13:50
11

I think git pull --rebase is the cleanest way to set your local recent commits on top of the remote commits which you don't have at a certain point.

So this way you don't have to pull every time you want to start making changes.

Mohyaddin Alaoddin
  • 2,465
  • 1
  • 19
  • 14
  • This is what I do also, but just to point out that there are definitely two main schools of thought on this (centred around whether it's best to fix conflicts across individual commits, or once in the merge commit) with Linus himself in the merge camp. Thankfully the tool itself is not opinionated, so use it however works best for you & your project's needs :-) – Luke Usherwood Mar 13 '19 at 16:27
2

You want your change to sit on top of the current state of the remote branch. So probably you want to pull right before you commit yourself. After that, push your changes again.

"Dirty" local files are not an issue as long as there aren't any conflicts with the remote branch. If there are conflicts though, the merge will fail, so there is no risk or danger in pulling before committing local changes.

AlexE
  • 334
  • 2
  • 15
  • 1
    Won't work, as Arnaud mentioned, pulling requires that you commit your changes first. – Jasarien Aug 30 '13 at 09:24
  • My git seems happy to pull with lots of local changes. Of course, if the same files are changed on the remote branch, the merge part of the pull fails. To create a proper merge conflict, I'd have to commit first, sure. So, if the set of locally and remotely changed files is disjoint, pulling and then commiting is fine. Otherwise, git won't pull. No damage to be done by trying. – AlexE Aug 30 '13 at 09:31
  • This is my preferred option when people is working on different files, and I find it the most natural. – nephewtom Apr 21 '17 at 18:28
0

Best way for me is:

  1. create new branch, checkout to it
  2. create or modify files, git add, git commit
  3. back to master branch and do pull from remote (to get latest master changes)
  4. merge newly created branch with master
  5. remove newly created branch
  6. push master to remote

Or you can push newly created branch on remote and merge there (if you do it this way, at the end you need to pull from remote master)

Jane Tasevski
  • 36
  • 4