How to work with GIT correctly?

Asked

Viewed 179 times

3

I am starting a team project and my question is whether the order I am following is correct when working with the GIT.

  1. I run git pull origin master //Aqui baixo os arquivos mais recentes do projeto
  2. I make all the changes in an Issue.
  3. Run git checkout -b fix/issue_1
  4. Then run git status.
  5. Then run git add .
  6. After everything is uploaded, I run git commit "Issue test"
  7. E por final git push origin fix/issue_1
  • 1

    In this case, your changes will not be mirrored in branch master and, if the Issue occurs in the master, would not, in fact, be solved. That’s just what you want?

  • This, in this example is not being sent to the master branch, the question is whether the order is correct.

1 answer

4


The right way is a little relative, but I’ll show you how it’s been working with our team, maybe I can give you an idea.

inserir a descrição da imagem aqui

The branches of Hotfix are very similar to branches releases (branches that add a new functionality), as they also prepare a new version to be sent to production, but it is not planned. Their idea is to supply the need to act immediately after some problem in the version that is in production. When a critical error occurs it must be solved immediately, so a branch of Hotfix from the master.

The great thing about this branch is that team members can continue the development of the develop (or the name of the main development branch you use, I’ll use develop here to get more didactic) usually while another developer quickly performs a fix for a problem crítico.

Creating a branch of Hotfix

The branchs of Hotfix are created from the master. For example, let’s say version 1.2 is the version that is in production and due to a serious error, is causing problems. Changes made to the branch develop are still unstable, not eligible for a release for producing. We should then create a branch Hotfix to fix the problem.

$ git checkout -b hotfix-1.2.1 master
# Switched to a new branch "hotfix-1.2.1"
$ ./bump-version.sh 1.2.1
# Files modified successfully, version bumped to 1.2.1.
$ git commit -a -m "Bumped version number to 1.2.1"
# [hotfix-1.2.1 41e61bb] Bumped version number to 1.2.1
# 1 files changed, 1 insertions(+), 1 deletions(-)

Don’t forget to change the version number after you create the branch. Then send the changes in one or more commits. (If you use this versioning scheme)

$ git commit -m "Fixed severe production problem"
# [hotfix-1.2.1 abbe5d6] Fixed severe production problem
# 5 files changed, 32 insertions(+), 17 deletions(-)

Finishing a branch of Hotfix

When finalized, a Hotfix needs to be merged back into the branches master and develop and now apply the changes back to your branch master.

$ git checkout master
# Switched to branch 'master'
$ git merge --no-ff hotfix-1.2.1
# Merge made by recursive.
# (Summary of changes)
$ git tag -a 1.2.1

Now, include bugfix in develop as well:

$ git checkout develop
# Switched to branch 'develop'
$ git merge --no-ff hotfix-1.2.1
# Merge made by recursive.
# (Summary of changes)

The only exception to the rule here is when there is a branch release current, then Hotfix will be merged with that branch and consequently merged into develop when the release is finished. Case develop urgently need that bugfix and can not wait, you can merge the branch release in the branch develop harmless .

And finally the Hotfix can be removed:

$ git branch -d hotfix-1.2.1
# Deleted branch hotfix-1.2.1 (was abbe5d6).

You can find the whole process here in this article in English

  • I tried sending a commit with the command git -f origin master and I ended up losing all my commits that I had done in a repository and it only appeared the last two that I had done recently. Would have some way to get them back to the repository?

Browser other questions tagged

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