On Thursday, July 10, 2014 6:28:01 PM 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. >
How did you pull down the repo exactly? In doing this pull, you created your second change: the merge commit that obviously merged in a lot of old crap. > 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. > It's usually safer to do a git fetch. Then have a good look in SourceTree what you want to do - pick a target branch where you want your changes to end up (probably origin/master). Now either merge or rebase your local master branch onto origin/master, and *then you check that everything looks OK*, both files and history. If everything looks all right, you can push. It's best if you have someone experienced guide you through this the first time though. > 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. > You created the second one when you made the pull command. Tell us what you did (parameters, etc), and show us your branch configuration (git remote -vv) if you want advise on what went wrong. > > 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? > These are changes on other branches. Changes on other branches can happen in parallel. The displayed order in your GUI is based on some other logic than when something was committed. > 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? > Yes. You merged in some branch when you pulled. You didn't notice that this was a bad merged, and you pushed it. > 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.) > > Yes. Git is not easy, and Git is not SVN. Git is a power-tool, and you need to get on top of branches, remotes, merging and rebasing. If you have no one to help you out, read chapter 2 and 3 here for starters: http://git-scm.com/book And try out these things one some dummy repo before you push to a repository other people are using. And get some help from your colleagues. -- 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.