I’ve just started using git, and am impressed with the workflow differences from SVN, but I’ve run into one structural/setup question that the documentation doesn’t seem to intuitively explain how to set up, and I’m wondering if it’s even possible.
My setup is that I have several computers I do development from (desktop and laptop), so, to more easily keep in sync and provide backup for the git repository, I set up a “public” bare repository on my home Linux server that I can ssh into from both desktop and laptop. It’s not really public, since it requires SSH access to the box to get to.
My problem comes when I do changes on my desktop, I can easily push changes to the server repository (I have the mirror flag set for the origin remote on that repository), and using gitx I can see that the local and remote states look identical, and each of my individual commits has been logged to the server.
The question is when I switch to my laptop, which I use rather infrequently, the git repository there is likely several commits behind the server version and needs to be updated. I started using git pull to get those changes local, but rather than duplicate all the individual commits on the server to the local repository, it adds one new ‘merge’ commit to the local repository, and gitx shows merging in the remote repository branch at that point.
Is there a command/workflow that would let me update the local repository to the exact state of the remote repository (such that if I do a git push --mirror no data would be lost)? Would I have to delete my local repository each time and git clone it again each time?
Currently no one else would need access to this repository, though in the future it might become a public repository for people to pull from, so answers that don’t destroy that possibility would be appreciated.
Edit: My commits do include rebasing branches off of the master branch; could that be what’s triggering the git pull command to show as a merge? Is the --rebase flag what I need then?
Solution Explanation: It turns out I had done the following to set up my repositories:
- Use laptop to initialize a git repository
- Push laptop repository to server (commit A)
- Made a change and committed it on the laptop (laptop at commit B)
- Desktop clones server repository (commit A)
- Make changes on desktop and commit (commits C, D, E, including rebasing branches)
- Desktop pushes to server (server fast-forwards to E)
- When laptop pulls from server, results in a merge (since B cannot fast forward to E).
- Laptop merges, and pushes changes to the server
- Desktop now has to merge as well.
Because of that one extra commit that was an unintentional newb mistake, it led me to think that it would always be a merge. On Xentac’s suggestion, I went back and found on the laptop that I had made a merge that wasn’t pushed to the server, which was the culprit, and once I got all three really in sync, git pull --ff (forcing only fast-forward merges) works just fine, and warns me if something is out of sync before doing the merge.
Because you have commits in your laptop’s master branch that aren’t in your server’s master branch, every time the server changes, the laptop can’t just update the master branch pointer. That’s why you’re creating merge commits.
If you want to continue having changes that aren’t stored on your server but just stored on your laptop, you’ll want to
git fetchand thengit rebase origin/master. The fetch will download the commits from the server but not change your local branches and the rebase will recreate your laptop’s master branch changes on top of the server’s master branch (origin/master).It’d probably be better to not have those commits dangling around though. Can’t they be integrated into the whole codebase to just have one common history?