If you pushed that already to the origin, and other developers are working that as well. This is highly recommended, especially if you have a share branch. You can obviously do a simple git merge master, which would then create a new commit, which is the result of merging the changes which happened in master into our app refactoring branch. Now, in order to synchronize with master, we have different kind of possibilities. Then we just jump to our app refactoring branch. We need to make sure that we are synchronized and up-to-date. To update our code, first of all, we need to pull down everything on master. Also, in this way, you avoid really, really large merge problems in the end when your branch is finished.
The main reason is that you can adapt immediately to changes which other developers made to the main application code. However, I highly recommend you to synchronize it with the main development line, which might be master or some dedicated branch, as often as possible. As in this example here, it's a good practice to create a feature branch for new functionality you create, or even back fixes. You did a git pull today morning, and you got down those commit messages in your master branch. In this case, I have created them on purpose, but it might be that your teammate has created them, pushed them to the remote repository. Then on master, there are other commits on top of it, which are not yet in my feature branch. I'm currently working on that app refactoring feature branch, where I've added two commit messages. Instructor: Our situation in our repository looks as follows.
0 kommentar(er)
