3 ms·
By doing a fetch first, and a merge in a separate operation, you're at least presenting yourself with an opportunity to check the code that you are merging. Wi
by click170 15y ago
By doing a fetch first, and a merge in a separate operation, you're at least presenting yourself with an opportunity to check the code that you are merging.
With `git pull`, it is all done in one operation.
Of course, if you've already reviewed the code or are pulling from your own remote repository then `git pull` is likely fine.
- gcv 15y agoAgreed. After a fetch, I always review the changes on the remote branch. Depending on the circumstances, I can then make an informed decision about my own code, with the following possible outcomes: 1. I might choose not to merge. The upstream code may be bad, or it may not be ready for a merge. I may need to do some more work to prepare my own code to merge. 2. I might wish to perform a fast-forward merge (if one is possible). 3. I might wish to force a non-fast-forward merge (if a fast-forward is possible). This is often a good idea, as it helps keep groups of commits related to a particular feature isolated. 4. I might wish to rebase.
- lucisferre 15y agoI treat pulls as a sync and always rebase local changes before pushing them. Merge pulls make for a very messy and verbose history.