Let's say that I have an application that scrapes a website. I will create a new branch called develop/pulldata. In this branch, I will work on pulling the data. One of my team members could work on applying some logic to the data, so he can create his own branch develop/applylogic. Once he has a few commits and his code is stable, he can open a pull request to merge his code to master, which you can view in the GitHub UI, to see what code he has changed and decide whether or not you want to merge, or if any changes are required.
Now, after a while, my code is done, I open a pull request to master, so my colleagues can view my code and approve or suggest changes. It's easy to view and everybody in the team knows that the master branch is stable. However, other branches do not have to be. They have to be when they are merged to master.
Whenever you start “something new” in your project, it makes sense to create a new, separate branch for that. It doesn’t matter if it’s just a little experiment or a full-blown new feature: you want to protect the mainline of code and your coworkers from all the small and big bugs that inevitably happen when new code is being produced.
- Lists of all local branches in the current repository.
- git branch
- Create a new branch
- git branch branch_name
- Switches to the specified branch and updates the working directory.
- git checkout branch_name
- Create and check out a new branch
- git checkout -b branch_name
- Deletes the specified branch
- git branch -d [branch-name]
- Combines the specified branch’s history into the current branch
- git merge [branch name]
- change the branch name
- type git branch -m a b
No comments:
Post a Comment