On Thursday, 10 July 2014 18:28:01 UTC+2, Joe Strout wrote:
> I joined a project yesterday that's using git for their version control.
> I pulled down the repo, changed one file, and added several new ones.  
> Everything was in good shape and ready to share with the team.  So, on the 
> advice of someone who has used git a lot more than me, I did a Commit, then 
> a Pull (which apparently was required because a few other changes had been 
> made while I was working), and then a Push up to the master.
> This morning I heard from the team leader (who was remarkably calm) that 
> everything was broken.  Looking in the log, there are two entries from me: 
> the first one (9:10 PM) contains just the files I thought I was committing, 
> but the second one (9:11 PM) contains hundreds of files that I never 
> touched.  And these, apparently, leave the master in a nonworking state.
> I've attached a screen shot of SourceTree, which hopefully makes sense to 
> somebody here.  It baffles me in a variety of ways.  For example, between 
> my two commits 60 seconds apart, there are half a dozen other commits, 
> including July 2nd, July 5th, etc.  How in the world did those get in 
> between my two actions?
> Our hypothesis is that me pushing my changes to the master somehow caused 
> a bunch of other changes, which previously were in other branches, to get 
> pushed to the master as well.  Can anyone explain this?
> Finally, what did I do wrong, and what should I have done instead?  My 
> goal is simple:
> 1. Get the latest version of the files
> 2. Make some minor edits
> 3. Share these edits with the group.
> This would be a simple svn update, edit, svn commit in my comfort zone, 
> but apparently in git it's not so easy.  Can anyone explain, as simply as 
> possible, how to accomplish this with git and SourceTree?  (Yes, I've read 
> git documentation and tutorials, but clearly I still don't get it.)
> Thanks,
> - Joe

Definitely sounds like you've got merge conflicts when pulling from the 
remote master, and messed the resolution up. The second commit you see (the 
one breaking everything apparently) is the result of the git-pull you made 
before pushing. A git-pull is two actions in one: git-fetch and git-merge. 
Any merge operation can throw conflicts if the same part of a file has been 
edited on both sides of the merge, in which case git cannot guess which one 
to use or how to merge them up. I recommend you read git's man page 
<http://git-scm.com/docs/git-merge> on merges, conflicts and how to resolve 

*Note:* I can't see it clearly on your screenshot, but it seems to me your 
first commit on your local master is pretty behind the tip of the remote 
master... The more differences there is between two branches, the more 
likely it is you'll have conflicts when merging them. A good idea is to 
make sure the branch you're about to work on is up-to-date with the remote 
before working on it (basically, pull before starting to work), and try 
keeping your branches up-to-date by pulling from the remote from time to 
time. It's always easier to solve a few conflicts from time to time than a 
big bunch of'em when you need to merge your work to the remote in emergency 
to keep up with the deadline.

You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to