Manage Shift Hours

[vubo]

Upgrade Manage Volunteer Shifts page.

New shift logged hours functionality for administrators: edit, log and clear hours.

Now we have Upcoming Shifts list and Shifts with Logged Hours list.

In the Upcoming Shifts list administrators/managers can Cancel Shift Registration and Log Hours for a volounteer.

In the Shifts with Logged Hours list administrators/managers can find logged hours, edit this hours and cancel them.

#71 and #69

[tapaswenipathak]

@vubo For the commit message, you should always tell what it is doing. You edited setting.py, we can see a diff. But the commit message should make someone realize with a single look, what she can expect in the diff.

So instead for Update settings.py, you can write something like, Replace hard coded username, password with general values.

Everything else, looks awesome 👍 💃

[vubo]

@tapasweni-pathak thank you for the tip!

I wanted to merge the commits, but still did not get it 😁

When I do

git log --oneline systers/develop manageShift

I see only one commit (no b0f6390 Update settings.py)

d43819e Manage Shift Hours
a6cd196 Merge pull request #84 from vubo/uniqueEmail
16567d7 Merge pull request #83 from vubo/location
97146d7 Unique email field

[tapaswenipathak]

@vubo I now observed that for every new feature, you create a new branch, why?

For your issues, can you check do you still have those changes in settings.py. If yes, then check git show commit_hash_code. Are they already merged?

[vubo]

@tapasweni-pathak I get it! There is only one commit "Manage Shift" now. It was a sync problem on my side.

I read somewhere that it is a good practice to create for every new feature a new branch. Should I not do it?

[tapaswenipathak]

Cool. 😄

I don't know. I find it no useful. You have to handle so many branches. It's good to make a separate branch in your forked repository to add new features. Its good to make a branch for a related feature list. But a branch a feature, I see no use of it. How it is gonna help you in organizing things. Can you please link me to that article?

[vubo]

@tapasweni-pathak here are some examples (Feature Branch Workflow):

• https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow
• http://bitbashing.io/2015/02/10/bpf-in-practice.html
• http://programmers.stackexchange.com/questions/235504/branch-per-feature-what-are-the-actual-benefits-and-risks

For me it is useful, because all commits for one feature are in one branch. So I can work in parallel on multiple tasks. I can also create multiple PRs and not to wait for previous PRs will be merged.

[tapaswenipathak]

@vubo Okay. I'm still not convinced if it is a good practice. But it sounds useful for you as you don't need to wait for previous PRs and to get merged. 👍

I think changes in settings.py are lost. I don't see it in diff. Is that what you want?

[vubo]

@tapasweni-pathak yes, exactly, these changes were wrong. Thank you!

[tapaswenipathak]

@vubo The previous changes in the settings.py were unnecessary you mean?

[vubo]

@tapasweni-pathak yes. Now this PR is in order.

[tapaswenipathak]

👍

[tapaswenipathak]

Give me some time, I want to test this one a bit. Till today evening I'll merge it. 😄

[tapaswenipathak]

@vubo Thank you for the Atlassian link. I now used it and find it pretty amazing. Thanks for making me realize how nice it is to use a branch per feature. 💃 👍

[vubo]

@tapasweni-pathak thank you! I am very happy to read this 🌷 ✨

I wanted to ask you, what do you do with the changes that you do not want to commit, but you want to leave them for your further development? It can be Django migrations files or some your admin passwords in the code.

[tapaswenipathak]

@vubo If something I have is big, that will take a lot of time to write again, I try not use git add -A and add file by file, that have other changes. Otherwise I keep a copy of file which does not have a passwords e.t.c and place it if I want to use git add -A only.

I do not think this is the best way to do it. But I do it like this. Let me know if you find something better.

@willingc do you have any suggestions on this?

[vubo]

@tapasweni-pathak thank you. Yes, I do the same thing. But if I find something better, I'll let you know.

[willingc]

@vubo @tapasweni-pathak If I am understanding the question correctly, I put files that I want to keep but not commit into a .gitignore file for the repo.

I rarely, if ever, use git add -A. Instead, I add those files that I wish to stage for commit.

[tapaswenipathak]

@willingc I know .gitignore. But this is an awesome use of it. 👍 Thanks.

But again if you want some of your changes to be committed and not others in the same file, which happens with me sometimes then you have no other choice then to undo some and keep some and then commit. :(

[willingc]

@tapasweni-pathak Ah... same file but different contents.

First, I create multiple branches (i.e. feature-working, feature-experimental or feature-optionA, feature-optionB). I commit the desired changes to the one of the branches while committing all changes to the other branch. If needed I can compare the files later on and make changes as needed.

[tapaswenipathak]

👍

[vubo]

@willingc thank you for the tips! I did not use the .gitignore file.