Git Sucks, What Am I Doing Wrong?
My employer recently made a companywide switch from SVN to Git and upper management has been touting it as a big success story in emails. The thing is, everyone I speak to in the project hates it and not just because it’s new and they don’t like change. We had a simple workflow going, we changed a file and then committed it directly to trunk, before we went to UAT we created a release branch. Life was simple and things worked really well with SVN, you edited a file, committed and that was that. With Git and Odyssey it’s a whole process though, we have to create a feature branch, then commit changes to the feature branch, then pull master branch changes, merge the master with the feature locally, push the changes, ask someone to approve/review every little change, then merge the feature with the master remotely. I mean what a drag. What are we doing wrong?
41 comments
[ 2.6 ms ] story [ 72.2 ms ] threadNone of that is a requirement of git, that's the workflow your company has chosen. (although branching and code review is usually a good thing)
The problem is complex, but the first place I would consider starting: try supplying a break-glass "I want to merge this without review", but have a zero-tolerance policy for unreviewed breakages. If you break something, and it turns out you did so in an unreviewed PR that you just YOLO'ed in, you are buying cake (or whatever). People need to learn from experience that reviews really are great, and one way to show them this is by making it clear how bad it is when there are no reviews.
Note, too, that now you are working with branches, there are tons of probably-unrealised benefits available to you. Pre-merge automated test suites, for example. Personally, I would flatly refuse to work on any moderately-complex code base that did not have automated branch tests that ran before any merge to master. It would almost certainly be well worth some dev effort setting this up, because it genuinely is a huge benefit to the branching workflow.
If their team is small (less than 5 developers), don't make code review a hard blocker, there's never anybody available to code review.
You're assuming there was nothing wrong with your SVN workflow because it was straightforward and you never experienced a catastrophic failure. I suspect that had your SVN server died you would have had a very bad time. I also suspect you must have a very solid UAT process and developers who really care about the quality of the code they write, because it sounds like there was very little oversight of the code that was going to production - if it did whatever the feature needed and UAT gave it the nod that was all that mattered, right?
With git there are a few assumptions like "One day all of this is going to go horribly wrong." A hard, hard crash of the repo servers for example. With git you can just fire up a new remote and everyone carries on locally while that's happening. With SVN it's a bit harder (although still not a huge problem) but everyone basically has to down tools while it's fixed. That's a problem on big projects. Also with git the assumption is that the code is important in itself. It's more than just whether it works, but whether or not it's something everyone agrees on. The process of pull requests gives people an insight of how the codebase is changing, and enables more people to have an input. Pulling the base branch in to your local branch and fixing conflicts locally means your base branch should always work. It's always deployable. With SVN it's easy to accidentally break things and block a deploy until it's resolved. That's an advantage that's rarely necessary but an absolute godsend if someone is working on something hard that has potential to wreck havoc across all the features.
git is great but a bit annoying when everything is going right. It's worthwhile embracing it for when things are going wrong.
I've once tried to use SVN before I learned about git. I was terrified to do something wrong. I did not understand the concepts well. I just did not get it. Fortunately I did not stick around with it, but learned a little bit of git shortly after. Then simply Used what little I knew. Then at some point tagging. Then feature branches. Submodules. Pull requests. You learn step by step and don't get overwhelmed by git's complexity.
In case of git, try this: https://www.youtube.com/watch?v=2sjqTHE0zok
Most SVN workflows did not use branching and merging, becuase it was such a pain in the ass with SVN.
You folks are right about the confusion between git and the workflow, most folks use gitflow which uses master, develop and feature branches. Others like gitlabflow are quite different, but still make use of git's far better branching and merging.
Usability has always been a problem as well as tooling support (merging algorithms really used to suck and generate conflicts all over the place, not specific to SVN or to git). Git made some things easier and some things harder. I'd personally rather have a sane command line interface (that I use every day) than the ability to track a rename twice a year.
Feature branching is nice in some cases. For example in open-source project this allows a maintainer to review code (of a potentially unknown developer) before it is accepted. It also prevents a contributor to vanish leaving half-finished features.
I believe feature branching is inferior to continuous integration for most private software development teams. Feature branching along with systematic code review add a lot of friction to the integration of a developer's code into the mainline. The consequence is that developers push less commits that become bigger and integrating each developer's code together become a painful process. This starts a negative feedback loop.
If I were you I would look for the evidences that continuous integration make a team perform better and push to keep git but change the workflow back.
A mandatory code review before merging is allowed (that takes some time to be processed) leads to fewer, bigger merges. Imagine waiting for reviews of the 10 pull requests of wrote two days ago, the 10 of yesterday and 5 you created so far today. It's too unwieldy. The latency encourages you to start writing fewer bigger pull requests more spaced out in time.
As an aside, it also tends to reduce trust and cooperation within a team : reviewers become the gatekeepers of the work of contributors. That work is explicitly not trusted until it is checked. Not a great social dynamic I think.
This seems to presume a split between reviewers and contributors that hasn't existed explicitly anywhere I've worked, and has only implicitly been a thing in a handful of contexts. Usually, reviewers and contributors (... well, authors - I would call good review a contribution!) are the same set of people.
With feature branching, you wait as long needed before the feature is finished. You can only merge when it is fully finished. This goes directly against the continuous integration philosophy of committing early and often.
> How do you have stable versions of the software if you have unfinished features and hacking in the master version?
It requires a strong commitment to ensure that the current state of the code remains healthy (strong unit tests,...). New in-progress features can remain disabled through feature flags, not showing the corresponding UI or not calling the code.
> I guess this makes sense for very small teams early in the development process but then you can just skip feature branching in git for a while.
It's definitely not for every team.
Martin Fowler presents in detail the 'made up things I just wrote' in this article : https://martinfowler.com/articles/branching-patterns.html . See in particular the Continuous Integration section and the following sections.
Git has been built for a very specific decentralized development workflow, for a close-knit team with a central versioning server git is simply not the right versioning tool, since you don't get any benefits from what makes git different from svn.
"If it ain't broken don't fix it"
Though doubtlessly this new workflow is harder on you than the previous.
I use git day to day and before that used svn for a number of years. Now on the odd codebase, I tend to find svn is still in use, and I don't mind that, I just work with it.
From what you've mentioned, it does not seem that introducing git in your organization was solving a problem per-se, you "could" have the exact same flow you had with svn in git, have a single branch and call it whatever you like, e.g. "master", "develop", whatever...
What I think is happening is that someone didn't like the process you had and tried to solve/replace that with a more modern way, e.g. having feature branch, release branches, master, etc... and that it easier to technically achieve with git than with svn. Imagine doing what you doing now with svn, that'd be a nightmare, wouldn't?
On the other hand, your "new" workflow might be solving problems that you didn't realize you had. I.e. code review and approvals have the great benefit of having a 2nd pair of eyes reviewing your changes as well as spreading the knowledge throughout the team as to what's been changing, more like keeping a pulse... so that is not necessarily a bad thing.
Either that, or someone read up on what are often considered best practices with git, and then pushed that as the new process in order to be diligent when git was adopted.
There's not enough context to tell whether the process change is a solution to an actual problem or doing it because others are doing it, too.
Most of the stuff (feature branches, review of major merges) are good ideas to do, though, and something you begin to appreciate once you've got used to them. Honestly, I want a feature branch at approximately the point where I realize the feature change is going to take more than two commits or is nontrivial in almost any way. I'm not sure about requiring a review/approval for every little change if it's earlier in development, and I can understand frustration with that, but that's not really a tool-mandated process, as you say.
Code review is normal software development in all companies. Though if your team is small (somewhere less than 5 developers), it's better to make reviews optional, there's never anybody available to review.
As for git and (git) branching, you will have to learn because that's what the industry standardized on. It's a shame because git objectively sucks (it is terribly user unfriendly). You have my deepest sympathy.
You have to sell/appreciate the problems before you sell/appreciate the solutions. Git is a solution for some problems, that seems you have either solved with another solution or have (learned to) tolerated for so long that you don't regard as problems.
I started git with only a single master branch, write code, commit and push. If code breaks, we fix it. The problem is the lack of code review. Without review, we are not even conscious about how much bad code went in, or how much better code could go in. And while we were always happy coding, deep down, we also have a bit unsatisfactory that we don't get to discuss our code, missing opportunities boast our clever idea and deep foresight ...
But once we are convinced that lack of code review is the problem, accepting the git branch review workflow is easy, and we appreciate it ever since.
It rings bells of many other technologies. Some of them I had hard time to sell because others have all used to the problem since the beginning and just don't see the need to fix. Some other technologies folks are just accepting because other people are touting it, applying to their "problems" that does not exist in the first place.
Let me answer your question with your own quote:
> The thing is, everyone I speak to in the project hates it and not just because it’s new and they don’t like change.
Tech industry is all about change, and since there is so much change, we have to rely a lot of having good processes that can be applied to all sorts of changes. It does sound like your company dropped a bomb of a bunch of changes - they probably could have baby-stepped into code review before also switching to git. Too much change is hard for anyone. But I don't think your company's problem is git.
I used to be the guy that had a single branch project with pushes directly to master, live changes on production, some days had multiple deploys as we discovered bugs. While that was _easy_ from the perspective of "hey, I could just push code, and it was great", it was hard because all deploys were high-stakes, and could mean spending hours debugging and redeploying into the after hours of my work day (and this happened regularly).
Just to ask a question back to you, how many times did your company's simple SVN process backfire and cause more work for you?
Surely Odyssey keeps a record of who approved what. If you approve something, your name should be attached as having reviewed. Then you share some of the responsibility if the commit is bad.
If you're asking people to review your edit history, that's (IMO) something you're doing wrong. Branch early, commit often, but clean it up into a series of conceptually related, easy to follow changes with good commit messages before you push it anywhere (morally) shared. In SVN, commits are always meant for the world. In git, commits are meant for you until you decide to share them. Owning that helps. (Again, IMO/YMMV/&c...)
Of course your company needs to use a workflow that works for what you need it to do. It's also possible that the company needs to invest in a bit of training here. Having your employees working with a version control system they're not comfortable with can become a big problem.
OP is complaining about the workflow/process not about the tool. Instead of all that big process described, the team could simply git-clone upstream, work on their local main (formerly master) branches, then "git commit && git push && git pull" all the time and that's it: you got your old workflow back, but now with git.
You can do that with Git.
>With Git and Odyssey it’s a whole process though, we have to create a feature branch, then commit changes to the feature branch, then pull master branch changes, merge the master with the feature locally, push the changes, ask someone to approve/review every little change, then merge the feature with the master remotely.
Based on what you wrote, this seems all about the workflow your company chose to use with git, not git itself.
Developers should never be required to produce and merge "feature branches" but only properly rebased sequences of commits which keep the history linear.
With a rebase workflow, you can juggle multiple changes in the same branch (your local main branch that tracks the remote master).
I sometimes have as many as five or six separate work items going on. This is much more productive than switching among five or six branches which don't know about each other, not only due to the convenience, but also due to the integration: all six things build together and are being tested in the same image.
Git has a great "interactive rebase" feature (git rebase -i) for rearranging the order of your local commits, and combining them together. Thanks to interactive rebase, I submit properly rebased versions off all six of those items to the review system.
It's also worth learning how to use "git commit --fixup" and its variant "--squash", together with "git rebase -i --autosquash". You can make commits which are amendments to commits that are not the current HEAD. The auto-squash rebase will automatically put these commits in the right order, and configure them to be combined with their target commits. I have the --autosquash option set up implicitly in the global config.
Code review is an excellent process. I've been saved from silly mistakes more times than I can remember, and have saved others. When I'm working on my solo side projects, I'm keenly aware of the lack of review now. I've screwed up many times in ways that a second pair of eyes could have prevented.