
Git Sucks, What Am I Doing Wrong? - JacKTrocinskI
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&#x2F;review every little change, then merge the feature with the master remotely.  I mean what a drag.  What are we doing wrong?
======
detaro
> _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_

None 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)

------
mrozbarry
> What are we doing wrong?

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?

~~~
JacKTrocinskI
I am unaware of SVN backfiring, however I do see peer reviews as being grossly
overlooked in the project. However, Git does not solve that problem because
people just click the approve button in Odyssey without actually reviewing the
code.

~~~
kazinator
Just like traffic lights and road signs don't prevent accidents because some
drivers ignore them.

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.

------
user5994461
It looks like to me you never had to do code reviews before, then management
decided to push mandatory code review down your throat while migrating to git.
Now you have to learn to do code reviews AND to use git AND to do branching,
at once. No wonder it's overwhelming.

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.

------
mcv
With git it's also possible to commit directly to master. An SVN-like workflow
is entirely possible. But git can do more, and allows very different workflows
that allow a more distributed way of working.

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.

~~~
dyingkneepad
I think this is the right response.

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.

~~~
JacKTrocinskI
I think you guys hit the nail on the head here, we want our old workflow back!
I'm not saying that the commit to master workflow is the greatest in the world
but it worked for us and now we're blaming Git for this feature branch
workflow which we admittedly we also tried with SVN but ended reverting back
to the simple commit to trunk workflow.

~~~
mcv
There's a good chance that your employer switched to git because they want to
enable feature branches and code review on pull requests.

------
Smaug123
It sounds like someone's identified a social problem and tried to fix it
purely with technology. I'm talking about code review. Knowing no more than
what you've told us, I would guess you need some social changes too.

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.

~~~
user5994461
I really don't think that having yet another process to skip the code review
is the way to make it easier to use. Besides, the tooling won't support
opposite workflows so this will have to be hacked in somehow (typical git
commit hooks that randomly block commits with no explanation unless they have
a magic word in the message).

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.

~~~
Smaug123
Agreed that it's worth OP diagnosing the _actual_ source of friction here. My
answer was implicitly predicated on the assumption of a largeish team, and I
hadn't realised that.

------
zelphirkalt
Sounds like you are not taking the time it takes to get to know the concepts
in git or are not given the time. One does not become proficient in a DVCS in
a day. It takes time and practice. It is important to note, that git is
distributed. It is a big leap from SVN. What you perceived as simple before
might have been a serious risk everyone took.

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.

~~~
flohofwoe
SVN has much simpler concepts and a much smaller "surface area" to learn
because it is a centralized versioning system. If you don't _need_ the
features of a distributed versioning system then there's little reason for
using git (apart from "everybody's using git", which of course may be the
strongest reason to adopt it too).

~~~
thawkins
Git branching and merging vastly out classes svn, coupled with its ability to
version directory deletes and renames which svn struggled with, it makes much
more sense than svn.

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.

~~~
user5994461
Correction: Most company workflows did not use branching and mandatory code
review because they started 10+ years ago and that was not widespread practice
at the time... for a variety of reasons.

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.

------
kazinator
Your organization has chosen a poor workflow.

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.

------
hackerm0nkey
Well to me that sounds more of a process matters than a choice of technology.

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.

~~~
Delk
> 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.

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.

------
hzhou321
Great question! It rings some bells in me.

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.

------
TBurette
You didn't just change the source control tool you also fundamentally changed
the development process. You used to do continuous integration. Now you are
doing feature branching instead.

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.

~~~
user5994461
Don't get it. You're trying to say that pushing to master with no code review
is "continuous integration"?

~~~
TBurette
Continuous integration is when the developers merge their code into a shared
master branch at least once a day, ideally several times a day.

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.

~~~
dllthomas
> 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.

------
stakkur
> _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._

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.

------
dllthomas
> ask someone to approve/review every little change

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...)

------
flohofwoe
You're doing nothing wrong, if you have a well-working svn-based workflow
there's absolutely no reason to switch to git, it definitely won't make things
simpler or more efficient in your case.

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.

~~~
fiftyacorn
I came looking for a post like this.

"If it ain't broken don't fix it"

------
serty2
Hi, you should look into
[https://githubflow.github.io/](https://githubflow.github.io/) works well for
us.

------
karmakaze
The steps described sound about right, so I wouldn't say that anything is
being done wrong. I'm not aware of Odyssey. Somehow though I would consider
the steps easy rather than a big chore. How much of the friction is the actual
git operations rebase/merging vs the reviewing? If it's the reviewing step
that's a culture thing where everyone has to buy into timely feedback to run
smoothly.

------
hevelvarik
There’s too little information in this post. As other have said your complaint
aims at the workflow not the technology and you’ve provided none of the
reasons your company adopted the new workflow. I can think different
situations to which alternatively each one of which is better suited.

Though doubtlessly this new workflow is harder on you than the previous.

------
onion2k
You're not doing anything wrong. That's how git works. However..

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.

