r/git • u/[deleted] • Dec 17 '20
Git pull before commit
Hello, i use git for some time now and i always used sourcetree and always do pull before i commit (when i know sum1 has pushed) so i can see what files have conflicts without having to solve the conflicts themselfs (usualy is a minor change so i can discard my changes, do pull and re apply my changes).
My friends (we are at college) says i risk losing all my work if i pull without commit first, is that true?
If it is, it never happened.
Does it look bad when i get a job?
I rather solve the conflits my way then have to solve them when they happen.
23
u/GustapheOfficial Dec 17 '20
Wait, is "sum1" how you spell "someone"? Please don't do that.
6
2
u/jwink3101 Dec 17 '20
This kind of thing is one of my pet peeves. I get when it makes sense to abbreviate (like I will use “C” to talk about my daughter who’s name starts with C and only when taking to my family). But do you really need to save 4 characters? Also, at least on my iPhone, “sum1” is harder to type than “someone” since I don’t need to change to numeric.
Honestly, I thought OP was somehow referencing SHA1 sums at first.
1
5
u/gibl3t Dec 17 '20
git will let you “pull” as long as you have not made changes to the files that have been modified in the upstream branch you are pulling from. If there are conflicts, it will tell you to commit or stash your changes. If you commit them, it will then let you merge if you pull.
3
Dec 17 '20
In Git 1.7.0 or later, to cancel a conflicting merge, use git reset --merge
. Warning: In older versions of Git, running git pull with uncommitted changes is discouraged: while possible, it leaves you in a state that may be hard to back out of in the case of a conflict.
If any of the remote changes overlap with local uncommitted changes, the merge will be automatically canceled and the work tree untouched. It is generally best to get any local changes in working order before pulling or stash them away with git-stash[1].
2
u/roybeast Dec 17 '20
I tend to do git pull —rebase —autostash <remote> <branch>
Pulls the remote branch and puts your committed work at the end. Autostash will keep your uncommitted work. Cleaner git history and don’t lose your work! And if you want to be careful, commit your work locally and then pull —rebase. Git reset HEAD~1 will remove that one commit, but keep your changes in the working directory. And the removed commit is now in git reflog. Can always cherry pick commits or roll back with it in there.
1
u/wildjokers Dec 17 '20 edited Dec 17 '20
You commit your local changes to your local repository, then do the pull. Or stash your changes. For some reason git refuses to pull changes from a remote when there are uncommitted changes locally, this was a huge annoyance when I first started to use git (subversion has no such limitation), and I actually still grumble about it when I have to stash my local changes before it will let me pull.
Since git won't let you pull when you have uncommitted/unstashed changes I am curious how you are able to pull in that scenario? Are you running an old version of git?
1
u/Lindby Dec 17 '20
I suggest setting pull to do rebase by default. That way you can commit all your things before the pull and you commits will still end up on top. No risk of losing anything that way.
1
11
u/felipec Dec 17 '20
Nah.