Tag: Git

Rebase Debate

I’ve written a few blogs about debating issues with the Team Lead. Another argument we had was about the use of Git Rebasing. The blog will be quite long if I go into the detail of what this means, but:

  • Git is a type of source control
  • Source control allows you to see the changes with the date/time they occurred
  • You can create a “branch”, make your changes, then merge many changes at once into the “main” branch.
  • There’s a concept of “merge” which basically keeps the timestamps they were originally made
  • There’s another concept of “rebase” which creates new commits, so changes the timestamps like they have just been made.

This new team always rebase, and end up rebasing as they are developing in their branch. A well-known rule is that if multiple developers are working on the same branch, you cannot rebase it without causing problems to your team members.

I raised this as a potential issue because I saw many upcoming items we need to work on that need multiple developers working on a feature, or needing to work from a shared branch. The Team Lead dismissed because he has apparently never had problems working with rebase before.

As I forewarned, I got hit:

  1. Jay creates folder A with many files
  2. I branch from his changes
  3. Jay moves all those files to folder B
  4. rebases
  5. I then rebase my branch. Git can’t see the move because the history is rewritten. It keeps folder A with the old files and treats them as mine. It adds folder B with Jay’s edited files.

Later on, the Team Lead was hit with something similar.

Team Lead
rebased fine for me
 
Team Lead 
hmm this is fucking me up now
i rebased onto jay's branch which went fine
 
Me
but now there is duplicates all over the shop
 
Team Lead
now i'm trying to rebase onto develop but it's trying to apply jay's commit to it too
 
Andrew
he rebased his branch again
before merging into develop
 
Team Lead 
but it should recognise that my branch starts at my first commit though shouldn't it
 
Andrew
not if you rebased onto his before he rebased again
you just have to drop any of his commits
 
Team Lead 
ah right, not come across that before but makes sense

So if you have multiple developers working in the same branch, you should not rebase once commits have been synced by one or more team members. Rewriting the commit history means Git cannot sync new changes because it sees everything as a new commit.

Commit Messages

As a developer, you need to “commit” your work into source control. When you do this, you need to provide a message that describes the change. A bug fix or enhancement can consist of a few commits. When you use a source control like Git, you can even “rewrite” the “history” by using squash/rebase commands.

When I am writing code for my job, I often put a bit of thought into the wording to make it clear and professional. If it is for a personal side-project, I sometimes write meaningful messages, but sometimes I may group together multiple fixes, then come up with something generic like “Bug fixes”, or might commit more experimental work-in-progress under a name like “attempt” or “x feature part 1”.

It’s quite frustrating though to see colleagues write generic messages like “bug fix” which doesn’t describe what it is fixing, or how it is fixing it. Seeing messages littered with spelling mistakes is also annoying and unprofessional.

Examples include:

  • “EventNotificationBugFix After Resolving James’ Comment”
  • “bug resolved”
  • “Dev test changes from tester” (literally what does that mean?)
  • Updated the findCorrectCodeSp to findCurrectCode.
  • Taken off completly the fix Amanda done for the fix for 25477 and fixed. Included the fix for 8017 as well
  • Fix for SQLCrop issues (should be SQL Cop, our Code Analysis)
  • Fioxed further typos (ironically creating more typos when fixing typos)
  • fixed the failed unit testes (testes rather than tests. Brilliant)
  • “Post Christ’ comments re coding standards” (it’s the second coming of Christ to teach us coding standards! They meant to write Chris.)

There was a guy who worked in our short-lived Scotland office who sounded like an absolute nutcase and I have never seen someone not take their job seriously like this:

  • instructions unclear, got dick stuck in tfs 
  • what a waste of eyes
  • but fuck wasps
  • be nice to bees
  • what if there were landmines in dinosaur times

A colleague recently showed me this website https://whatthecommit.com/. I don’t know if they are based on real messages, but it shows you a new message every time you refresh. Most are pretty basic along the lines of “does this work”, but there’s some more outlandish ones if you persevere and refresh many times.

One of my team members recently submitted a change that was labelled “Crash when cancelling out of the dialog”. That describes the bug that he fixed, rather than what he fixed. Another team member provided the following good advice:

The change looks good, but your commit message isn’t describing the change. Could you just reword it so that it completes the sentence “When applied, this commit will…” please. Another way of looking at it is that every commit should read like an instruction in a to-do list. I’d use something like “Return empty collection if user cancels out of the dialog”.

Senior Developer

A stricter idea of commit messages is described here: https://www.conventionalcommits.org/en/v1.0.0/

One of our Principal Developers loves linking people to this guide https://cbea.ms/git-commit/. One interesting idea is to “Use the imperative mood in the subject line”, whereas most people would write in the past tense.

Having a clear history of file changes helps you when it comes to finding which change caused an issue, and also gives you a better understanding why it changed.

Merging for 3 days

There was a project in a code branch that needed merging in for the release. Colin volunteers to do it. I expected that it would take him half a day, depending on if there are conflicts to resolve which can be quite tricky.

3 days later, he sends it for review. A couple of developers reviewed it and left him 17 comments of “is this your change?”

Colin responds to them “No I’ll remove it.”

How has this happened? How can he mess it up so bad?

There was a project that I worked on where we delivered it in two stages. We merged our changes in, but there was one feature where we discovered a problem so we reverted one file.

Another team had merged from the master branch into their project branch to take our original changes. When they merged their project branch into master, they wrongly resolved the conflict and reintroduced the problematic change in that one file.

No idea what Colin did though, it’s almost like he had merged a different branch into his branch then had merged it to master. I’m out of theories. It took him 3 days and he had clearly messed it up.

Testing found 4 bugs with the project (which may be original bugs missed in the original testing before it got merged in). How many have they not found? That’s what worries me.

Open Source Culture

Last year, a developer suggested we get involved in contributing to open source. It’s a good way of getting our company name out there and also it gives back to the community – given that we are using many open source libraries ourselves.

Recently, a developer had used an open source library, but needed to make a small change to it. He had created a “fork” which meant he had the code showing up in his GitHub profile. An audit report runs on our profiles and it was flagged up for investigation because the repository had “public” visibility. The intent of the report is just for someone to check we don’t have our proprietary code exposed publicly.

There was some discussion, with the end result being the developer was made to remove the code. He cited “they didn’t want my name being traced back to the business”.

I wish we would just commit to ideas. Are we Open Source-friendly, or not?

Different Git Server

After being on a new project for a few months, Beavis is told he has to fix a bug in the old system. Now, both codebases are stored using Git source control, but they are located on different servers. Other than the initial connection, accessing them is the same, so if you are using the command line, the commands are exactly the same.

Beavis, a Senior Developer states that he has the code checked out from months ago, but it will be now out of date, so he needs to get the latest changes. He then says “do I need to create a new branch to get the latest code? And if so, do I create it on the server and sync it down, or create it locally and sync up?”

Beavis, it’s the same process you have been doing for the last few months. Sync to get the latest changes, then create a new local branch for your bug fix to go in.

In the end, I think he asked another developer who doesn’t understand Git very well and Beavis ends up cloning another copy of the code.

Facepalm.

Mini Musing #2

When talking about the Source Control “Git”, there’s so much jargon to throw around. Pull, Push, Fetch, Sync, Clone, Stage, Rebase, Squash, Branch, Merge, Commit, Tag…

I was talking to the Junior Developer about Git, and he comes out with this gem:

“When I think about Git, it reminds me of the game Bop It!”

“Fetch It”, “Pull It”, “Push It”

Commit Messages

Now that we have moved to Git, our Lead Developer seems to be making more of an effort to promote good “commit” messages. Over the last few months, we have joked about the quality of some of the commit messages in TFS, and how useless and frustrating they are.

“Fix bug 1756”
“Address code review comments” 
“correct previous check-in” 
“fix crash”

All of these don’t describe what has happened, or why the code has changed. With any code change, you always know it has happened to fix a problem, be it: a crash, performance issue, or refactoring to make the code easier to read.

There’s plenty of times when I’ve been investigating a bug, and you track it down to a particular file. Then you view the history of the changes to try and understand at what point the bug was introduced. When you are greeted with any of the examples stated above, then you have to look at each change and look at the linked Work Item (Bug Report). It’s great when you can just glance at the commit messages and can jump straight to the most likely culprit.

Say you are investigating a issue with Threading and you see:

“Minor refactoring of the DisplayInfo method”
“Change threading to use a threadpool” 
“Add null check to prevent crash after clearing data”

You can then just jump straight to the change that clearly states there’s a change regarding threading.

I overheard the Lead Developer tell Derek to write a detailed commit method for his latest change and he says “seriously? I never write a detailed commit message; linking a Work Item is enough”.

I was face-palming. Surely, with a few months development experience, you will learn that good commit messages are very helpful. You could argue it only saves a few clicks and a few minutes here and there; but why make your job, or other people’s jobs harder?

Useless Git

As part of my employer’s technology refresh, we will now be using Git as our source control (alongside Azure DevOps), moving on from Team Foundation Server (TFS).

Although using Git requires a different way of thinking, it is still a type of source control, so the same steps of checking out code, making changes, and checking in still applies.

I get into work, click a few buttons to “Clone” the source (it took around an hour for that to complete though), then click a few more buttons to set up a branch. Since I had been making changes before the switch-over, I then copied my changes that I had been doing in TFS into my Git repository. After 2 hours, I had my code uploaded to the server and had a decent understanding of the process.

Today, Derek was doing the same process, and by the end of the day, he had finally sent his “Pull Request” (Code Review in TFS terms)…with the assistance of the Lead Developer. He then exclaims “that’s a fairly successful first attempt”, then goes home.

Sorry to disappoint you Derek, but this is a trivial process which took you 5.5 hours longer than me, and required assistance of the Lead Developer.