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
+20-5Lines changed: 20 additions & 5 deletions
Original file line number
Diff line number
Diff line change
@@ -405,12 +405,27 @@
405
405
\includegraphics[scale=0.9]{Git Tree}
406
406
\end{figure}
407
407
408
-
\subsection{Combining Commits}
409
-
The final way we can manipulate commits at the intermediate level is to combine them or "squash" the commits. There are two main ways to do this. The more advanced way is using rebasing, which I will talk about in the section on advanced usage of git. The easier and more typical way to squashing is to add the \colorbox{light-gray}{\textbf{- -squash}} flag when using \colorbox{light-gray}{\textbf{git merge}}. This will take all of the commits you have done in that branch and then combine them together on the merge. You can also do this manually in GitHub when merging there or submitting a Pull Request, which I will talk about later. You can also squash the last several commits by using \colorbox{light-gray}{\textbf{git reset --soft}} followed by the reference to the commit you want to go back to so you can commit again with all of the files together.
408
+
\subsection{Combining Commits}
409
+
The final way we can manipulate commits at the intermediate level is to combine them or "squash" the commits. There are two main ways to do this. The more advanced way is using rebasing, which I will talk about in the section on advanced usage of git. The easier and more typical way to squashing is to add the \colorbox{light-gray}{\textbf{- -squash}} flag when using \colorbox{light-gray}{\textbf{git merge}}. This will take all of the commits you have done in that branch and then combine them together on the merge. You can also do this manually in GitHub when merging there or submitting a Pull Request, which I will talk about later. You can also squash the last several commits by using \colorbox{light-gray}{\textbf{git reset --soft}} followed by the reference to the commit you want to go back to so you can commit again with all of the files together.
410
410
411
-
\subsection{Bisect}
412
-
The final intermediate command is \colorbox{light-gray}{\textbf{git bisect}}. Using bisect allows you to do a binary search through your commit history to find the moment your code stopped working or a change was made. to start the search, type \colorbox{light-gray}{\textbf{git bisect start}}. This will go to the middle commit of the history. If the code still works, you type \colorbox{light-gray}{\textbf{git bisect good}} to move earlier in the history when searching and type \colorbox{light-gray}{\textbf{git bisect bad}} if the current commit still has broken code. Following this process, you will quickly be directed to the commit that broke your code.
413
-
411
+
\subsection{Bisect}
412
+
The final intermediate command is \colorbox{light-gray}{\textbf{git bisect}}. Using bisect allows you to do a binary search through your commit history to find the moment your code stopped working or a change was made. to start the search, type \colorbox{light-gray}{\textbf{git bisect start}}. This will go to the middle commit of the history. If the code still works, you type \colorbox{light-gray}{\textbf{git bisect good}} to move earlier in the history when searching and type \colorbox{light-gray}{\textbf{git bisect bad}} if the current commit still has broken code. Following this process, you will quickly be directed to the commit that broke your code.
413
+
414
+
\section{Advanced Usage of Git}
415
+
This last section on the Usage of git are more advanced techniques that I have at least used on occasion, but are by no means the full extent on all of the other things you can do with git. I may need to make use of the things in this section a couple times a year or in special cases.
416
+
417
+
\subsection{Rebasing}
418
+
Rebasing is a powerful technique that allows you to drastically alter your commit history in multiple ways. If you enter the command \colorbox{light-gray}{\textbf{git rebase -i}} followed by a reference to how far back in the commit history you want to go, the terminal will change to a screen that uses vim that allows you to do mulitple commands listed at the bottom of the screen. On screen you will see a list of commits with their SHA values and to the left of each commit will be a keyword. By default the keyword will be pick. This keyword says that you want to change the messages of those commits. Another common keyword is drop. This tells the rebase that you want to delete those commits. \textbf{Only do this if you know everything in those commits is something you want to delete.} The final common keyword is squash. Like before, using squash will take all of those commits and combine them together. You will also have the option of changing the combined commit message or allow it to default to a list of all the commit messages. The last main usage of rebasing that I use is you can rearrange you commits on screen if you find a specific reason to. For example, you may want to group commits by the things they change. Beware of doing this if the commits work on the same files as you may accidentally revert a change. When you are done, you write and quit like usual and the rebasing will take effect. If you picked options that affect commit messages, you will keep getting screens where you can change the commit messages one by one in order of the commits on the rebasing screen.
419
+
420
+
\subsection{Cherry-picking}
421
+
Cherry-picking is a technique to take important commits out of other branches and make copies of them in your current branch. Lets say there is a case where someone is working on a feature and they find a way to fix a bug in the main code. They may not be done with the feature addition, but you want the fix as soon as possible. to accomplish this, they can commit the bug fix in their branch and you can "cherry-pick" or make a copy of that commit in the main branch by using \colorbox{light-gray}{\textbf{git cherry-pick}} followed by the commit's SHA value. This will leave the original commit in the feature branch and a copy in the main branch. Then the feature is merged in, that commit will be skipped over in the merge. For a more in-depth look at cherry-picking, refer to this \href{https://www.atlassian.com/git/tutorials/cherry-pick}{guide} from Atlassian.
422
+
423
+
\subsection{Stashing Incomplete Changes}
424
+
Lets say you are in a situation where you are working on some changes locally, but you don't think they are ready for a commit. You need to pull new changes from the central, remote repository or merge in a branch, but to do so would require to to either commit your changes or delete them. Instead, you can "stash" or save these changes using \colorbox{light-gray}{\textbf{git stash}} when you want to bring the changes back, use \colorbox{light-gray}{\textbf{git stash pop}}. You can also make multiple stashes and give them names using \colorbox{light-gray}{\textbf{git stash save}} followed by a name. You can then list the stashes using \colorbox{light-gray}{\textbf{git stash list}} and apply stashed changes back to the repository using \colorbox{light-gray}{\textbf{git stash apply}} followed by the index number of the stashed changes from the list.
425
+
426
+
\subsection{Submodules}
427
+
The final advanced technique I want to mention is using submodules. In a nutshell, using submodules allows you to clone a reference to a repository inside of another repository. When pulling the main repository, you will also be able to pull your submodules. The real strength of this in the lab is we can use shared repositories for tools, modeling, or supporting scripts that can be pulled inside of individual, experiment repositories, but all version controlled from the same place.
428
+
414
429
415
430
\section{Using GitHub}
416
431
There are three main reasons to directly go to GitHub instead of using the terminal or your GUI: to make the README, create a release, manage an issue.
0 commit comments