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 them. *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.