git single developer w/multiple machines – rebase and commits showing up twice

Some Background:

  1. I am a single developer working on one site.
  2. I am using git for version control.
  3. I have multiple computers that I work from: office, home, and laptop

Currently, I have a central, bare repository on my server. Each computer clones from and pushes changes to this repository. I currently have branch Master and branch dev. All of the work is done in the dev branch. Master is always the current, stable production code. Changes can be applied to Master at any point along with the changes that are going on in dev.

  • Make bash commands to fall back to git commands if git command exists
  • How can I disallow git commands from moving to the parent directory?
  • Git search all diffs
  • Prevent 'git checkout' if uncommitted changes
  • How can I move my ten commits from master to a new branch in git?
  • Git describe fails to return most recent annotated tag
  • My everyday workflow consists of:

    git checkout dev
    //pull in changes from remote
    git pull
    //make and commit changes as need throughout the day
    git add -u
    git commit
    //these steps only happens when I know master has changed
    git checkout master
    git pull
    git checkout dev
    git rebase master //to get changes to master into dev branch
    //push changes to central remote at end of day
    git push

    I believe this should be a fairly standard workflow for a single developer.

    Now with all that out of the way, to the purpose of my question. I recently ran into a situation that I’m not sure how to properly handle and how to prevent it in the future. Currently, my dev branch is a long running dev branch that is a major rewrite of a portion of the site. As such, it has been in development for a couple of months. While I’ve been doing this work, I’ve also been making small changes/bug fixes to Master. When I finish one of the changes to Master, I rebase dev onto Master to get the changes, then push them up to the central repo. This has been working fine.

    However, I made a change to Master a couple of days ago – the first such change in about a month. When I went to rebase, all hell seemed to break loose. I was getting merge conflicts on files that didn’t exist in Master, and I was getting the same conflicts in the same files over and over. After spending the better part of a day trying to resolve all the conflicts, I finally gave up.

    This morning, I went to try again, but before I started I examined the project commit history and found something rather odd. I found that around 15 of the commits were repeated. It showed all of the commits from 07/12/2012 – 08/24/2012. Then, I had the same commits listed again, all with different SHA Hashes. I didn’t notice it until I saw that the Dates of the commits were listed all in chronological order as you would expect, but then it suddenly jumped back into the past again.

    To resolve I did another rebase, but skipped the duplicate commits. When I did that, everything worked just as I would expect with no conflicts at all.

    So, my question to you guys is how did those commits come to be done twice, and how can I prevent this nightmare from happening again in the future? As the title of the question suggests, I assume the problem has something to do with my use of rebaseing and pushing the rebased branch. But I’m really just guessing there. I just need some help figuring out what I did wrong.

  • git set upstream to origin
  • Git (LFS): what is locking support? And should I enable it?
  • Git Clone Repo Has No .git File
  • Can I reference the git repo from a repo-level .gitconfig file for a custom binary-file diff handler?
  • PhpStorm + GIT line endings changing from LF to CRLF
  • Web-based git commit tool
  • One Solution collect form web for “git single developer w/multiple machines – rebase and commits showing up twice”

    I’d consider that your model is essentially the same as having three developers, since you have three development machines. So, your dev branch is shared in that sense. I’ve also read on SO that rebasing as shared branch leads to issues, and it’s better to merge than rebase shared branches. After reading that I’ve started using rebase for private branches only, with good results. I’d suggest creating a test repository and trying the two approaches to see how they compare.

    If I can find the other SO question, I’ll add a link here.


    Here it is Rebasing remote branches in Git

    Of course, there are many different opinions on this. 🙂

    Git Baby is a git and github fan, let's start git clone.