- It's recommended to divide PR into independently mergeable parts. This not only promotes simpler designs but also reduces coupling.
- It's best to break down the PR into smaller related commits rather than having a single PR with many changes. Reviewers find it difficult to go through 50+ file changes in one go.
- At least 1-2 developer approvals are required for a PR review, except for simple changes like typo fixes or documentation updates.
- A well-written description of the PR is crucial for the reviewer to understand the code's purpose.
- Additionally, PR labels can help to give a clearer picture of the PR's status or functionality.
The purpose of this gist is to gather the best practices for using git in one convenient location and to educate more people about the standards. Especially when collaborating with others, it is essential to establish conventions to follow.
A commit should be a wrapper for related changes. For example, fixing two different bugs should produce two separate commits. It is better to keep commits as small and focused as possible for many reasons, some of them include:
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| import UIKit | |
| //2^3 = 2 * 2 * 2 = 8 | |
| /* | |
| Stack | |
| 2 * power(2,2) | |
| 2 * power(2,1) | |
| 2 * power(2,0) | |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| import UIKit | |
| func factorial(number: Int) -> Int { | |
| // base case | |
| if number == 0 { // end the recursion | |
| return 1 | |
| } | |
| // recursive case |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| import UIKit | |
| func factorial(_ number: Int) -> Int { | |
| var fact = 1 | |
| for n in 1...number { | |
| fact = fact * n | |
| } |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| import UIKit | |
| struct Queue<T> { | |
| var array: [T] = [] | |
| init() { } | |
| var isEmpty: Bool { | |
| return array.isEmpty | |
| } |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| import UIKit | |
| struct Stack<Element> { | |
| private var storage: [Element] = [] | |
| init() {} | |
| mutating func push(_ element: Element) { | |
| storage.append(element) |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| import UIKit | |
| struct LinkedList<Value> { | |
| var head: Node<Value>? | |
| var tail: Node<Value>? | |
| var isEmpty :Bool { | |
| return head == nil | |
| } |