Juni is a membership-driven learning platform designed to help each student discover and pursue their passions with joy

Juni

Long ago, in an era when every junior could find a job and get an offer without much effort, I encountered situations that forced me to face the reality of the modern industry. It was a time when crowds were eager to enter the world of programming, but not everyone understood what to prepare for. A call from HR. It went successfully, and then I was invited for an interview. At the interview, there was a certain owner of the company named Elizar Viktorovich. However, he didn't ask any technical development questions but immediately started talking about the future job. It was strange; by that time, I had already had several real but unsuccessful interviews. Later, I googled this Elizar and saw a huge number of angry reviews from juniors on all open platforms stating that Elizar assigns tasks from freelancers but does not pay salary during the probation period, and after the probation period, he disappears. I did a test assignment for free, and the employer disappeared. The motives are really unknown. The task was simple but strange - to make a regular mobile application that reads data from JSON and shows a list of cards. The strangeness was that there were extra spaces and some letters from the Latin alphabet were replaced with Cyrillic :/; things that generally do not occur in practice. Honestly, it's not very clear what this test assignment is checking. I sent the task, but the employer didn't even read my messages. TWO months later, he replied: "We liked your test assignment; we will contact you for an interview." And then he disappeared... Another episode: a random call from a man from my city claiming that he was ready to hire me for a job from an ad I posted on hh.ru. He offered a salary in an envelope of 45 thousand rubles. When I refused, he started to criticize me and claimed that I was a fool who didn't understand what kind of opportunity it was. Doubts prevented me from accepting such a job offer. Today, when the market is flooded with juniors, deception and shady schemes have become commonplace. The recommendation I can give is that no reputable company will offer a job to a developer without a thorough technical interview. If something is offered without this, you should think about hidden pitfalls. The reality of the IT industry has changed, and now, it's important to be vigilant and ready for surprises. I hope my experience will help others avoid such pitfalls and make the right decisions on their way to a career in IT. What strange or unusual requests or tasks have you ever received during interviews or completing test assignments for work in the IT field?

How I Was Deceived When I Was a Junior Developer

*We will survive, believe me!* Something that all junior developers share, regardless of the stack they are working on, whether it's backend, frontend, mobile, JavaScript, C#, Angular, PHP, or whatever the focus of their work is: managing branches, making commits, and creating Pull Requests. One of the key factors to transform your career is to refine your communication with your team more and more. The clearer you are in presenting your ideas, doubts, and opinions, the more value you will have. So, as the idea of this text is to be practical, let's go to our main topics: ; ; and . Managing Branches Commits Pull Requests Managing Branches is a model for managing branches. The idea is to create, from the main branch, specific branches for the development of your project, complete the development of what you are creating, and merge it back into the main branch. Gitflow In Practice: Your task for the week will be to include a social login with Facebook in your project. What's the first step? Start your project from the main branch (main), switch to the branch where the project is being developed (develop), and from there, create a new branch for this task and work on it (feat/social-login-facebook). Only then do you start your work. When you finish your work, this branch will be merged into the “develop” branch. What are the most common types of branches? : It is the main branch, reflecting the most "stable" version of the product you are working on. Main : Developers use this branch to start their projects, and it serves as the base code. Develop : This branch is created from the development branch for specific tasks. It is considered a temporary branch that, upon completing its task, should be merged back into Develop. Feature : Similar to the Feature branch in that it's temporary, but it is used for immediate fixes. It can be created from the developed or main branches. Hotfix : This branch is considered a "pre-main." When various tasks are completed and a significant stage of development is finished, a release branch is created from the development branch. It serves more as a milestone for the type of update the main branch will receive. Release Ok, now that you have a better understanding of how branches work, how can you apply this in your daily routine? Free extensions are available in the Visual Studio library, such as , which makes all these branch changes visible and distinct. Let's see: Git Graph Through Git Graph, you have access to the graph itself, showing the progression of branches, the branch description, the creation date, the author, and the commit ID. Git Graph is not only designed for a graphical view of the branching order but also for understanding the commits, where they are made, and how they come together. There is also a specific way to name your branches to adhere to this flow, typically using a prefix like feature/, hotfix/, or release/. You can read more about the topic . here In addition to Gitflow, there are other branch management strategies, such as GitHub Flow, GitLab Flow, OneFlow, and Trunk-Based Development. If you want to delve deeper into the subject, you can read it . here Commits Commit is the tool that allows you to explain the intent behind the changes you made in the code. They should be concise and descriptive, with a clear and specific purpose. Commits act like checkpoints. In addition to explaining the purpose of your changes, they also serve as a way to roll back in case your code is not approved, allowing you to revert to the previous commit. But just like GitFlow, there are also commit standards. The one I've been using is . Conventional Commits Using Conventional Commits makes its purpose very clear since every commit starts with either chore, feat, fix, refactor, docs, perf, style, test, build, ci, or env: : Updating tasks that do not cause changes in the production code but involve tool changes, configuration changes, and libraries. chore : New features or any other new implementations to the code. feat : Bug fixes. fix : Used for any changes that are made in the code but do not alter the final functionality of the impacted task. refactor : Inclusion or modification of documentation files. docs : Changes to improve performance. perf : Formatting changes in the code presentation that do not affect the code's meaning. style : Adding missing tests or fixing existing tests. test : Changes that affect the build system or external dependencies. build : Changes in CI configuration files and scripts. ci : Modifications or additions to configuration files in continuous integration (CI) processes and methods. env Since the commit is a way to create a checkpoint, it should contain a fragment of your task. In our case, you could divide the task of adding login through Facebook into the following commits: Creating a relationship with Facebook to receive a token feat: Add integration with Facebook to receive the token Creating necessary permissions on Facebook feat: Configure permissions on Facebook for integration Creating a component to perform the request feat: Implement component for the request to Facebook Creating verification of the Facebook token with the user in the project feat: Add verification of Facebook token with the user in the project Testing integration with Facebook test: Perform integration tests with Facebook Creating documentation for the integration with Facebook docs: Add documentation for integration with Facebook By making commits in this way, when you create your PR, it will make your life easier, as it becomes clearer what should be included in the PR since you have already described everything you did in the code through the commits. Now, what tools can help you maintain standardized commits? and . Commitlint Husky With Commitlint, you can create a commit verification filter that needs to follow a specific format (conventional commits) to be effective. And how do you apply to ? By using and Husky, which compare the established rules and what you wrote. If the pattern is not followed, it prevents the creation of the commit, asking you to correct it. It is essentially an automation of the commit verification process, limiting their size and allowing them to be divided into a short message, scope, and commit description (if necessary). Commitlint Commitizen For the application of these tools, I recommend these two texts: 1 - Why Should you use Commitizen + Husky for conventional commit and have organised lint 2 - Como adicionar hooks de commit ao Git com Husky para automatizar tarefas Pull Request (PR) And now what? You created your branch, completed the defined task, created checkpoints with commits, and now you need to make the PR to add your branch to the developed branch. How to do it? A Pull Request is the way you ask to merge your branch into the develop branch. It is the method we use to present your work to be reviewed by other developers and approved. The main purpose of the PR is to present what has been done, validate the work, or point out changes that need to be made and include your code in the development branch. As a communication tool, although it does not have a convention like the previous ones, there are some ideas to keep in mind when making your PR. Your PR should be based on WHY, WHAT, and HOW. : Why your PR is necessary, and what problem caused your need. WHY : Describe what your PR does, not in a technical way, but what the practical effect of your code change is. WHAT : This is the space you should use to make it clear, in a technical way, what changes you made. You should use your commits as a guide for what will be explained, which files were altered/created/deleted, how it happened, and why it happened this way. That would be the basic necessity. HOW Now, two points to pay attention to: PRs should contain between 200 and 400 lines of code change; more than that, there's a possibility that an error may go unnoticed. : The number of code changes Your PR is the moment to explain what you did, but it doesn’t mean writing a book. Just like with commits, you have to focus on being concise and clear. Conciseness: Finally, there is other information you can add to facilitate the interpretation of your PR, such as the type of changes made, screenshots or videos of the effects of your change on the project, adding the link to the Task you resolved, some form of checklist, and a section for additional information you may want to add. You can find a screenshot and the to the example PR template I usually use. link I also recommend Kara's on the subject, which is much more comprehensive than this. article : Some teams may have their template; if yours doesn't, you can check if it's possible to add one. itself provides a detailed description of how to do this. PS GitHub Conclusion Knowing how to use and create branches, commits, and pull requests are basic concepts, but not everyone gives them the importance they deserve. Although this is not directly related to code, understanding how to use branches, commits, and pull requests is fundamental and highly valuable because it's the way developers can communicate, explain their work, and receive feedback for improvement. This is the first text in a series of guides that I intend to create. As I continue learning in my day-to-day, I'll keep publishing these ideas.

Your Junior Dev Survival Guide to Managing Branches, Commits and PR

Java Testing Frameworks: Choosing the Right Tool for the Job - JUnit, AssertJ and Hamcrest

The Basics of Developer Hierarchy First, let's delve into such a convoluted narrative. What sets a Junior apart from a Mid and a Senior developer? You need to understand that in the real world, there isn't a clear-cut demarcation because it varies significantly based on the company's perception. In one place, , while with the same set of skills, you could be considered a Mid elsewhere. And in a third setting, you might even qualify as a Senior. So, the best definition I've come across goes something like this: you might be a Junior 👶: A Junior is essentially a beginner in the field of development who can handle basic tasks. However, they often need assistance to complete a task entirely because they lack the experience. Juniors tend to tackle tasks to the best of their abilities but may not excel in optimization. Junior Developer 🧑‍🚀: A Mid-level developer is more independent and experienced. They can tackle tasks on their own, understanding the project's specificities, system architecture, and overall project structure. While not perfect, they can complete assigned tasks without external help. Mid-level Developer 👴: A Senior developer is the one with the most experience. They can start from scratch and execute a project to perfection. They grasp the project's specificities, choose the optimal technologies, manage team interactions effectively, and understand how to achieve the project's goals efficiently. It's the highest level of technical expertise. Senior Developer Here's an amusing definition as well: A Junior developer is one who has acquired basic knowledge and now feels invincible, believing they can implement anything. Then, as you gain a bit more experience to the Middle level, you realize there are things you don't understand. You lose that invincibility feeling. But, Seniors are in a constant state of realizing just how much they don't know, yet they don't fret because they have the experience to quickly figure things out. The distinctions between Junior, Mid, and Senior developers can be somewhat blurry and are subject to variation. It's essential to understand that these labels are relative and depend on the context and expectations of the company you work for. 🎯💼 Dealing with the Real World Let's get down to the nitty-gritty. In the developer's universe, there's more to it than just coding. Conflict Resolution & Communication🤝 In the real world, you're going to face conflict. It's unavoidable because developers, like any other humans, have different values, interests, and perceptions. But, as a Mid, it's your duty to learn how to navigate those rocky waters. You've got to be the peacemaker when conflicts arise, all while keeping the development ship sailing smoothly. Communication is another crucial skill in this game. Even if you're an introverted code wizard, you need to communicate effectively. If a problem crops up, don't keep mum – speak up and discuss it. Timely discussions prevent issues from blowing up later on. So, whether you're an introvert or an extrovert, communication is your ticket to success. More Essential Skills📚 For Mids, the path to success isn't all about coding. You need to start understanding business requirements and what the clients want. This helps you find more efficient solutions to problems. Being an independent thinker and a self-learner is also a must. You've got to keep up with new technologies, methodologies, and approaches. – knowing how to assess the time it takes to complete a task is crucial. You can't be a Mid without mastering this skill. Sharing knowledge with your team is vital, too. If you can explain complex concepts in a way a newbie developer can understand, you're golden. It's all about making the learning process smoother.📖 Mid-level developers should also hone their estimating skills The Mid's Transition🚀 As a Mid, you'll likely transition into more managerial roles. You'll be responsible for project management, delegating tasks effectively, and making sure your team communicates seamlessly. It's all about leveling up and passing on your wisdom to the newbies. In summary, being a Mid-level developer is like balancing on a tightrope. You've got to keep your technical skills sharp while diving into the world of business requirements, communication, and self-improvement. But remember, the more you learn, the more valuable you become to potential employers. So there you have it, the lowdown on the developer hierarchy. Whether you're just starting your coding journey or climbing the ladder, there's always something new to learn and always a new challenge around the corner. Embrace the journey, and keep coding!

Discover the Nuances of Junior, Mid, and Senior Developers in the Tech Industry

A Detailed Roadmap to Take You From Junior to Senior Web Developer

Junior developers often find themselves caught in a dilemma between delivering code quickly and ensuring high code quality. While speed of delivery is important to meet deadlines and keep up with the pace of the industry, quality is crucial for maintaining software integrity and avoiding technical debt. code In this article, we will explore the challenge that junior developers face in finding the right balance between these two opposing priorities and discuss strategies for achieving both speed and quality in their work. The Importance of ‘Why?’ and Consequence in Development Good developers and development teams answer questions in the context of solving problems. Answering ‘Why?’ reveals whether actions correspond to an end goal. Understanding consequences defines a good developer and distinguishes technical debt from bad code. Ignorance of consequence leads to unmanaged complexity that stalls delivery. Pushing ‘Why?’ and enhancing consequences ensure continuous value and delivery, rather than simply producing or building up technical debt. Tips for Striking the Right Balance You do not necessarily need to be “Quick & Dirty” or “Clean & Slow.”​ Whenever you speak about quality, there is an inherent assumption that it takes longer. Don’t get me wrong--most of the time, if you need to have a clean code, you need to invest some time in it, but not necessarily all the time. You can choose the right balance between the two. There will be times when velocity takes priority and others when quality is needed to avoid future stupid, unexpected problems. So, it’s like this: getting the balance right between meeting deadlines, shipping features, and writing the best code possible is seriously tricky. Some folks think that the need to get things done and keep clients happy means that clean code patterns take a back seat, while others believe that quality code should be priority number one and that by prioritizing it, you can actually work faster in the long run, even if you miss short-term deadlines. This is why you need to stop seeing it in black and white and start to see the shades between them. Embrace Everything-as-Code Developers are less likely to make mistakes when testing or deploying software, for example, when the processes are codified. At the same time, managing everything through code also increases software delivery velocity because it allows processes to be as automated as possible. So, the point is to try not to take unnecessary extra steps and replace whatever you can with a code-based approach wherever possible. The more you’re in the actual code, the faster your performance and the better your code will be. Stay Humble & Manage Expectations As a junior developer, it’s expected to make mistakes and produce inconsistent work while learning. Seek when needed, but don’t rely on it entirely. Try to figure things out yourself first and use available resources before asking for help. Take criticism graciously, as code reviews are not personal. Keeping an open mind and considering different approaches is key to becoming a successful developer. senior advice Embrace Small Developer Teams Smaller teams can be more effective for junior developers. This is because smaller teams can often provide more opportunities for learning and growth, as well as more opportunities to contribute to the project. Additionally, smaller teams may be less intimidating for junior developers, as they may feel more comfortable asking questions and seeking help from their colleagues. I am not saying that if you are in a big team, you should quit and search for another place to be in a smaller team, but small teams can give you the key to having the balance faster. Use everything at hand. I actually used to be against using you have for junior developers, and the reason was simply that it could be inaccurate or misleading sometimes, and it could also kill your Googling skills (I think that term will be gone in the next few years 😊 and be replaced with “prompting” or something), So whether you like it or not these tools are here to stay. Chat-GPT or any available AI tool I highly recommend using them for simple, boring tasks so you can gain more time to focus more on your code quality. Conclusion While it is important to write clean, efficient code, it is equally important to meet deadlines and deliver working software. By prioritizing communication, seeking feedback, and continuously learning and improving, junior developers can navigate this challenge and contribute to successful projects. With the right mindset and approach, balancing code quality and speed of delivery can become a strength rather than a weakness. Sources: Speed vs. Quality in Software Delivery: 5 Tips for Striking the Right Balance For modern developers, software delivery speed tends to be the name of the game. To delight users, meet business goals… www.itprotoday.com On the Balance of Speed and Quality Fostering faster development without sacrificing quality. medium.com The Most Common Misconceptions Amongst Junior Developers | Wasp · 6 min read High code quality only indirectly affects users. The main purpose is to keep development velocity high… wasp-lang.dev Also published . here

Junior Devs, Let's Talk About Balancing Code Quality and Your Speed of Delivery

You've probably been there: a newbie in the tech industry, eyes wide, in front of a codebase that looks like a maze, full of uncertainty. Now, you're a mid-level developer, a seasoned coder with a few laps around that maze under your belt. One crucial role you'll play is that of a mentor to junior developers, shepherding them as they navigate the maze for the first time. As Uncle Ben once said to Spiderman, "With great power comes great responsibility." In this case, the 'power' is your experience, and the 'responsibility' is to foster the growth of your less experienced team members. But don't worry! Here's your guide on how to mentor effectively, contribute to the team's growth, and mold the next generation of tech talent. Why Mentorship Matters Mentoring is not just beneficial for the mentee; it's a win-win situation. By sharing your experiences, insights, and tribal knowledge, you're helping junior developers accelerate their learning curve. In return, mentoring offers you an opportunity to refine your communication which helps you clarify and solidify your own understanding. More broadly, mentoring gives provides a fresh perspective, improves your leadership skills, and contributes to a collaborative team culture. about your craft Mentoring Strategies for Mid-Level Developers Every junior developer is unique, with different strengths, weaknesses, and aspirations. Understanding their background and career goals will help you tailor your mentoring approach to meet their needs effectively. Understanding Their Background and Goals: For learning and growth, it's essential to create an environment where junior developers feel comfortable asking questions, making mistakes, and seeking help. Building trust takes time, but it's the foundation of a successful mentor-mentee relationship. Fostering a Safe and Trusting Environment: Coding skills are crucial, but soft skills are often what distinguish successful developers. Teach them how to communicate effectively, manage their time, work as part of a team, and solve problems. Remember, you're not just mentoring a coder but a whole person. Teaching Soft Skills: Feedback is the breakfast of champions. Constructive feedback helps junior developers identify areas for improvement. However, it's not just about pointing out the areas they're lacking but also highlighting what they're doing well and should continue. Providing Constructive Feedback: Remember the old saying, "Show, don't tell." When a junior developer encounters a problem, instead of just giving them the solution, walk them through the problem-solving process. This way, they'll learn how to approach similar issues in the future. Demonstrating Instead of Directing: In our industry, the only constant is change. Continuous learning is a must. Inspire them to keep up with the latest tech trends, attend workshops, webinars, and read. Learning should be part of their daily routine, not just something done when a problem arises. Encouraging Continuous Learning: While ambition and drive are necessary, it's essential to encourage a healthy work-life balance. Share your strategies for avoiding burnout and maintaining productivity without sacrificing personal well-being. Promoting Balance: Mentorship Challenges and Overcoming Them Mentoring isn't always easy. You may face challenges like time constraints, lack of trust, or communication gaps. It's important to remain patient, empathetic, and flexible. Also, seek feedback from your mentees. Their feedback can provide valuable insights into improving your mentoring style. The Ripple Effect of Mentorship By stepping up as a mentor, you're setting a positive example for junior developers. When they advance in their careers, they'll likely pay it forward by mentoring the next generation of developers. This ripple effect contributes to a culture of continuous learning, collaboration, and mutual support in our industry. Embrace mentorship. No, you don't have to be a level 10 expert to be one. A level 3 can successfully offer value to 1's and 2's. Yes, you'll encounter challenges, but the rewards of witnessing your mentee's growth, enhancing your own skills, and contributing to a nurturing team culture far outweigh them. As they say, the best way to learn is to teach. Also published . here

Mentoring Juniors: Tips for Mid-Level to Senior Developers

Hello, community! I’m Anna Naumova, and I’m really passionate about Android Development. Currently, I work in a company that develops a mobile app - a messenger with audio and video calling functions, and I’m actively involved in the development of many useful app features. In this article, I’d like to tell you in general about - a distributed version control system and its most useful commands that I use in my daily work. I’d like also to explain why a Junior Android developer needs to master these commands even before he gets his first job. I will also talk in general about how a workflow is usually arranged in most companies. Perhaps this article will be helpful to Junior Android Developers who are in the early stage of their career. Git Now, looking back, I can say with confidence that if I had mastered Git earlier, my adaptation to the company would have happened much faster. When I learned how to use Git competently, the quality and speed of my work increased significantly. The reason for publishing this article was my daily observations over several years. Talking to who are just looking for their first job, I’ve noticed that they often underestimate the importance of the Git tool. Preparing for their job interviews, they often carefully study fundamental concepts (SOLID, principles of object-oriented programming, data structures), mobile development technologies (working with a network, databases, multithreading, etc.), prepare detailed answers to common interview questions, learn the algorithm complexity,  but at the same time they usually have absolutely no idea about the workflow. To my way of thinking, this approach is wrong. Once a candidate accepts a job offer, he becomes a member of a team, and every team has its own specifics and rules to follow, and Git is an important tool for organizing code work in a team. Junior Android Developers First of all, one should note here that I am in no way detracting from the importance of knowing the fundamental concepts of programming. In my opinion, understanding these concepts is a very important skill for being a successful Android Developer. This is a base, a skeleton, on which all further study of the remaining programming skills is built. In my opinion, that’s why questions about the basic principles of object-oriented programming are very often asked at job interviews. If a candidate understands the basic principles of programming well, then no doubt it is much easier for him to . However, it is equally important, in my opinion, to understand a company workflow when many distributed teams work on one product and write a lot of code. For most cases, knowing a few basic console commands and hotkey combinations will come in handy. I have been using these commands and hotkeys every day in my work for several years, and it makes my work convenient and saves a lot of time. switch to a new technological stack It should be noted that at the initial stage of a career in mobile development, a Junior Android Developer should not study Git deeply. In my opinion, it is much more useful to understand the main principle of how Git works than to learn a lot of complex commands. For most daily tasks, knowing a few basic console commands and hotkey combinations is enough. Even now, after several years, I have been using these commands and hotkeys every day in my work for several years now, and it makes my job convenient and saves a lot of time. The Git system can be loosely compared to a tree. This tree stores the entire commit history. There is the main trunk of the tree - this is a branch with the actual code, which is usually called "master." This branch contains the overall result of the team's work. Below you can see a good visualized example: Usually, working with the project code in a distributed team according to the following scheme: A developer gets a task (where he should implement a certain feature, fix a bug, etc.)., which is assigned a number. Execution of all project tasks is tracked in a project management tool (for example, Jira). Until the developer has taken the task to work, it hangs in the status. As soon as the developer takes the task to work, it goes into th status. "ready for development" e "in work" The developer will perform this task in a separate git branch, which needs to be started from the master branch. To do this, you can open a terminal in Android Studio and run the following git commands: - switch to the master branch Git checkout master - "pull" the current code from the master branch, which is located on the remote repository. Git pull (create a new branch and switch to it immediately). Note that, usually, the branch number corresponds to the issue number. Git checkout -b “your new branch name” to make sure you're on the branch you expect. Git status Let's say that you completed a task and want to push your changes to a remote repository for review. To do this, you can run the following commands (in the Android Studio Terminal or using keyboard shortcuts): - Format code so it looks nice and is easy to read for other developers Ctrl+A+L ​​ (highlight code) Ctrl + A (or "git add" in the terminal). This command will add your code to Git Ctrl+Shift+A (or "git commit" in the terminal). This command will commit the changes in the code. Don’t forget to write your commit message. Ctrl + K (or "git push" in the terminal). This command will push your changes to the remote repository. After that, the Android Developer can change the task status from “in work” to “in review.” Ctrl + Shift + K A tip: before I commit and push my changes, I always open the tab in Android Studio in the top left corner, where all the changes in the code are visible clearly. There you can once again check all the changes made and delete unnecessary ones. And if you suddenly need to switch to another branch without making a commit, you can use the command in the terminal. Then the changes will be temporarily hidden. If you need to show these changes again, this can be done using the command. Changes git stash git stash apply Once your changes are pushed to the remote repository, other developers in your team can see them and provide feedback - agree or disagree. Following these remarks, you need to fix your code and push your changes again. Once you have peer approval from all of your colleagues, you can merge your changes into the master branch of the repository using the button in your common work repository, ex. . Thus, changes in your branch will be merged into the main branch of the remote repository - master. After that, your task status can be changed to ” Done! merge GitLab “ready for test. If you need to update your project, commit and push your changes, you also can use the bottom in the top right corner of Android Studio. If you need to merge a branch from a remote repository into your current branch, you can run the following commands: Git checkout “name of the branch you want to merge into your branch.” Git pull ex: Git merge master. Thus all the actual changes in this branch from the remote repository will be merged in your branch. Git merge “name of the branch you want to merge into your branch.” In Git, you can make changes from one branch to another in two ways: , which I mentioned earlier, and . With the rebase command, you can take all the commits from one branch and apply them in exactly the same order to another branch. merge rebase The second method ( ) has an advantage over merge - it allows you , giving that history the look you need. rebase to rewrite the history of the branch If you don't need to pick up all the commits but only need some, it's convenient to use This method takes the changes made by a single commit and tries to reapply them as a new commit on the current branch. This feature is useful in a situation where you need to pick up a couple of commits from another branch rather than merge the entire branch with all the changes made to it. cherry-pick. These are the basic Git commands that I use actively in my daily work. In my opinion, they are quite enough for most tasks. But sometimes, a developer has to deal with more complex cases. If you want to learn Git in depth and master this technical tool more professionally, I can safely recommend the following resource: dangitgit.com I really hope that my article was useful to everyone who is actively interested in Android development and would like to master such a useful technical tool as Git. I wish you success in learning!

JUNI

junilearning.com

-- employees

Since n.d.

COMPANY RANKING

JUNI

EVERGREEN INDEX #5854

Representing this company? Click here to claim and customize this page!

Juni WIKI

Apply to get your Tech Company News Page live on HackerNoon.com today!

JUNI

junilearning.com

-- employees

Since n.d.

COMPANY RANKING

JUNI

EVERGREEN INDEX #5854

RELATED COMPANIESRANK

STORIES ABOUT JUNI

Representing this company? Click here to claim and customize this page!

Juni WIKI

Apply to get your Tech Company News Page live on HackerNoon.com today!