Documentation
SolutionDeveloperComplianceProjects
  • Introduction
  • Gitbook Guidelines
  • PRELIMINARY ANALYSIS
    • Project Initiation
    • Business Goals
    • Information Analysis
    • Solutions Evaluation
    • Risk Assessment
  • APPLICATION DEVELOPMENT
    • Scrum Framework
      • Scrum Values
      • Scrum Roles
      • Scrum Compliance
    • User Requirements
    • Product Backlog
      • User Story
      • Story Mapping
      • Grooming
      • Roadmap
      • Best Practice
    • Sprint Planning
      • Planning Inputs
      • Task Definition
      • Task Sizing
      • Sprint Backlog
      • Best Practice
    • Sprint Execution
    • Sprint Review
    • Sprint Retrospective
    • Process Control
      • Sprint Burn-Up
      • Sprint Burn-Down
      • Sprint Velocity
      • Source Control
    • Risk Assessment
      • Data Privacy & Security
      • Postpone the release
      • Lack of participation or engagement
      • Incomplete backlog items
      • Project Scope Creep
      • Third-Party Dependency
      • Integration Issue
      • Outdated Technology
      • Budget & Time Constraints
      • Inadequate Testing
    • User Acceptance
    • Release and delivery plan
    • Literature
  • SERVICE MANAGEMENT
    • Service Lifecycle
    • Receiving Ticket
    • Ticket Management
      • Maintain Attributes
      • Ticket Assignment
    • Troubleshooting
    • Escalation
    • Monitoring
    • Evaluation
    • Risk Assessment
      • Support and Maintenance
      • Insufficient information
      • Misinterpretation of attributes
      • Insufficient Testing
      • Delayed deadline
      • Lack of continuous improvement
      • Lack of Stakeholder involvement
  • REVIEW & IMPROVEMENT
    • Dashboard Analysis
Powered by GitBook
On this page
  • What are the steps for Source Control?
  • Create a new branch and make a commit to the server.
  • The next step is applying pull request.
  • The next step is reviewing the code and test it.
  • Improving the code after comments from another developer.
  • The last step is merging the code with the main branch.
  1. APPLICATION DEVELOPMENT
  2. Process Control

Source Control

PreviousSprint VelocityNextRisk Assessment

Last updated 2 years ago

During the creation of a piece of software, source code control is used to monitor changes made to source code and other text files. By doing so, the user is able to access any earlier versions of the original source code as well as any saved changes. Also, the developers check the quality of the code with reviewing and testing it.

What are the steps for Source Control?

For source control in our case, Github is used. There are several steps for managing and reviewing the code:

Create a new branch and make a commit to the server.

  1. Navigate to the main page of the repository.

  2. Above the list of files, click Branches.

  1. Click New branch.

  1. Type a name for the branch.

  2. Choose a source for your branch. Select the branch dropdown menu and click a branch.

  3. Click Create branch.

After this make a commit to the server. A commit saves changes to one or more files in your branch, just like saving a modified file. Each commit in Git is given a special ID that indicates:

  • The particular changes

  • When were the modifications made?

  • Who was the author?

When you make a commit, you must include a commit message that briefly describes the changes.

The next step is applying pull request.

  1. Navigate to the main page of the repository and click pull requests.

  1. Click new pull request.

  1. To choose the branch into which you want to merge your modifications, use the base branch dropdown menu.

  1. Type a title and description for your pull request.

  1. To create a pull request that is ready for review, click Create Pull Request.

The next step is reviewing the code and test it.

The review is done from another developer. He can also comment the changes with the author. And the author must improve his code before he merges with the main branch.

Improving the code after comments from another developer.

Sometimes, the pull request of a task is not completed after the reviewing part. Then, one developer comments the change that must be done. The other developer makes another commit to the branch with the improved code. Finally, the code is approved from the reviewer, and it can be merged with the main branch.

The last step is merging the code with the main branch.

After the review is done, the author of the pull request can merge the code with the main branch.