gitlog 0.1.0 → 0.1.1
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- checksums.yaml +4 -4
- data/README.md +52 -5
- data/lib/gitlog/log.rb +1 -1
- data/lib/gitlog/version.rb +1 -1
- metadata +2 -2
checksums.yaml
CHANGED
@@ -1,7 +1,7 @@
|
|
1
1
|
---
|
2
2
|
SHA1:
|
3
|
-
metadata.gz:
|
4
|
-
data.tar.gz:
|
3
|
+
metadata.gz: b073d6ce6cd942ac6a7fef727732c0161b68f6e0
|
4
|
+
data.tar.gz: c1f3b3718f096180175771b06e0e72fc8344f2aa
|
5
5
|
SHA512:
|
6
|
-
metadata.gz:
|
7
|
-
data.tar.gz:
|
6
|
+
metadata.gz: 14e6f75c30fc900ff2a89f32d4988227c7e56e0763a849e83cf929b4769b8279c1d27c32d4229c349a28576b53436a9d9515fd2db2cac51c1627144a63da6a23
|
7
|
+
data.tar.gz: 47b4c71caf94b85cdc3d3f135cafb55ac12f7ae1ef81491b2af1124138315e8fbc7c06b0f05b201cfd14ee8528b2f09cd45bb9f02b1aaa6916429507baaa0af2
|
data/README.md
CHANGED
@@ -1,8 +1,53 @@
|
|
1
|
+
|
1
2
|
# GitLog
|
2
3
|
|
3
|
-
Welcome to
|
4
|
+
Welcome to GitLog! GitLog is a tool to get meaningful insights and formatted log of the work you have done in a git repo.
|
5
|
+
Since, nothing comes free of cost, you have to follow a few rules while writing your git commits and this tool serves you well.
|
6
|
+
|
7
|
+
## Idea
|
8
|
+
The idea came up while struggling with daily updates from the team over the standups. While the standup, many people just go through their git commits and try to see what they have worked on and try to recap that. But if someone has a large commit history, then the updates are a mess. So, to formalise this and create a defined structure for the updates, we came up with this.
|
9
|
+
|
10
|
+
Another story is with the timesheets. People forget to fill up their timesheets on regular basis and after 2-3 days they totally forget what they worked on. And again, they end up writing some messy updates in their timesheets as well
|
11
|
+
|
12
|
+
## Structure
|
13
|
+
|
14
|
+
The commits are structured into following types. Every commit has to fall under one of these types.
|
15
|
+
|
16
|
+
| type |description |
|
17
|
+
|--|--|
|
18
|
+
| ***feat*** | A new feature |
|
19
|
+
| ***fix*** | A bug or defect resolution |
|
20
|
+
| ***refactor*** |A code change that neither fixes a bug nor adds a feature |
|
21
|
+
| ***test*** | Adding or modifying test scripts or settings |
|
22
|
+
| ***chore*** | Changes to the build process or auxiliary tools, adding libraries or changing project configuration settings |
|
23
|
+
| ***style*** |Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc) |
|
24
|
+
| ***perf*** | A code change that improves performance |
|
25
|
+
| ***docs*** | Changes to ReadMe or other documentation |
|
26
|
+
|
27
|
+
## Rules to write commits
|
28
|
+
Each commit message should therefore contain three components to clarify it's context:
|
29
|
+
|
30
|
+
1. **Type:** The type classifies the _nature_ of the change being made(described above). It should always conform to one of the following types and be _lowercase_
|
31
|
+
|
32
|
+
2. **Scope:** The scope classifies where the change is being made, it might describe a certain task, an object or even a set of files. This term should _include no spaces_, but can include other characters, including capital letters and/or slashes to indicate scope paths.
|
33
|
+
3. **Subject:** The subject contains a short description of the modification that was made. It should always begin with a lowercase letter and does _not_ contain a period.
|
34
|
+
|
35
|
+
###### For optimal readability, it’s important that the overall commit message be kept as short as possible. As a general rule of thumb, aim for a 50 character limit, but consider 69 characters the hard limit. This is primarily because GitHub will truncate anything beyond 69 characters. Always write your subject in an imperative fashion, as if you were commanding someone. In other words, lines should start with “Fix,” “Add,” or “Change” instead of “Fixed,” “Added,” or “Changed.” So keep all verbs in the present tense.
|
36
|
+
|
37
|
+
### **Commit Message Format**
|
38
|
+
|
39
|
+
When writing a commit message, it’s important for us to maintain a consistent, predictable structure. This allows for easier scannability and searchability. Each message should contain a Type, Scope and Subject using the following syntax:
|
40
|
+
|
41
|
+
> ***type(Scope): subject description in all lowercase***
|
42
|
+
|
43
|
+
So, for example:
|
44
|
+
> ***feat(UsernameInput): add username text field with validation handling***
|
45
|
+
|
46
|
+
You can also choose to define your scope as a path to better organize topics:
|
47
|
+
|
48
|
+
> ***feat(onboarding/username): add username text field with validation handling***
|
4
49
|
|
5
|
-
|
50
|
+
It’s critical that this syntax is precisely followed. This allows us to list separately the different types of modifications that are included in the build, such as features, bug fixes, refactoring, project configuration changes, tests, or stylistic updates to code.
|
6
51
|
|
7
52
|
## Installation
|
8
53
|
|
@@ -21,8 +66,10 @@ Or install it yourself as:
|
|
21
66
|
$ gem install gitlog
|
22
67
|
|
23
68
|
## Usage
|
69
|
+
Usage is simple. Just `cd` to the git repo and do `gitlog my`
|
70
|
+
1. `gitlog my` - to get all the logs for today
|
71
|
+
2. `gitlog my -d yyyy-MM-dd` - to get all the logs for specified day
|
24
72
|
|
25
|
-
TODO: Write usage instructions here
|
26
73
|
|
27
74
|
## Development
|
28
75
|
|
@@ -32,7 +79,7 @@ To install this gem onto your local machine, run `bundle exec rake install`. To
|
|
32
79
|
|
33
80
|
## Contributing
|
34
81
|
|
35
|
-
Bug reports and pull requests are welcome on GitHub at https://github.com/
|
82
|
+
Bug reports and pull requests are welcome on GitHub at https://github.com/ravindrasoni/gitlog. This project is intended to be a safe, welcoming space for collaboration, and contributors are expected to adhere to the [Contributor Covenant](http://contributor-covenant.org) code of conduct.
|
36
83
|
|
37
84
|
## License
|
38
85
|
|
@@ -40,4 +87,4 @@ The gem is available as open source under the terms of the [MIT License](https:/
|
|
40
87
|
|
41
88
|
## Code of Conduct
|
42
89
|
|
43
|
-
Everyone interacting in the
|
90
|
+
Everyone interacting in the GitLog project’s codebases, issue trackers, chat rooms and mailing lists is expected to follow the [code of conduct](https://github.com/[ravindrasoni]/gitlog/blob/master/CODE_OF_CONDUCT.md).
|
data/lib/gitlog/log.rb
CHANGED
@@ -220,7 +220,7 @@ module GitLog
|
|
220
220
|
if author.nil?
|
221
221
|
author = author()
|
222
222
|
end
|
223
|
-
print_log("log_style", log_style)
|
223
|
+
# print_log("log_style", log_style)
|
224
224
|
git_logs = git_log_on_date(specific_date, author, current_branch_only)
|
225
225
|
logs = git_formatted_log(git_logs,log_style)
|
226
226
|
puts logs
|
data/lib/gitlog/version.rb
CHANGED
metadata
CHANGED
@@ -1,14 +1,14 @@
|
|
1
1
|
--- !ruby/object:Gem::Specification
|
2
2
|
name: gitlog
|
3
3
|
version: !ruby/object:Gem::Version
|
4
|
-
version: 0.1.
|
4
|
+
version: 0.1.1
|
5
5
|
platform: ruby
|
6
6
|
authors:
|
7
7
|
- Ravindra Soni
|
8
8
|
autorequire:
|
9
9
|
bindir: exe
|
10
10
|
cert_chain: []
|
11
|
-
date: 2019-
|
11
|
+
date: 2019-09-04 00:00:00.000000000 Z
|
12
12
|
dependencies:
|
13
13
|
- !ruby/object:Gem::Dependency
|
14
14
|
name: bundler
|