Is it possible in Git to work on the same sub-branch in perpetuity?

Question

High-Level Background:

My workplace has been around for decades and many of the employees here likewise. I joined earlier this year but have plenty of experience elsewhere.

I taught myself Git in my first job way back when, which was essentially a 2-man project. I screwed up many things and practiced many things, so I come from the school of hard knocks. As I wrote in an email to some of the department heads

[…] I am not a git expert. For better or worse, though, in this company I am :\ […]

We just switched to Git/Bitbucket from a more antiquated source control (one that locked files, copied files, etc). Most people (and old-timers) are acclimating to the new protocols and I and a few others are helping where we can.

The Guy I am Dealing With:

There's one dude, an older guy, who is a curmudgeon. I get along well with him but he's a tough nut to crack. he doesn't want to learn new things, he wants it to be simple. This is not a dumb guy, btw, he has been programming in C++ since it was released and, among other things, he wrote the driver we use to connect to our DB from our product (from scratch). A lot of the code he works on is his own stuff, essentially libraries that other departments use, although enough of his work is within shared code files that others modify as well.

He's accepted that I know what I'm talking about but he's an old dog; the concept of Git being "diff"-based vs actual file has usage scenarios he doesn't want learn, like creating new branches. He wants a simple procedure.

In my defense, I am a pretty good teacher. I have worked with a number of the other employees and they seem to get it now and are firing away at their code using Git/Bitbucket.

What He Wants:

Back to the curmudgeon, he wants ONE branch to work on. He doesn't want to checkout new branches, switch branches, he doesn't want to know about branches. He wants that he does his work, commits, does a pull request, and continues his work.

This is just one guy, most people in the company are willing to change. I have sat with him for probably around 5-6 hours in total over the last week. I enjoy it because we respect each other, and I also consider it my company duty as I am the best equipped here to do that (many find him tough to talk to so he kinda works in his own bubble, plus not many here have the comfort level with Git that I do). Additionally, he has wrapped his mind around some of the core fundamentals of Git, like staging, local vs remote, etc.

Although not ideal, would it be a "good enough" workaround if every so often, he merges from the master branch into his own and just works on his one branch for the foreseeable future? Hopefully I can incrementally get him to be a good "Gitizen" over time. At worst, the guy's likely to retire in a few years.

Is this workaround a ticking time bomb? Will it screw up the master-branch's history (this is assuming all merge-conflicts are resolved correctly; something not a problem for him)?

Answer 1

To git, there is no necessity to delete a feature branch after it has been merged back. Especially if that feature branch merged master directly before being merged into master itself. The tips of the two branches will be (almost) identical after the merge back, so the basis for the future development as perceived by git is also the same. (What is a "feature" branch, anyways? All I see is parent commits...)

Whether your old hand continues working on the merged-back branch, or branches a new one off master, does not really make much of a difference. The difference would simply be the commit at which the new work attaches, and, most importantly, the name of the branch.

Actually, this is one of the key advantages of git: Older versioning systems like SVN had quite some trouble with handling merge-backs, making it impossible to make more use of a branch after it had been reintegrated into its source branch.

To git, all commits on all branches look the same, and it does not care what branch name is attached to which commit. When git merges two branches, it simply determines the common base state of the repo, and merges the two change sets to that base state. The commit graph only helps it to determine the common base state, which is typically the commit from which a feature branch was started, or from which it pulled last, but it can also be the commit that master pulled from the feature branch. (What was a feature branch, anyways?!?)

Answer 2

It depends, assuming his branch would be "master" (otherwise someone else merging his branch will have headaches)

• he can pull/merge and commit+push his changes easily
• he will have a hard time working on multiple issues over a period of time. Assuming since he doesn't like branches, he won't be using stashes either (though he could invest a lot of time and work with diff/patch-files and keep all of them up to date) ** very hard to keep multiple versions of the same file updated with changes from upstream without "branches and merge only at end"
• it will be difficult to work with him together on a feature branch, sending patches to and fro by email?
• if there are other devs working with feature branches, his changes won't be visible as nicely in gitk as fine parallel lines with all the commits, instead he'll be on master only

It certainly would work, but with a toll. Different workflows for same project, more difficult analysing of features afterwards, some harder to track merge errors (yes they will happen, regardless on how diligent the dev is).

I'm sure the C++ guy with decades of experience knows his stuff and his tools almost work in magic harmony with his fingertips. So from his point of view, git is not helping him to perform better but is a hindrance. Only helpful for people with less knowhow than him, forcing the pro to change the almost perfect workflow for people who are not anywhere near it. It could be helful to remind him and yourself that you are not trying to help him, but need his help for the team/company/project as a whole.

Bottomline is, depending on amount of devs, frequency of changes, probability of parallel work on different features it's either almost impossible or a lot of time wasted which instead could have been put in new features.