Skip navigation

Tag Archives: version control

This weekend, I made an interesting (re)discovery. I was digging though some old emails and found an email with details about how an acquaintance and I were creating a centralized git workflow.

I figured out how to keep my project in sync with yours.
I use git on the command-line, but I imagine it should translate to a GUI tool pretty easily

git add remote upstream
git fetch upstream
git stash //I had uncommitted changes that I had to get off the stack first
git rebase upstream/master
git stash apply //to reapply my changes, I had to manual merge a few issues.

Anyway, thought I’d share with you in case you get other contributors to your IDE.

Later,

Ben

This was highly relevant for me personally, as we have been discussing the benefits of SVN vs Git at work lately. SVN’s centralized structure is simple enough to understand that everyone groks it from the jump. But keeping Git in sync, with its distributed workflows, is a much more convoluted process for new users.

With the above setup to a git instance, it allows a user to maintain local changes, while still being able to keep up-to-date with the latest pushed changes. Being able to rebase, based on the most recent changes to the upstream repo (aka, the centralized shared home of the project) makes keeping everyone in a centralized git workflow so much easier.

If you add ‘–‘ to your git command, git will know not to process anything after the double hyphen as a command-line argument.
This was useful to know for the situation I just found myself in. I had accidentally cloned a repo into a directory called “–force”. I had placed the –force argument in the wrong sequence in the clone command. But when I went to remove it from git, I found I could not. Every ‘git rm --force‘ command was throwing up the usage guide for the rm command; git thought I was passing in ‘–force’ as an argument. I found out about using the ‘–‘ argument with git and ‘git rm -- --force‘ got rid of my bad directory.

%d bloggers like this: