Team development using git and Trac in the Midnight Commander project

Indeed, on the Internet now you can find a lot of information about setting up GIT and working with it, but the issue of team development and the “workflow” of an individual project from the beginning to the end is not sufficiently covered.

I will try to fill this gap with the example of the open project Midnight Commander, not stopping on the issues of installing the necessary software, since this point is well described on the Internet, and you can easily find the additional information you are interested in yourself.

Terms and Definitions Used

• ticket - error report or about wishes, improvements. Other names - bug report, etc.
• brunch - a branch of development that exists in the version control system (in git)
• Upstream - the main branch in the version control system. For git, this is usually the “master” branch.
• stable branch - branch that has sprung from the “master” branch, tagged and released as a release (hereafter, accompanied separately)

Bug fix / add functionality

Capturing the current state of development with Trac

There is no project leader in our team as such, and the principle of fucking democracy works in our country , i.e. decisions are made collectively by a majority vote. So that the decision-making does not linger for a long time, all communication takes place in a jabber conference in real time. Who did not have time - he was late :). But if the decision requires the votes of all active developers, then a separate ticket is started to vote on the Trac project.
To avoid chaos in the development process, we adopted a number of regulations stipulating the immediate "workflow". The process boils down to several stages:

• problem identification
• ticket creation on Trac
• acceptance by the developer of the ticket
• publication of work in the form of brunch
• discussion in the room of the found solution, performance check, code audit
• approval of brunch, if the required number of developers found the decision acceptable
• upstream brunch

If one of the developers decides to fix the problem described in the ticket, or wants to add a new functionality - he designates himself as the owner of the ticket and is then considered responsible for solving this problem. Now he watches the ticket (communicates with the task designer, watches that — whether someone from third-party developers offered his “solution” in the form of patches, etc.), creates a new branch (brunch) for subsequent work in it. New branches must follow the rules of the name: XYZ_ <here_some_description_>
where XYZ is the ticket number; the description should, if possible, be meaningful and short.
Patches from the ticket are never applied directly to the “master” branch, but always go through the discussion and revision procedure as a separate branch.
After creating a branch and publishing it in the repository, the developer responsible for the ticket exposes the branch for revision (review) so that other developers can see that this ticket is ready for revision and discussion. If this is not done and the ticket is not put up for review - the branch is considered unstable and is subject to further development.
')
As an example, I will give the ticket # 1746 , in which someone bilbo described the essence of the problem with the built-in ftp client and attached a patch that fixes the problem.
Further, in the same ticket, he reports about the publication in the repository of the new branch 1746_passive_mode_over_proxy and putting it to the vote.

* owner set to bilbo
* status changed from new to accepted
* severity changed from no branch to on review
Created branch 1746_passive_mode_over_proxy
Initial changeset: b32c9e4a2a15cd50a6a07ad85b1a587328bd2cfc

After viewing the code, two developers voted for this code and designated it as approved.

* votes changed from slavazanko to slavazanko andrew_b
* severity changed from review to approved

Next, the developer merged his 1746_passive_mode_over_proxy branch with the main master branch and reported it on the ticket:

* status changed from accepted to testing
* votes changed from slavazanko andrew_b to commited-master
* resolution set to fixed
* severity changed from approved to merged
Fixed 2cfed22012ded42c2f4f47a13edc05bf405842db

Work with code under GIT control

Working on code using git, within the same ticket, comes down to the following steps:

switching to the “master” branch

$ git checkout master

getting the latest changes

$ git pull

creation of local brunch, according to the rules for naming this very brunch

$ git checkout -b 123_branch_name

Next, the developer makes changes to the source code and commits the changes ...

commit changes

$ git commit file.1 file.2 file.3

branch post

$ git-publish-branch

script git-publish-branch can be downloaded here

Code Revision

Just as there is a guide for creating tickets - there is also a guide for reviewing them.
The basic principles that we use when reviewing the code are well and succinctly stated in the article, the translation of which is published here “I hate you: your code is trash!” .
A developer who has assumed responsibility for code revision should receive answers to the following questions during the review process:

• Is the patch embedded in the overall concept of the project or is the patch a “hack”?
• Does the code look neat?
• Does the code do what it should do (which was declared in the comment to the patch)?
• Does the code add new problems (errors)?

If a patch is like (looks acceptable), then the developer reviewer should add his vote in the Votes for changeset in the format <login>, where login is the username in Trac. If the patch is not completely sinless, then you need to write to the ticket manager and change the ticket status from review to rework
Currently, the voices of two developers are needed so that the patch is applied to the parent branch (or to the “master” branch). If any reviewer adds his vote to the second, he also needs to change the ticket status to approved (approved).
During the discussion in the ticket, or during the viewing of patches, developers can remove their voices in the event of any problems.

Ideal test option:

$ git checkout master
$ git reset --hard origin / master
$ git pull
$ git merge --log --no-ff origin / 123_branch_name

simpler option

$ git checkout origin / 123_branch_name -b 123_branch_name

Further assembly, testing, code review, review.

Patch application

After the audit procedure and obtaining the required number of votes for the brunch, the developer can inject his changes into the main trunk of the repository. At the same time, the following regulations must be observed:

• NEVER (!!!) do not rebase a stable branch against the “master” in order to merge fixes!
• It is necessary to indicate in the first description of a commit the ticket number in the format relative to which the brunch was created, something like this:
  

  Ticket # 123 (ticket summary)
  <blank line>
  add: some text ...
  fix: some text ...
  

  
  this will help to further connect, through the description of the first commit, the poured brunch with the ticket number on the Trac.
  
  
• Be sure to relocate your brunch relative to the parent branch.
  
  for example, if brunch is based on the “master” branch
  

  $ git checkout master
  $ git pull
  $ git checkout 123_branch_name
  $ git rebase -i origin / master
  

  
  the -i switch is indicated if you need to make an interactive relocation (if you need to remove / glue / rearrange individual commits)
  
  After that, you need to update the branch on the server
  

  $ git push origin + 123_branch_name
  

  "+" indicates that a forced update of commits in the remote brunch is necessary
  
  NB: If you do not rebase, then a situation is possible when other developers have already poured their competing changes into our parent branch, and at best the story in it will be confused and muddled, and at worst - the parent branch will stop gathering or will work incorrectly.
  
• Merge with the parent branch
  

  $ git checkout master
  $ git merge --log --no-ff 123_branch_name
  

  
  the key --log shows in the merge commit, a list of patches that are entered by this merge;
  the --no-ff key allows you to generate a merge commit even if the branch is a child of the parent's top (it is easier to track which patches were made within this ticket). This key greatly simplifies the understanding of commit commutations.
  
  update data in remote repository
  

  $ git push origin master
  

  
  deleting 123_branch_name branch on the server and locally
  

  $ git push origin: 123_branch_name
  $ git branch -d 123_branch_name
  

  
  
• Be sure to record the fact of the merger in the ticket, as mentioned above, by writing a comment in the form
  

  Fixed 2cfed22012ded42c2f4f47a13edc05bf405842db
  

  
  where 2cfed22012ded42c2f4f47a13edc05bf405842db is a merge branch.
  
• Close the ticket with the status “merged”
  

Uff ... everything seems, thank you for your attention ...

PS: I would be happy to read how it works for you.