![]() ![]() Git commit -S -m "my first commit to the dev branch" # remove the -S if you're not "secure", secure = when you already setup crypto private and public keys (i.e "verified" green sign in github) Make your changes to the "dev" branch (your current if you follow step 1), commit and push them to the remote "dev" branch. Git push -set-upstream origin dev # push the "dev" branch to the remote. # branch's files will be cloned to the new branch by-default. # No need to git add or git commit, the current I also recommend using the Sourcetree App to see visual tree of changes and branches.Ĭreate and switch to a new "dev" branch, where your local git files are in-synced with the remote but "dev" branch does not exist yet. $ git push # pushes all “new_branch” commits to both branches - “master” and “new_branch” Master shouldn’t have any commits ahead, otherwise there will be a need for pull and merging code by hands! $ git merge development # merges files in localhost. $ git checkout master # goes to master branch ![]() When job is finished on this branch, merge with “master” branch:.$ git push # pushes commits only to “new_branch” Change your current git branch to the new_branch.It will contain the latest files of your master branch repository Clone repository in your local dir (or create a new repository):.You begin to create a new branch in this way: git merge -no-ff developmentĮxplanation from the bottom for ones who came here without any knowledge of branches.īasic main/master branch development logic is: You work only on another branches, so you use main/master branch only to merge with another branch which is ready for merging. This is generally useful only when merging development into the master (last step), because you might need to merge master into development (first step) multiple times in your workflow, and creating a commit node for these might not be very useful. If you want to keep track of who did the merge and when, you can use -no-ff flag while merging to do so. There isn't much of a difference in the two approaches, but I have noticed sometimes that I don't want to merge the branch into master yet, after merging them, or that there is still more work to be done before these can be merged, so I tend to leave master untouched until final stuff. Git merge development (there won't be any conflicts now) (resolve any merge conflicts if there are any) (on branch development)$ git merge master I generally like to merge master into the development first so that if there are any conflicts, I can resolve in the development branch itself and my master remains clean. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |