- Go to terminal and clone the remote repo wherever you want it in your system. (this will set the remote repo name as
origin) - Go to the repo on Github you want to fork, and click the fork button in top right.
- Refresh page, and you should now see your forked repo.
- In terminal
cdinto that repo you just cloned locally. - Add your fork repo as a remote:
git remote add {whatever remote name you want} [email protected]:{your github username}/{repo name}.git - Your fork remote is set up now
git fetch --all # this brings all your local remotes up to date
git checkout master
git rebase origin/master # this rebases any changes you didn't have locally into your master branch
git push {fork remote name} master # this pushes all the changes from origin master into your fork repo master keeping it up to dateWhile on the master branch, run the following:
git checkout -b {feature-branch-name-of-your-choice} # this basically says take the branch I'm currently on and create a copy named X- Stage your files
git add files(add individual files if you don't want to add all files in your unstaged workspace) - If this is the first commit, run
git commit, and this will bring up your terminal editor of choice for you to write out the title, description, and a reference link to a Jira ticket. Once you're done, save and exit however you do that with your terminal editor. - If this is not the first commit, you can commit however you like, but the way I recommend is to commit fixups:
# ready to add another commit to the parent commit
git log # copy the git hash of your first commit
# exit git log view
git commit --fixup={hash of your first commit}
fixupsmake slight work when rebase/squashing your code, and I can't recommend them enough
When ready to push commits up to your forked repo, run:
git push {fork remote name} {branch name}When ready to rebase master into your branch (before PR is approved)
git checkout master
git fetch origin
git rebase origin/master
git push {fork remote name} master
git checkout {your-feature-branch-name}
# if you used fixups, (which I highly recommend) do the following:
git rebase -i —-autosquash master
# if you didn't use fixups, do the following:
git rebase -i master
git push {fork remote name} {your-feature-branch-name} —fhttps://stackoverflow.com/a/7244456/
If you'd like to add your approach to the following scenario, contact Evan Vinciguerra.
Let's say I haven't contributed to riskive/intel-backend yet, but now I am. I was given this task of creating a new batch service in intel-backend. So how do I do that?
If, at any time, you feel uncertain about running a git command, REACH OUT to your TL/SM/Manager!!
Git commands still make me nervous, even today
I'll open up my terminal and navigate to directory where I want to clone my new repo:
cd ~/dev/darkweb/
git clone [email protected]:riskive/intel-backend.git
# cloning...
cd intel-backend/Once that is done, I'll navigate to riskive/intel-backend and click the fork button up in the top right. (personal preference)
When GitHub is done forking the repo, I'll go back into my terminal, and in the /dev/darkweb/intel-backend/ directory, I'll add my forked repo as a new remote:
git remote add evanvin [email protected]:evanvin/intel-backend.gitThis is where I'll check the current remotes:
git remote --v
> origin [email protected]:riskive/intel-backend.git (fetch)
> origin [email protected]:riskive/intel-backend.git (push)
> evanvin [email protected]:evanvin/intel-backend.git (fetch)
> evanvin [email protected]:evanvin/intel-backend.git (push)I'll also fetch everything from remote and make sure my local is up to date:
git fetch origin
# fetching...
git checkout master
git rebase origin/master
git push evanvin masterCool! Now let's start deving!
So, I was tasked with creating a new batch job, so I'm going to make a new branch off master so I can start coding. While I'm on the master branch, I'll do the following:
git checkout -b batch/x-y-zNow I'm in my new branch and I can start coding.
Fast forward to when I'm ready to commit
I'm ready to commit, so I'll do the following:
git statusThis will lists all of the unstaged (red) and staged (green) files. I'm going to stage my work:
# Let's say I want to add all my unstaged files to be staged
git add .
# OR I want to commit just my changes to README.md
git add README.mdI'll usually check git status again to double check my work was correctly staged, then I'll commit.
git commitThis will bring up my terminal editor (for me it's nano). I'll type out my commit title, and Jira reference (and sometimes a little summary if I'm feeling spicy).
New Batch Job
Adds a new batch job to intel-backend that does X, Y, & Z.
Ref: https://zf.atlassian.net/browse/ZFE-46159Once I'm done, I'll exit my terminal (for me in nano it's Control+X followed by Y and then Enter)
Now I have a commit. I'll check this by running:
git log
> commit 9de0a6fd88596b344a5d3f86ccd14764be7d6051 (HEAD -> evanvin/batch/x-y-z)
> Author: Evan Vinciguerra <[email protected]>
> Date: Fri Jan 7 10:37:35 2022 -0500
>
> New Batch Job
>
> Adds a new batch job to intel-backend that does X, Y, & Z.
>
> Ref: https://zf.atlassian.net/browse/ZFE-46159
>
> commit 660c23a9b4c847e7f9d03082c3bf3e5161538cc2 (upstream/master, origin/master, master)
> Author: reevesrs24 <[email protected]>
> Date: Thu Jan 6 11:57:49 2022 -0500
>
> Updated Readme with makefile local compile instruction
> Ref: https://zf.atlassian.net/browse/ZFE-45861
> ...I'll usually follow up most of my commits with pushes(personal preference), so I'll run the following:
git push evan batch/x-y-zThis will push my branch up to my forked repository. If it was my first push, I also usually create a new PR into origin master.
So I'll open the remote PR page, and there is usually a a yellow box that appears near the top saying something like:
evanvin:batch/x-y-z had recent pushes less than a minute ago
and button to the right saying Compare & pull request. I'll click that button which will open a new page where I'll see my commit message and have the option to choose where I want to merge this into. Make sure theses condition dropdowns say:
base repository: riskive/intel-backend base: master <- head repository: evanvin/intel-backend compare: batch/x-y-z
If the repo dropdowns and the commit message looks right, all I have to do is click the green button Create pull request.
Now, I'll copy the url for my PR and paste it in our private team Slack channel asking for my teammates to review it.
Fast forward to after teammates review and leave comments
I now have a bunch of comments from my team, so I'm going to resolve them with code updates.
Let's say I went back into the code, still on my batch-x-y-z branch, and made the changes necessary to resolve my teams concerns/suggestions. Now I have to commit this up. The following is what I do, using git fixups, which I highly recommend.
git add .
git status # make sure that everything looks good in staging
git log
# this brings up the previous commits
# I'll copy the commit hash from our first commit for this branch
# 9de0a6fd88596b344a5d3f86ccd14764be7d6051
git commit --fixup=9de0a6fd88596b344a5d3f86ccd14764be7d6051This will take the new commit and add it into the git log list as a !fixup commit.
I'll push that up too, and throw it at the team to review again.
Fast forward to when the team ok's everything, and my PR passes drone, and I'm ready to get this puppy merged into master
Ignoring repository-specific deploy/testing required prior to merging to master for now, I'm ready to get this PR merged. But two things happened that I need to resolve before I can merge!
- We only want to merge a PR when it has a single commit
- In the time I spent deving, another team member had their work successfully merged into
master
It's overkill, but I do the following even if I had to only deal with #1 above.
git fetch origin
# fetching...
git checkout master
git rebase origin/master
git push evanvin master
git checkout batch/x-y-z
git rebase -i --autosquash master # this allows me to fixup and squash commits into oneThis will open my terminal editor to an interactive squashing window, and if I used fixup commits, this process will go by quickly and without editing.
Learn how this file works if you need to, and when you're satisfied, save and exit your terminal editor (
nano). This will squash all your commits into your first commit, and rebase them off the up-to-date master branch.
You might run into merge conflicts during this process. If you do, contact your Tech Lead/SM if you don't know how to yourself. If multiple people are working on the same branch this may lead to merge conflicts when rebasing. Git will notify the user of any merge conflicts and force the user to resolve all conflicts before continuing the rebase. If this occurs, resolve the conflicts in your editor. Most IDE's will highlight these merge conflicts for you. Resolve all conflicts, commit and then enter git rebase --continue (Note: this may occur multiple times and take several iterations to resolve depending on how many merge conflicts there are)
continuing...
I'll usually check git log to see if everything looks good and then I'll push my squashed/rebased commit branch up again, this time with force.
git push evan batch/x-y-z -fNow, in my Github PR I should see a single commit and I don't see anything like This branch is out-of-date with the base branch, then I'm good to reach out to my team again for a review, and then I ask for a review from the repo service owner (listed at top of README's in majority of riskive repos). And ask the service owner (if not stated) what the process for deployment is.