Re: What's The Right Way to Do This?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 23/09/11 05:48, Jon Forrest wrote:
I'm just now starting to use git for more than trivial things.
Today I got myself in trouble. Here's what happened:

1) I pulled the master branch from the IT repository from our
main git server.

2) I created a branch from this called "J" and started making changes.

3) Other people pulled master from IT and then pushed changes back.

4) I merged J with my master branch.

Someone will be along soon to correct me, but I think you should have rebased against the master branch rather than merged. Something like:

% git rebase origin

That way your changes would remain appended to the tip of the master branch. That will in general make your life much easier for all sorts of reasons.


5) I tried pushing my master back to origin but this failed with
the usual message saying I first needed to pull from origin.
So, I pulled and then pushed. This worked.

6) On another server where I was going to use my changes I pulled
master from IT.

6) It turned out that my changes were incorrect. So, I tried to revert
using various methods I found by googling "git revert". What happened
was that when I tried to revert back to the commit before the one I
made, the files I had modified *and* the files that apparently were
modified by other people in #3 above were reverted. This wasn't what
I wanted. I only wanted to revert the changes I had made.

At a guess, git revert created a commit that undid your _merge_, rather than your commit. The merge included all those other changes....

It's a good idea to take a look at what a commit does before pushing it - "git show HEAD" is your friend.


With the help of someone more experienced than me we were able to get
things back to normal but this experience left me wondering what I
should have done in the first place. There's a chance I'm going to
have to go through all this again as I try to fix the problem with
my changes.

Use git rebase (*) to keep your changes nicely arranged at the top of the main branch.

Use git show to check the sanity of what you're about to push upstream.

I think you could award yourself a nice cup of tea after an experience like that though, having been on both sides of it, I can imagine you need it :-P

Regards!
Luke


(*) But note that rebasing can cause problems for people who are downstream of _you_. See the git-rebase(1) man page.

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]