Tag Archives: git

3 Common & Frustrating Scenarios

When using Git, your commit history can sometimes become unintentionally complex. Here are some classic scenarios that many developers have faced.

Scenario 1: Accidentally Branched from Another Feature Branch

You were supposed to create your new work branch (my-feature) from the latest main, but you accidentally branched off a colleague’s work-in-progress branch (dev-feature). Now your Pull Request includes commits that have nothing to do with your work.

# [Problematic State]
* commit C (HEAD -> my-feature)
* commit B
* commit A (dev-feature)  &lt;-- Shouldn't have branched from here
| * Latest main (main)
|/
* ...

# [Problematic State]

* commit C (HEAD -> my-feature)

* commit B

* commit A (dev-feature) <-- Shouldn't have branched from here

| * Latest main (main)

* ...

Scenario 2: Mixed Multiple Features in a Single Branch

While working on a branch (work-branch), you realize that commits C and D are actually for a completely different feature (new-idea). You want to cleanly separate just these two commits into a new branch.

# [Problematic State]
* commit E (HEAD -> work-branch)
* commit D  ┓
* commit C  ┛ &lt;-- Want to separate only these two
* commit B
* commit A
* Latest main (main)
* ...

# [Problematic State]

* commit E (HEAD -> work-branch)

* commit D ┓

* commit C ┛ <-- Want to separate only these two

* commit B

* commit A

* Latest main (main)

* ...

Scenario 3: Started New Work on an Outdated Branch

You started some new work (new-work) on a branch you created months ago (old-feature). Meanwhile, the main branch has evolved significantly, and your new commits are now sitting on top of a very old history.

# [Problematic State]
* commit Y (HEAD -> new-work)
* commit X
| * A much newer main (main)
| | * ...
| |/
| * commit B (old-feature) &lt;-- Outdated base
|/
* An old commit from main

# [Problematic State]

* commit Y (HEAD -> new-work)

* commit X

| * A much newer main (main)

| | * ...

| |/

| * commit B (old-feature) <-- Outdated base

* An old commit from main

All of these problems can be solved with git rebase --onto.

Continue reading →

[:ja]パソコン[:en]Personal Computer[:]

Managing test specifications with Git: Creating Excel from Markdown

Tuesday March 21st, 2023 Kenji

Are you writing a test specification?

There are various ways to write test specifications, such as making them as test specifications or as test code, depending on the company. I think it is common for large, historical companies to create test specifications in Excel files. When editing by multiple people, I think it is also common, at least in Japan, to use suffixes such as _latest, _latest_20230103, _latest_5 to manage versions.

I would like to know the best practices for handling Excel files, but I have no good idea at the moment, so I decided to use a program to make the differences visible in a Git repository and manage them.

However, if you put the Excel file directly into Git, the difference lines are not clearly displayed. TortoiseGit and other tools will also show you the difference, but can you make pull requests and comments there? You usually see the difference on the web page of the repository anyway. And CSV is also a bit unsatisfactory. There are tools that can edit CSV in table format like spreadsheet, but the diff display of the repository should be a simple character-delimited text, which is not easy to read. So, I thought about managing test cases in Markdown. If you can manage it in text, you can also use *nix commands. You can write test cases even if you don’t have Excel, and if you can convert it to Excel, no one will have any trouble. (The tool I used can also convert to CSV, TSV.)

Continue reading →