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 

> 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 
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: 

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.

Reply via email to