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 collective development and the “work process” of a particular project from beginning to end is not adequately covered.

    I’ll try to fill this gap with the example of the open Midnight Commander project, without dwelling on the issues of installing the necessary software, since this moment is well described on the Internet, and you can easily find additional information that interests you yourself.

Terms and definitions used

• ticket - report on errors or wishes, improvements. Other names - bugreport, etc.
• brunch - a development branch existing in the version control system (in git)
• Upstream is the main branch in the version control system. For git, this is usually the master branch
• stable branch - a branch that is branched off from the master branch and is tagged and released as a release (it is followed separately separately)

Correction of errors / adding functionality

Capturing current development status with Trac

    Our team does not have a project leader as such, and we have the principle of fucking democracy, i.e. decisions are made collectively by a majority vote. So that decision-making is not delayed for a long time, all communication takes place in the jabber conference in real time. Who did not have time - he was late :). But if the solution requires the votes of all active developers, then a separate ticket is launched for voting on the Trac of the project.
In order to avoid chaos in the development process, we have adopted a number of regulations stipulating the immediate “work process". The process comes down to several stages:

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

    If one of the developers decides to fix the problem described in the ticket, or wants to add new functionality - he appoints himself the owner of the ticket and is further considered responsible for solving this problem. Now he observes the ticket (communicates with the task manager, monitors whether any of the third-party developers suggested his “solution” in the form of patches, etc.), creates a new branch (brunch) for further work in it. New branches must follow the naming rules: XYZ_ <here_some_description>
where XYZ is the ticket number; the description should be meaningful and short if possible.
    Ticket patches are never applied directly to the “master” branch, but always go through the discussion and revision process as a separate branch.
    After creating a branch and publishing it in the repository, the developer responsible for the ticket exposes the branch for review (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 ticket # 1746 , in it someone bilbo described the essence of the problem with the built-in ftp client and applied a patch that fixes the problem.
Further in the same ticket he announces the publication in the repository of a new branch 1746_passive_mode_over_proxy and putting it to a 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 on review to approved

Further, the developer merged his branch 1746_passive_mode_over_proxy with the main branch master and reported this in 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 the control of GIT

Work on the code using git, within one ticket, comes down to the following steps:

switching to the "master" branch

$ git checkout master

getting the latest changes

$ git pull

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

$ git checkout -b 123_branch_name

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

changes

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

branch publication

$ git-publish-branch

git-publish-branch script can be downloaded here

Code revision

    Just as there is a guide for creating tickets, there is 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 takes responsibility for code revision should receive answers to the following questions during the review process:

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

    If the patch is pleasant (looks acceptable), then the reviewer should add his vote to the Votes for changeset field in the format where login is the username in Trac. If the patch is not completely sinless, then you need to write about it to the person responsible for the ticket and change the ticket status from review to rework
    Currently, two developers need votes to apply the patch to the parent branch (or to the “master” branch). If one of the reviewers adds his second vote, then he must also 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 case of any problems.

Ideal testing 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.

Applying patches

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

• NEVER (!!!) rebase the stable branch relative to “master” in order to combine the fixes!
• Be sure to indicate the ticket number in the format of the brunch in the first description of the commit, something like this:
  

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

  
  this will help in the future to connect, through the description of the first commit, an infused brunch with the ticket number on Trac.
  
  
• Be sure to rebase your brunch relative to the parent branch.
  
  for example, if the 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 specified if interactive rebasing is needed (if you need to delete / glue / rearrange individual commits)
  
  After that, you need to update the branch on the server
  

  $ git push origin + 123_branch_name
  

  "+" indicates that you need to force the commit to be updated in the remote brunch
  
  NB: If you do not rebase, then it is possible that other developers have already poured their competing changes into our parent branch, and in the best case the story in it will be confused and messy , and at worst, the parent branch will stop collecting or will not work correctly.
  
• Merge with the parent branch
  

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

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

  $ git push origin master
  

  
  removal of the 123_branch_name branch on the server and locally
  

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

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

  Fixed 2cfed22012ded42c2f4f47a13edc05bf405842db
  

  
  where 2cfed22012ded42c2f4f47a13edc05bf405842db is the merge brunch commit.
  
• Close ticket with status “merged”
  

Uff ... everything seems, thanks for your attention ...

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