1

I'm in the process of introducing feature-driven development to my team. We work with git and we're just starting to create topic branches for our work. From what I understand, a topic branch should be created for every feature or bug and the branches are supposed to be "short-living".

Our workflow involves creating an issue for each bug we discover (as well as features we want to introduce, but that aside for now) and then follow up by creating a branch for it that derives from master, make some changes, commit & push and then merge through pull request after code reviews.

So far this works well, however we've had a couple cases where bug fixes were a few lines of code (like 2-3). I instructed the developers to create a branch, but this seems like overkill - i.e - creating a branch for just a couple lines of code and a single commit...

What would be best to do in such cases? Would it be better to just work on the master branch for little changes rather than creating a branch for them?

Adi Gerber
  • 582
  • 7
  • 21
  • I guess it depends on your team setup. If all clone one central repo to their local computer, they need to push into their own feature-branches for code-review and backup purposes. If all have their own central clone (like github forks) I don't see as big benefit, as all can push into their own central repo from which you make code reviews. – Mattias Åslund May 29 '16 at 07:30

2 Answers2

1

Branches in Git are ridiculously cheap; it rarely hurts to create extras. People should not feel obligated to make them, but it should be their default and they should not feel silly for having made one that turned out to be trivial, either.

Note that it's possible to "move" a commit onto a branch, as long as you have not published (pushed, or allowed others to fetch) it. For instance, suppose you have this at the start:

...--A--B--C   <-- HEAD -> master, origin/master

Then you go to fix something without first creating a branch. You make new commit D:

...--A--B--C   <-- origin/master
            \
             D   <-- HEAD -> master

but then you discover this isn't sufficient, or is the wrong fix, and decide this should be a branch fix-xxx. Just add a new branch label pointing to D (using e.g., branch fix-xxx master), then set master to point back to commit C (using, e.g., git reset --hard HEAD~1 since you are still on master right now), giving:

...--A--B--C   <-- HEAD -> master, origin/master
            \
             D   <-- fix-xxx

Now you can git checkout fix-xxx to put commit D back in the work tree and set up HEAD to point to fix-xxx:

...--A--B--C   <-- master, origin/master
            \
             D   <-- HEAD -> fix-xxx

and it everything looks as though you had created fix-xxx first, and then made commit D.

In other words, this all works both ways: feel free to create branches, which are as close to free as possible, but feel free not to create them and then "move" commits (nothing has actually moved here: we've merely shuffled the branch labels around!) later instead. Programmers can do whatever works for them.

The big advantage to making the branch first, and then not needing it later, is that this is less work than not making the branch first, and then needing it later. Also the git reset --hard step is annoyingly dangerous (you must make sure the work tree is clean first).

torek
  • 330,127
  • 43
  • 437
  • 552
0

You can have a look to these link

Git workflow

Git branch model

On my side, I would suggest to commit bug on master or development branch and then rebase before to push. Separated branch followed by a merge should be used only for new feature or minor release. I think it break the history to have to many merge.

merge VS Rebase

Example

(master)  Init --- Bug1 --- Bug2-- merge -- HEAD
(featureA)    \--- 1 --- 2 ------- /
Community
  • 1
  • 1
Flows
  • 3,040
  • 1
  • 19
  • 49