You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: Git Tutorial.tex
+8-2
Original file line number
Diff line number
Diff line change
@@ -424,7 +424,7 @@
424
424
425
425
\begin{figure}[ht]
426
426
\centering
427
-
\includegraphics[scale=0.9]{Git Tree}
427
+
\includegraphics[scale=0.85]{Git Tree}
428
428
\end{figure}
429
429
430
430
\subsection{Combining Commits}
@@ -502,7 +502,13 @@
502
502
\subsection{Creating Issues}
503
503
Issues are a great way to track any of the problems or improvements you want to make in your code. You can also assign jobs to others in the lab by assigning them issues. If you want to close an issue, you can do this manually in github, or you can close it with a commit message by following \href{https://docs.github.com/en/enterprise/2.16/user/github/managing-your-work-on-github/closing-issues-using-keywords#closing-multiple-issues}{these instructions}.
504
504
505
-
Documenting your bugs, features you want to add, and any future changes that need to be made is necessary for a few reasons. The main one is that it helps regulatory bodies like the FDA or the IRB know exactly when and how we found and solved problems in our code and how we did our due diligence in making sure we have safe code. Documenting issues also helps you keep your thoughts in order and your can even organize your issues into groups using projects on Github. I usually make a project for improving test code and another for analysis code. Projects also allow for automation in making issues into categories like to-do, in progress, done, and wont fix. Finally, making issues allows you to organize a team of people fixing code by allowing you to assign jobs to people and setting milestones in github.
505
+
Documenting your bugs, features you want to add, and any future changes that need to be made is necessary for a few reasons. The main one is that it helps regulatory bodies like the FDA or the IRB know exactly when and how we found and solved problems in our code and how we did our due diligence in making sure we have safe code. Documenting issues also helps you keep your thoughts in order and your can even organize your issues into groups using projects on Github. I usually make a project for improving test code and another for analysis code. Projects also allow for automation in making issues into categories like to-do, in progress, done, and wont fix. Finally, making issues allows you to organize a team of people fixing code by allowing you to assign jobs to people and setting milestones in GitHub.
506
+
507
+
\subsection{Forking}
508
+
On GitHub, there is an option at the top labeled as fork. You can do this on any public or private repository that you have access to and it will create a copy of the repository in my personal profile. The benefit of this is you can make large changes to this copy of the repository without affecting the original. If you want to then add some or all of those changes to the original, you can submit a pull request, which I will talk about next. Be careful when making forks. This is not a way for you to make multiple copies of the same code as this defeats the purpose of version controlling. There may be better options depending on your situation like branching to add a feature or using submodules when you want the same support scripts in multiple repositories. The only real time to fork is if its a repository outside of the lab or you want to create a whole new experiment where you will be changing the code to the point where it would no longer work for its original purpose.
509
+
510
+
\subsection{Pull Requests}
511
+
The final information you need to know about GitHub is they have a feature called pull requests. This is something we would have to turn on for repositories and the main purpose of them is so that a senior person can verify code. It works similarly to an issue, but is usually done when merging a branch to the main code. It will signal a senior person and ask them to review the code before approving the pull request. As of writing this, the Tyler lab does not do pull requests as we are a small team that can self manage our code well enough, but as we get bigger and want to collaborate, we will want to enable pull requests on code we share to make sure we only accept code we want integrated into our repositories. Pull requests will generally by done directly on GitHub, but we can also make settings that make pull requests under certain conditions when people push code.
506
512
507
513
\section{Conclusion}
508
514
The most important thing for you to do is keep the central repository of code on GitHub up-to-date. We all use each other’s code so we need to know that what is on GitHub is experiment ready. Clear documentation is also important. I shouldn't need to ask you what something does or why you did something. The changes should be documented well in commit messages and your code should have enough comments for me to read it clearly. Add things to the ReadMe if you think it will make the usage of your code clearer.
0 commit comments