Create git documentation

[ericchu94]

1. Use similar file location as #3
2. Create documentation
   • Setup (git name and email)
   • git cloning
   • Tackling and issue and creating a feature branch
   • Adding and committing changes
     • Formatting commit message
   • Pulling and merging
   • Pushing

[ericchu94]

@allenh Please review

[allenh]

@ericchu94 do you think it's good to have another set of documentation on how to use the Github's desktop client? It's the same as the command line but it's a GUI so probably easier to learn as a beginner.

[allenh]

@ericchu94 I made some suggestions on the commits and found one spelling mistake.

[ericchu94]

@allenh I do think it is a good idea to have a guide on using Github's desktop client. There are many guides online (eg: Github for Windows - User Documentation)

However, a guide to using the desktop client is not specific to this project, and is therefore out of scope.

[ericchu94]

@allenh I have fixed my typo and replied to your suggestions, please review.

[allenh]

@ericchu94 I made some other comments for the replies.

[ericchu94]

@allenh Please review

[allenh]

I think this issue is finished.

[ericchu94]

@FlipEnergy please review

[FlipEnergy]

@ericchu94 Some questions for clarification:

1) Setup: This section is about basic setup for Git on our local computer, correct? Just do what the following link says under "Setting Up Git"? (link is for windows) https://help.github.com/articles/set-up-git/

2) Cloning: Your documentation suggests using command line. We can basically clone so we have a local copy by using (in my case) the windows application instead of the commands and keep it synced, right?

3) Tackling Issues: under "3. Add and commit these changes", when talking about the commit message, for example the first line being a summary, should that be in the description or just as the commit name. Since when commiting changes, we are already given two places to describe the commit, a title/summary and a description area. So by saying first line and second line, it confused me.

4) "5. Pass code review": Do we always assign review to you, @ericchu94, after we think we're done our issue for first review? Also, after we pass the final code review, are you, @ericchu94, always responsible for the merging of the branch?

Sorry for my lack of git experience.

[ericchu94]

No need to apologize.

1. The link you provided is to setup the "GitHub Desktop Client". This client is specific to GitHub and is not required (I don't use this client). You can follow the instructions as specified by your link, and it should work fine (but I didn't really look through the entire article).
2. It doesn't matter how you follow the steps. I am providing basic examples (from what I use myself). As long as you achieve the same result, anything works.
3. The title is the first line, the description is the 3rd line and up; GitHub just provides a simple abstraction.
4. The issues documentation illustrates code review procedures, as it is not specific to git. Please refer to that document and let me know if anything is unclear.

[FlipEnergy]

@ericchu94 Only one question left. Does the assignee merge the finished branch (after review and all that) or do they just need to close the issue and then you merge it?

[ericchu94]

@FlipEnergy I don't know. What do you think?

[FlipEnergy]

@ericchu94 I think as the owner, once all reviews are done, you should merge the branch as the last step before closing an issue. It doesn't take long anyways. So maybe this step should be added to issues.md (https://github.com/ericchu94/chat/blob/gh-3/documentation/issues.md#lifecycle) as well?

[ericchu94]

I agree that the person closing the issue should also be the merger, but I think the review documentation states that the person who is assigned to the ticket last is not the owner.

However, I don't think this is a part of the issues documentation, as it is specific to git

[FlipEnergy]

@ericchu94 Oh, I mean owner as the owner of the whole repository.

However, as you stated, the alternative is to let the assignee (the person who worked on the issue) close and merge after the reviewing process is done. This, I think, is good as well but then I would change the intro to "Tackling Issues" from

"The workflow for resolving issues involving the repository is as follows:"

to

"The following workflow steps are to be done by the person who is assigned to resolve an issue involving this repository:"

[ericchu94]

@FlipEnergy I implemented your suggestions. Please review

[FlipEnergy]

@ericchu94 I see no more problems.

[ericchu94]

@allenh please review again

[ericchu94]

I've added delete branch instructions and implemented suggestions. @allenh please review again

[allenh]

@ericchu94 Is conflict resolution necessary to be included in the documentation?

[ericchu94]

Added merge conflict resolutions @allenh please review

[allenh]

@ericchu94 It looks good to me

[ericchu94]

@FlipEnergy please review again following changes mentioned above

[FlipEnergy]

I see no problems.

[ericchu94]

@r29sun please review

[r29sun]

@ericchu94 It looks good to me.

[ericchu94]

merged