What’s the best practice for solving the problem with git?

Asked

Viewed 131 times

2

Next, the scenario is: In my work there is a project with only one branch to master. They had commits that broke the version that was in production. So when I took the project, I needed to clone the project into a specific commit. So I did, cloned in a specific commit, added new features. I have some questions, for example:

  • How do I upload my version without giving conflict? I thought about creating a new branch but would lose the history, I would just remove all those commits that broke the application and go back to the version I downloaded, so I can commit.
  • Have two branches? Like a master and one for development?
  • What else can I do?
git

  • "Have two branches? Like a master and one for development?" for sure, actually even more, development, testing, homologation and production. What’s the problem of losing history of errors, if commits have broken the application have to have them saved?

  • If you search for "git workflow" you will see that there are numerous different possibilities, then "best practice" depends on each case. But I don’t think you’re taking advantage of one of the great advantages of git, which is that you can have multiple branches, since they’re "cheap" and easier to merge compared to svn, for example. And you always have a copy of the entire repository, there is no fear of losing history - although even history is not considered "sacred" to the followers of rebase: https://www.atlassian.com/git/tutorials/merging-vs-rebasing

1 answer

0

There is a better practice that applies in all cases. The problem you are facing is the lack of branchs. I, for example, work as follows:

  • A branch with the code that goes into production, called master
  • One for approval, call staging
  • A new branch for each feature

So when there is a new functionality the process is like this:

  • Create a branch from master, example user register
  • Once ready for testing, merge the user register with the staging
  • Once approved, merge the user register with the master

If this history is important to you, it is possible to create a new branch that contains it and then reset it to master for the last commit without errors.

Example of commands to create a master backup and reset it:

git checkout master
git checkout -b backup-master
git checkout master
git reset --hard HASH_DO_COMMIT_CORRETO
git push origin --force

There are more sophisticated ways to organize your branchs, I recommend following the simplest for you and your team. I also recommend this article on git flow: Git Flow

There’s another technique called Feature toggles, I haven’t used yet, but it’s interesting: Feature Toggles vs Feature Branches

Browser other questions tagged git

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