We interrupt your irregularly scheduled blog post to brag gently inform the universe about a huge Git problem I just solved here at work.

Yesterday morning, my officemate looked over at me, brow furrowed, despondent, and says, “I think we just need to delete the repo and start over.”

I’ve been down this road before, and it’s the cause of and result of many, many frustrations. Several months ago, while working on Intermediate Python, we came across this issue as well. You may know this story in your own travels/workplaces, but everyone involved in the project had push and pull access. Everyone has push and pull access because then it is equitable and flat*.

The problem with everyone having push and pull access to the master branch is the the technical difficulty of tracking changes, the very problem that Git purports to solve. So Steve and I deleted the repo, preserved it locally (of course), and made a new repo with the same name. You may be cringing – I am too at the memory of it! It kinda-sorta-60% solved our problems, but looking through my local files on the project I really can’t discern which copy of things is the “latest” one. There are other problems in this “fix” that are so alarming I’m not even terribly interested in sussing them out as a completed project.

So, to my officemate, I said that no, we will not be deleting the repo. Rather, we will be changing our workflow. I started by researching ordinary forking systems and how to set them up, but none had any info on how to move from a pushing and pulling workflow to a choked forking system. “Choked forking system” is my term, no one else’s, but it seems descriptive in that access to PR approvals is restricted to owners.

As preparation, I resolved all branch differences. Merges from dev to master should have been done way before they were, but with everyone pushing and pulling, things were getting really murky and entangled. Those merges were really the only “gitched Earth” (à la ‘scorched earth’) actions I took. But because the project is still small – maybe 30 files in total – and because I was familiar with all of the files and major changes that had been done, I was confident in that. I then changed the permissions on the repo to READ ONLY, a crucial step that limits push access to owners only.

The next step is to actually fork the repo – since the access has been restricted, that is now the only way to alter the contents of the repo. Since our team was moving from a universal push/pull system to a forking system, it’s important to note that the contents are local to each contributor’s machine. The only thing that changes from a user’s perspective is the remote pointer. git remote add RachelsFork git@github.com:rachelkelly/RepoName.git is an approximation of how that’s done, with the fork, user & repo names needing personalization, of course.

ED. NOTE 08/08/2014: One of the biggest problem-solvers our office encountered was to ensure the destination of all of our remotes. After you fork, just type git remote to list all the remotes you have designated, and then look at the destination of each one with git remote show origin and git remote show yourForkName. You ought to designate the upstream as the original repo (with git remote add upstream git@github.com:originaluserororg/RepoName.git) and make sure your origin points to your OWN fork of the material, rather than back to upstream. Note that “upstream” is a conventional term, you may call the original repo whatever you like.

Oh gosh, another thing from this Aug 8 update before I sign off again! Sorry that this is becoming enormous. Theoretically, my friends, you can entirely eliminate merge conflicts on a user level. Before you start work, pull the upstream repo and when done writing, push to your fork and then create a pull request. Then, it is only the person/people approving PRs that resolve/s conflicts, and once it’s approved, each person will then pull ONLY from upstream! LET THE CIRCLE BE UNBROKEN

back to original post:
Here, we use the command line for pushing, pulling, committing, and the github.com GUI for forking and merging. I keep hearing about terrific client-side GUI options, and I suspect those will assist with other Git difficulties as well.

Git is a work in progress, but in the last few days I have come a LONG way. Recently I led a group of PyLadies in a Git exploration because the more I talk to people, the more people I meet who seem genuinely afraid of this tool. I would bet under 10%** of users are confident in ordinary, command-line based usage of Git. My focus in the meetup of the beginning of this month (we’re having another in a few weeks, linked above) is just to explore in a friendly setting, pushing and pulling and forking and merge-conflict-resolution. Even though Git remembers everything, it’s still intimidating to push to something that “works” now, significantly moreso if it’s production code. At the last meetup, others did some forking, merge conflict resolution, and more. It was all quite basic, but I learned a lot, ha ha! Next time, I want to have something to offer, and I think I’m getting closer to that. Someday, ma, I’ll be a git wizard!

*I will write more one day on the myth of “flat” structures.
**Pretty sure it’s much less than that.