How do you commit in git?

Question

git

I have always believed that in the process of developing a project it is worth doing one commitfor one task. This process roughly looks like this:

• For the new task, we create a new branch based on our topic branch git checkout -b new_issue.
  
• We do everything commitin this thread.
  
• When development is finished, we can apply squashfor these commit, compress them into one and make them rebaseinto our topic branch.
  
• If something went wrong, we can roll back this one commitand everything will be the same. Find a bug, fix it and push the fix from above. (We do not change the history of the remote repository).
  

But this approach is also possible:

• For the new task, we create a new branch based on our topic branch git checkout -b new_issue.
  
• We do everything commitin this thread.
  
• Then mergethis branch into a topic branch with the flag --no-ff, in this case we will have a commit merge, which, if something went wrong, we can also rollback, fix and commit again commit.
  
• But here we have one plus, we can use the command git bisectin order to find which one commitbroke everything.
  

Using approach 1, we will have a good history in git, which commitwill be an atomic unit, but when we find a bug, we sometimes have to revise a bunch of files.
In approach 2, we will have a scary story, it will be long and confusing, consisting of a bunch of commit merges. But in this case, we can use magic git bisect, which will allow us to find the bug faster. (Perhaps this method should be used when fixing legacy code or refactoring).
I understand that perhaps this is more a matter of personal preference, but I would like to know what practice do you prefer? What other problems could there be with such approaches? Perhaps you can suggest something else?
UPD:Friends who prefer to do a lot of commits. Is it really easier for you to find bugs in this case, or is it just a placebo for you? How does it help you? Does anyone really use it git bisect?

Answer 1

I don't understand the first option. In my head, I can’t fit in at all, why try to do something for the repository. He doesn't care what your story looks like. If you need to search for something, the search will be by the names of the commits, and the more atomic, the easier it is to roll back. The more atomic, the easier it is to merge. The more frequent the commits, the easier it is for colleagues to see how the process is going. What other arguments could there be? In the first approach, how can you ever move home from the office in order to finish the work at home?

Answer 2

If you are working on a project alone, then do it in the way that is more convenient for you (it seems to me that in this case it is convenient to just lead a straight line of development).
But if you have several people working on the project, then in principle it is impossible to rebase into the main branch - you will bring a lot of problems to your colleagues. We made a merge - everything is visible to everyone, people have no problems with pushing their work.
And I don’t see a gap in a large number of merges - yes, the story is branched, yes, it’s more difficult for some third-party person to understand it, but everything is visible, and the project can scale without problems for developers.
I can recommend you this article to understand workflow.

Answer 3

I prefer the second approach because I find a detailed history and clearly visible merging points useful.
I know several projects that prefer the first approach, where in history each change is a single and atomic (indivisible) commit, and the real branch is hidden by rebasing the branches. Admirers of this approach claim that it saves them time that would otherwise be unproductive spent browsing through a more detailed and more branching story.
Such projects include, for example, Node .

Answer 4

We use the second method. If the committer is conscientious and made whole commits in his branch, it’s easy and pleasant to work. There are those who will make one significant commit, and then another dozen at the top with a fix comment (where it can be anything - from a conceptual finish to a missing semicolon). At one time I asked similar questions “how to make a beautiful story”, then what we have come to now is completely satisfied. To make it easier to crawl through the git tree, the task number is placed not only in the name of the branch, but also at the beginning of each commit message. This really simplifies life when debriefing (both graph analysis and git blame). For this to work, there are a couple of hooks - a push prohibition and an auxiliary one that substitutes the task number into the edited commit message.

Answer 5

I prefer the second one, since I often have to delve into the code of other programmers and correct their mistakes, in the first version it would take a hell of a lot of time from me.

Answer 6

Let's use the second method. A task is a branch, it can have a bunch of commits, then git merge --no-ff into the main branch (develop), releases are merged into master and tagged.
Plus: with adequate naming of branches, the repository tree looks more than beautiful. It is always clear from which task this file came out (the name of the branch contains the id of the task in the bugtracker), how the development went, and so on. Very convenient.

Answer 7

We just commit to featurebranch, and then we merge.
No loss of history, no matter what tool to use for merging - at least the gui, at least the command line, the bisect works - what else do you need?

Answer 8

I prefer the first one, with one commit.

Answer 9

We use the first option

Answer 10

I probably don't know Git Kung Fu yet, but when I use git blame to find who changed something on a line, I give up early when I have to do something like git blame -w abcdef~2^2. And sometimes I don't need to know that this line has changed several times during one holistic refactoring.
I prefer the first approach, and accordingly a linear history. IMHO measure seven times, one - squash-smerdzh.