
Let’s assume that we have two branches dev and rel_2.3. But parallel work sometimes results in working on the same files, and may require applying the same change to two separate branches. Git branches were designed to allow working simultaneously on different features within the application without resolving all the conflicts at the same time. Then you can do whatever you want – merge it or work further on the correct branch.Ĭherry-pick – in case you just want friends to commit to your branch
Git reset to restore the state of the commit to the previous commit (you can go back any number of commits if you want).
Create a new branch from the branch that you committed before. A fix to this involves using GIT and does not require making the same change twice. How many times have you been in such a situation: your project manager standing next to you, urging you to make a small change – “it will only take a second” (I just hope you didn’t have to deal with it too often) – and you accidentally commit to the wrong branch. That way we can rename the branch locally and erase the evidence of any mistakes from the remote source. # Push the new branch and set local branch to track the correct remote So we create our feature branch, name it according to the company policy, develop it on this branch… only to find out there is a spelling error in the branch name… There are a couple of ways to fix it (after all we are programmers, and solving problems is what we do) but we can do it using the git branch function. This involves, for example, creating a task acceptance process and branch naming policy. But do you know all their features? This article will show you some tips, tricks and functions that you should know to fully use the potential of GIT.Īt some point, every IT company realizes the need to standardize working with GIT. and then we are finally allowed to leave the buildingĪt the core of our work with GIT are branches. For example, in case of emergency of fire the expected behavior would be: A single technology to rule them all, and reign above all the differences: GIT, the beloved version control system.Īll of us know GIT and we are always ready to use it. Clearly, one side has little in common with the other side, but there is one thing that bridges the two realms.
Cherry-pick – in case you just want friends to commit to your branchīeing a front-end developer involves getting into numerous arguments with the back-end guys, usually over whose technology is better.