6 Before you go!

Like any analysis, we should tidy up before we close the git_practice repository for an extended amount of time. That being the case the Git Flow workflow suggests we: merge develop back into main prior to pushing our code to a remote.

amreimer@DFGSXQDSF206801 MINGW64 /s/RTS/Reimer/Research_Best_Practices/git_practice (develop)
$ git checkout main
Switched to branch 'main'
Your branch is up to date with 'origin/main'.

amreimer@DFGSXQDSF206801 MINGW64 /s/RTS/Reimer/Research_Best_Practices/git_practice (main)
$ git merge --no-ff develop
Merge made by the 'ort' strategy.
 fib_seq.R | 14 ++++++--------
 test.R    |  2 ++
 2 files changed, 8 insertions(+), 8 deletions(-)
 create mode 100644 test.R

The current state of the repository may be of interest since it marks the end of the development we documented in this book. A convenient way to mark a particular commit as special is with git tag. In the terminal session below I add a tag the most recent commit and add a short message detailing why this commit is special.

amreimer@DFGSXQDSF206801 MINGW64 /s/RTS/Reimer/Research_Best_Practices/git_practice (main)
$ git tag -a "v1.1" -m "This tag is synchronized with the first draft of the git book."

After you have created a tag it is useful to know how to reference them. A plain call to git tag will show the tags in the repository.

amreimer@DFGSXQDSF206801 MINGW64 /s/RTS/Reimer/Research_Best_Practices/git_practice (main)
$ git tag
v1.1

You can also use git show to reference the tag and obtain additional information about the tag and the commit it is associated with.

amreimer@DFGSXQDSF206801 MINGW64 /s/RTS/Reimer/Research_Best_Practices/git_practice (main)
$ git show v1.1
tag v1.1
Tagger: Adam Reimer <adam.reimer@alaska.gov>
Date:   Tue Jul 11 15:14:24 2023 -0800

This tag is synchronized with the first draft of the git book.

commit ef33f10150d6248b61558f63f98bd1d5acb3d771 (HEAD -> main, tag: v1.1)
Merge: 22dcfea 6466f85
Author: Adam Reimer <adam.reimer@alaska.gov>
Date:   Tue Jul 11 15:08:02 2023 -0800

    Merge branch 'develop'

6.0.1 Choosing the Appropriate Remote

Thus far I had been interacting with my private remote, as shown below (notice “adamreimer” in the URL). This is the preferred workflow for a repository of this type, which had no value to other ADF&G staff while it was being created.

amreimer@DFGSXQDSF206801 MINGW64 /s/RTS/Reimer/Research_Best_Practices/git_practice (develop)
$ git remote -v
origin  https://github.com/adamreimer/git_practice.git (fetch)
origin  https://github.com/adamreimer/git_practice.git (push)

Repositories with immediate staff interest or repositories that develop staff interest (i.e repositories associated with operational plans, any population assessment or any data analysis task which is shared internally) need to be pushed to the Division of Sport Fisheries GitHub site. Making the git_practice repository public may help interested readers who are looking for more insight into the workflow demonstrated within this book. As such the repository is about to go public. There are two ways to do this, both of which will be discussed below.

6.0.1.1 Push directly to the new site

The easiest way get your repository on the ADFG-DSF account would be push it there directly. The first step is to create a new repository named “git_practice” on the ADFG-DSF GitHub¹. After that “git_practice” repository is created you can change the URL associated with your origin remote (notice “ADFG-DSF” in the URL),

amreimer@DFGSXQDSF206801 MINGW64 /s/RTS/Reimer/Research_Best_Practices/git_practice (main)
$ git remote set-url origin https://github.com/ADFG-DSF/git_practice.git

and push to it.

amreimer@DFGSXQDSF206801 MINGW64 /s/RTS/Reimer/Research_Best_Practices/git_practice (main)
$ git push -u origin main
Enumerating objects: 49, done.
Counting objects: 100% (49/49), done.
Delta compression using up to 16 threads
Compressing objects: 100% (48/48), done.
Writing objects: 100% (49/49), 8.21 KiB | 75.00 KiB/s, done.
Total 49 (delta 14), reused 0 (delta 0), pack-reused 0
remote: Resolving deltas: 100% (14/14), done.
To https://github.com/ADFG-DSF/git_practice.git
 * [new branch]      main -> main
branch 'main' set up to track 'origin/main'.

After the push the remote repository is synced with your local directory you should create a README by opening the repository on GItHub and pushing the green button add README. This method will work for any existing repository².

6.0.1.2 Transfer a Repository

While the method above will work for any repository be aware that GitHub specific features (Issues and Pull request records) will be lost when pushed to the new remote. To illustrate that difference I transferred the “git_practice” repository from my personal account to the ADFG-DSF account: (open the repository on github), Settings > (scroll to the very bottom) > Transfer > (rename to git_practice_transfer). We can see the difference by comparing the repository that was pushed to the ADFG-DSF account to the repository that was transferred to the ADFG-DSF account. In the transferred repository there are closed pull requests listed under pull requests > 2 closed while on the pushed repository those records are missing. Notice that if the repository had peer involvement sufficient to utilize pull requests or was in a state of development that necessitated issue tracking it should have been pushed to the ADFG-DSF account earlier in it’s history.