Minimal GitHub for reassurance

The multitude of GitHub terms and command line options has always been so dizzying for me that its main objective has never been met: reassuring me a safe way back from trying out changes of my code. Finally I have found some minimal procedures for my simple use case.

At some point of trying out changes, I give up keeping track of the many interdependent changes (because this feels like herding cats) and it is no longer possible to revert all my changes with manual methods such as Undo/ Redo, comment-out/ uncomment individual lines, or going through all the red/ green marks from the Changes display. (Comparing this with knitting, I have to rip it all up and start again.) This is where GitHub offers a great affordance: In the Changes navigation pane on the left, right-click the file and then click “Discard changes…“.

But sometimes there is some partial success that I do not want to discard along with the subsequent changes. This is what the “commit” command is all about. But what if I am not sure yet if the partial success will lead to a final succes, or if is must eventually be discarded, too? This is where the “branch” concept comes in. Yet, creating a Branch seemed to be a nightmare:

Once I switched to that new branch, all the code in my Development Environment (Eclipse) was silently changed, and I did not know how I would get it back. Even worse: previous experience suggested that not all files were correctly restored, or not immediately, not even when I clicked them. (Only after I found and used Right-click > Refresh on the project entry). This was not the safety I needed when confusion and wreckage had happened, and I avoided branching. The many descriptions available on the web (one nerdier than the other) just made me feel like it is me who is the “git”.

Finally I learned what the unfortunate default of “stashing” means, and that it is the opposite alternative that does exactly what I needed:

Now I can “commit” my partial success “to” the risky branch. Then the Changes display is reuseable again for new red and green marks which normally make life so much easier:

• trying small things out until something works,
• then revisit the few logical bunches of changes (I love to see how the changes belong together),
• cleanup what would be embarrassing to publish as open source,
• “commit” within the experimental branch,
• and move on to the next challenge on a fresh cleared display of changes.

Once I decide to ‘rip it all up’, the only thing I need is strong nerves to trust that switching back to the “master” branch will indeed restore all my work. (Which I have saved by Right-drag > Copy-here of my entire source folder within my desktop, anyway, just in case).

Alternatively, if I decide to keep all the changes, the “merge” procedure gets again a bit more adventurous: I follow the dialogues on the GitHub web page to create a “Pull request” and to commit it:

• Upon clicking “Branch” > “Create pull request” on my GitHub Desktop, it says : “Your branch must be published before opening a pull request.”, so I press the Blue buttton called “Publish branch“
• which leads me to a confusing GitHub web page titled “Open a pull request” and it has a green button called “Create pull request“;
• On the next page, I have to scroll down to a green button “Rebase and merge“;
• (a drop-down arrow next to the button offers two alternatives that are equally mysterious and unexplained as “Rebase”, namely “Merge commit” and “Squash and merge”, so I stick to default option, Rebase);
• another green button asks me to “Confirm rebase and merge“, and pressing this leads to a success message “Pull request successfully merged and closed”.
• After the next automatic “Fetch origin” on my GitHub desktop, it shows the commits that I had sent to my experimental branch just like the normal commits in my master branch.

(It was unexpected and a bit uncanny that my commands on the github.com web site, directly changed the code files on my local Eclipse IDE (right ‘under my feet’). But I did not find a procedure on the desktop that was made for graphical GUI rather than command line CLI. Probably, the GUI and CLI camps fight and see each other as ‘gits’ instead of helping each other).

Frankly, I cannot understand how it has become fashionable even for the plain texts of humanities scholars to just store them on GitHub, without any backup intent. Probably it shall prove digital literacy and nerdiness to fumble with fancy command prompt incantations. But I suspect it may rather push off traditional scholars and widen the gap.