Zenn
🐾

How to Use GitHub Step2: Develop Actually

に公開
Git
GitHub
tech

Last time, we created a repository and linked the local and remote. This time, we will develop actually with using making branch.
If you haven't read step1, I reccomend to read it first.

1. Make Branch

First, check the branch by git branch

git branch -a
# * main
# remotes/origin/main

We have a repository both of local and remote. mark * shows which branch we are on, so if you aren't on local repository, please move to local by git checkout <branch_name>.

Next, we reflect remote branch to local branch by git pull.

git pull <remote_repository_name> <branch_name>

・Example

git pull origin main
# `git pull` is also fine because we set up upper branch using `-u`

Finally, we switch the branch with using git checkout.

git checkout -b <new_branch_name>

・Example

git checkout -b feature/add_profile_page

-b switch the branch after making the branch, we can confirm it using git branch -a.

2. Develop

As a test, let's make profile.html and commit.
After making html file, please execute this:

git status
git add -A
git commit -m "add profile html file"

Pushing new brnach to remote repository with set upper branch.

git push -u origin feature/add_profile_page

In here, you can confirm branch maked at main toggle button on your github page.
As a timing of pushes, that is no need to do it that often, commits are often done when you want to keep the eidt history, and pushes are often done at good timing.

3. Merge

Do the merge when you complete the development of a application.
There are some different each pattern of existing conflict or not, but operation in first is the same in both.

First, after the push from latest local branch, doing pull request on github web page.

※ The image of merge

# remote
A -- B -- C (remote/main)
# local
A -- B -- D -- E (local/main)

# After merge
A -- B -- C ----------- M (merged commit)
          \           /
           D -- E (local/main)

3.1 Pattern of no conflict

If there is no conflict and no problem in code, we can merge from merge button at pull requests tab on github page.

The confirmation that there are no problems is called code review, typically, ask someone else to review your code.(It compelete by approve)

3.2 Pattern of existing a conflict

If there is a conflict, a alert will occur on github page.
In this case, follow the flow below:

  1. Pulling remote main branch to local main branch
  2. merge in local(merge main to local by git merge main)
  3. Natullary, conflicts will occur, so resolve them and merge　it again locally
  4. Pushing local feature branch to remote feature branch.
  5. Sending pull request again

There are many steps, but those have means. Please similar this while in beginner.

3.3 After resolve merge

After resolve merge, we can send pull request from pull requests page on github.

  1. Moving to pull request page
  2. Click New pull request
  3. Select branch to merge from toggle button(This time, select feature branch at compare toggle.)
  4. Click Create pull request
  5. Write description of pull request, setting reviewers, assignees
  6. Click Create pull request
  7. Option: If there are point to modify, modify local feature branch and push again(The contents of a pull request are updated when you push, so you don't have to recreate the request.)
  8. Click merge pull request and confirm
  9. You can delete remeote feature branch that no more needed by Delete branch button. And we can delete local feature branch using git checkout main and git branch -d <branch_name>

Please note that this operation is doing on only remote repository.

4. Rebase

The image that remote repository will be into the history of local repository.
・rebase

git pull --rebase origin main

※ Image of rebase

# remote
A -- B -- C (remote/main)
# local
A -- B -- D -- E (local/main)

# After rebase:
A -- B -- C -- D -- E (local/main)

With rebase, you can think of the remote history as "pushing ahead" to your local history. Please note to after rebase code is on local, but you don't have to consider to conflict(you can commit as is after rebase).

Your local changes don't disappear, they're just reapplied after the remote changes. Your history is nicely linear. This is a big difference from merging, which doesn't result in a complicated history with multiple branches mixed together.

5. Summary

If you come this far, I think you can at least use git and github.
From here, please get used to it through development.

This time is over. Thank you for reading.

Discussion