1

I'm still learning the in's and out's of git, and the more I learn, the more I like, and the more I realize I don't really know what i'm doing.

I have several branches, a develop, a master, and two feature branches.

I was working on a feature branch, and I wanted to checkout the develop branch. I got a warning that I had uncommitted changes, so I did a git commit -m'storing changes'

Then I did a checkout on the develop branch.

The problem is that my commit to the feature branch, appears to have been pushed to the origin repository, without my doing.

I have no idea how it happened. I've gone through the reflog, and through my command history and no where did I explicitly do a push

I'm totally confused, and my boss is going to burn my feet.

EDIT TO ADD:

This is the output of the reflog

4f1641c HEAD@{5}: checkout: moving from feature/X to develop
b67d265 HEAD@{6}: commit (merge): stashing
dd9294d HEAD@{7}: checkout: moving from develop to feature/X

b67d265 is the commit that got pushed. I see the (merge) but I thought if there was a merge, it autocommits locally...

Here is the output of branch -va

  develop                               9b44fac [behind 8] Fixing clicking search annotation causing app crash
* feature/X                       b67d265 stashing
  feature/forecastscroll                8211bfc Updated Forecast Slider to be based on UIScrollView
  master                                4a2a436 Merge branch 'master' of git://X/iOS/X
  servertimedelta                       72e5426 removing comment check
  remotes/X_dev/develop              57f0f03 fixing lockonme not enabled for for new users
  remotes/github/feature/forecastscroll 8211bfc Updated Forecast Slider to be based on UIScrollView
  remotes/origin/HEAD                   -> origin/master
  remotes/origin/develop                fe64f76 Merge branch 'develop' of git://X/iOS/X into develop
  remotes/origin/feature/X        b67d265 stashing
  remotes/origin/master                 4a2a436 Merge branch 'master' of git://X/iOS/X
Alan
  • 45,915
  • 17
  • 113
  • 134

2 Answers2

3

Use

git branch -va

to understand where your branches are pointing. You will see local and remote branches, where remotes are tracking the state of the corresponding branches on the remote side.

There is no way that the commit is getting pushed without you pushing anything. Therefore i think information provided by the command above will clear things up. If still confisud - please expand your question with details of commands executed and what the the output of the command above is.

Eugene Sajine
  • 8,104
  • 3
  • 23
  • 28
  • Thanks, I ran that command, but how do I know where the branch is pointing? I see the branches I expect, then I see a list of remotes below it, but it's not obvious where my branches are pointing (I assume since they're not pointing anywhere, they're local) – Alan Apr 26 '11 at 18:14
  • as you know the branch in git is a movable pointer to a commit. Your local branches are all branches that don't have "remotes" prefix (master, develop, feature/X etc). The branches that are listed with "remotes/" prefix are so called remote-tracking branches, i.e. branches that are tracking the state of the corresponding branches in the remote repository. In your case remote-tracking branches are from different remotes you have connected (x_dev, github, origin) – Eugene Sajine Apr 26 '11 at 19:53
  • Remote-tracking branches are updated ONLY by a network operation which is push or fetch. I.e. you cannot change the commit ID the remote-tracking branch (such as remotes/origin/feature/X) is pointing to by any other operation (commit or merge or whatever). Only fetch(pull) or push. – Eugene Sajine Apr 26 '11 at 19:58
  • Now as i see from the printout both branches feature/X and origin/feature/X are pointing to the same commit ID. It means to me that you did pushed your feature/X branch. Or somebody pulled from you, pushed to your origin repo and then you have pulled the change in. – Eugene Sajine Apr 26 '11 at 20:02
  • As a side note: I wouldn't recommend the naming of branches using slashes. If you really need to distinguish your branches as feature ones, i would use something like below: f_newX f_improvelogging b_9999 (for bug fixes) – Eugene Sajine Apr 26 '11 at 20:04
  • @Eugene: thanks for the explanation. Though I swear on my 10k reputation I never once typed "git push" or anything similar. With regards to the /, it's part of this "git flow" workflow that my team has adopted. It's some script that adds `feature/` when you create a feature branch. – Alan Apr 26 '11 at 21:00
  • Also, when I check the commit history on the origin, it says I did the push. However, when I use "up" in terminal, no where do I do a push, after I make the commit. :( – Alan Apr 26 '11 at 21:01
  • Do you have any wrapper scripts around git? Can it be that you have executed some wrapper script that has push of any kind inside? Did you execute pull or fetch recently? – Eugene Sajine Apr 26 '11 at 21:22
  • @Eugene: I did a pull after I did a checkout to another branch. Im a little confused though, pull would do a push? – Alan Apr 26 '11 at 21:33
  • Of course not. Pull would update the remote-tracking branch. Do "git remote show origin" See if it will tell you something like "local refs configured for pull: feature/X merges with origin/feature/X" If this entry is present it means that you are having this branch configured for parameter-less pull. I.e. "git pull" will update all the branches configured that way. We are getting closer;) Do you have any team members working with you on your feature/X? Can you check if they have pulled from you recently? – Eugene Sajine Apr 26 '11 at 21:42
  • Local branches configured for 'git pull': develop merges with remote develop feature/X merges with remote feature/X So it looks like we have parameter-less pull. I had a teammember who pulled from my github remote. If they did a pull from me, when they did a push, wouldn't their name show up in the origin commit? They may have also added my local repository as a remote as well... – Alan Apr 26 '11 at 21:52
  • Rather, is there a way to find out that it was Person X that pushed the commit made by Person Y? – Alan Apr 26 '11 at 21:54
  • As far s i know git doesn't track such info by default, if we are talking about bare repo (i believe your origin is a bare repo) but you can set it up to at least to have reflog enabled. please, see here http://stackoverflow.com/questions/3876206/how-do-i-view-a-git-repos-recieve-history – Eugene Sajine Apr 26 '11 at 22:09
  • Most of the time the info about who pushed is not interesting. Git cares more about who changed what. Although in our particular case such info could help dramatically to unwind your mistery;) – Eugene Sajine Apr 26 '11 at 22:15
  • @Eugene: One of the things I liked about git, is that I could make commits, and modify them to "hide my stupidity", before exposing them to the origin repo. If someone can pull from me, without me knowing, and push my commits, then that seems like I still should worry about what I do and don't commit locally. – Alan Apr 26 '11 at 22:18
  • Well this is true mostly for the situation when you have your repo in the network reachable by other team members, like NFS. Generally speaking, it seems to me that the problem is not in the ability to pull from you and to push but that people are not educated about what they are doing. Your problem is not git problem, but workflow and education problem IMHO. So if you want to avoid this kind of stuff and you're concerned about your origin repo integrity i would suggest things like below: – Eugene Sajine Apr 26 '11 at 23:02
  • 1. to make the folder that contains all your local repos readable only for you. This will prohibit people from pulling via NFS. 2. introduce access management system for your origin repos, I.e. make only team leads/maintainers be able to push to origin. This enforces workflow, where every change will be reviewed and will guarantee that commits will be pushed in proper branches. 3. EDUCATE, EDUCATE, EDUCATE – Eugene Sajine Apr 26 '11 at 23:03
  • @Eugene: I figured it out with your help. I think it has to do with my repo's being setup to do a parameter-less pull. I think that works the same for push, right? I've been doing 'git push' assuming that it only pushes whats in my current branch. Apparently thats not true? – Alan Apr 27 '11 at 00:07
  • Wait, git push, according to the documentation, should only update the remote/origin for the current branch. WTF. – Alan Apr 27 '11 at 00:16
  • As far as i know "git push" without parameters will update all branches that are configured for push (i.e. all branches that are listed in "git remote show origin" in section "Local refs configured for git push") I believe whatever wrapper script is used to create your feature branches it is configuring those feature branches for push as well. Which i think is not necessary. Feature branches are not supposed to be public - so that might be the root of the issue. – Eugene Sajine Apr 27 '11 at 14:52
  • @Eugene: Yes, you are spot on. I misread the documentation for `git push`. I also believe you are right, the git-flow script must add the branches it creates to the 'local refs configured for push' I ran the following `git config remote.origin.push HEAD` which now only updates the origin of the current branch, when I do a git push. Still, to be sa – Alan Apr 27 '11 at 16:09
  • You can use this to push only current branch (if you want to push feature/X): "git checkout feature/X", "git push origin feature/X" This command is explicitly saying that you want it to take current HEAD and push it to the specified branch on remote called origin – Eugene Sajine Apr 27 '11 at 17:27
0

There is also the possibility that if your repository is visible on your local network, someone might have pulled it from you and then pushed the changes up to origin.

rtn
  • 127,556
  • 20
  • 111
  • 121