3 ms·
Agreed. 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,
by gcv 15y ago
Agreed. 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.