Is this type of merge correct?

Asked

Viewed 47 times

0

I’m doing the following method to administer my branchs, but I don’t know if it’s the right one:

I create a branch with git branch -b newbranch and fix the changes. So when I do an update I simply add the files and git commit --amend and then git push origin newbranch -f. So I always leave my branch with a commit. When I go up to the master I do the following:

git checkout newbranch
git rebase master
git push origin branch -f

I resolve conflicts, so the branch will be updated and then:

git checkout master
git rebase newbranch
git push origin master

I resolve conflicts and then delete the branch.

This is how I was taught, but I saw that there is a merge, which seems to be much simpler, but in the projects I participated I was told that this way I showed the tig is more organized, because it does not show the dismemberments of the tree and everything is more organized.

The point is that I took the lead on the projects, and I want to change this kind of merge with rebase to the normal merge, only I don’t know if it’s the same thing or if the merge is safer. Is there any pattern that is used?

  • 2

    And does it make sense to have it all in one commit? What if you just want to reverse a small change made within this branch?

  • That’s why I want to change, for me the merge makes more sense, but they taught me so.

  • 5

    Possible duplicate of git merge or rebase

  • 1

    Dude, the best way to work with git today is by using the Git Flow Concept, it’s worth taking a look at it, for example, git checkout master, git checkout -b develop, git checkout -b feature/algo && git add . && git commit -m "[ tag ] o que foi criado" && git push origin feature/algo That’s just an exemlplo

  • 1

    Both "make sense" depends on how you want to work. I think it’s worth understanding the difference between them, and then you decide what makes the most sense or is "better" in your case (because "better" is relative), take a read here and here (in addition to the link already cited as duplicate). But in short, the rebase leaves the history cleaner and more linear (at the cost of having to rewrite it), while the merge is the opposite (it doesn’t change the history, but it gets more "polluted").

  • 1

    As to the commit --amend, I’d say it’s a "crooked use" of the command, because it is possible to join commits in other ways. If you choose to merge, for example, you can do that

  • 1

    Although the question is very interesting (and pertinent), when someone mentions "do x is that correct?" and I see that it worked, I remember the best agile methodology of all

Show 2 more comments
No answers

Browser other questions tagged

You are not signed in. Login or sign up in order to post.